From: Brian Norris <computersforpeace@gmail.com>
To: linux-mtd@lists.infradead.org
Cc: linux-kernel@vger.kernel.org,
"Furquan Shaikh" <furquan@google.com>,
"Stephen Barber" <smbarber@chromium.org>,
"Marek Vasut" <marex@denx.de>, "Rafał Miłecki" <zajec5@gmail.com>,
"Huang Shijie" <shijie.huang@arm.com>
Subject: Re: [PATCH] mtd: spi-nor: scale up timeout for full-chip erase
Date: Tue, 29 Sep 2015 13:26:01 -0700 [thread overview]
Message-ID: <20150929202601.GK31505@google.com> (raw)
In-Reply-To: <1442613557-36838-1-git-send-email-computersforpeace@gmail.com>
On Fri, Sep 18, 2015 at 02:59:17PM -0700, Brian Norris wrote:
> From: Furquan Shaikh <furquan@google.com>
>
> This patch fixes timeout issues seen on large NOR flash (e.g., 16MB
> w25q128fw) when using ioctl(MEMERASE) with offset=0 and length=16M. The
> input parameters matter because spi_nor_erase() uses a different code
> path for full-chip erase, where we use the SPINOR_OP_CHIP_ERASE (0xc7)
> opcode.
>
> Fix: use a different timeout for full-chip erase than for other
> commands.
>
> While most operations can be expected to perform relatively similarly
> across a variety of NOR flash types and sizes (and therefore might as
> well use a similar timeout to keep things simple), full-chip erase is
> unique, because the time it typically takes to complete:
> (1) is much larger than most operations and
> (2) scales with the size of the flash.
>
> Let's base our timeout on the original comments stuck here -- that a 2MB
> flash requires max 40s to erase.
>
> Small survey of a few flash datasheets I have lying around:
>
> Chip Size (MB) Max chip erase (seconds)
> ---- -------- ------------------------
> w25q32fw 4 50
> w25q64cv 8 30
> w25q64fw 8 100
> w25q128fw 16 200
> s25fl128s 16 ~256
> s25fl256s 32 ~512
>
> From this data, it seems plenty sufficient to say we need to wait for
> 40 seconds for each 2MB of flash.
>
> After this change, it might make some sense to decrease the timeout for
> everything else, as even the most extreme operations (single block
> erase?) shouldn't take more than a handful of seconds. But for safety,
> let's leave it as-is. It's only an error case, after all, so we don't
> exactly need to optimize it.
>
> Signed-off-by: Furquan Shaikh <furquan@google.com>
> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Pushed to l2-mtd.git
next prev parent reply other threads:[~2015-09-29 20:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-18 21:59 [PATCH] mtd: spi-nor: scale up timeout for full-chip erase Brian Norris
2015-09-29 20:26 ` Brian Norris [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-01-02 12:53 Venkatesh Yadav Abbarapu
2024-05-07 4:20 ` Abbarapu, Venkatesh
2024-09-17 15:58 ` Abbarapu, Venkatesh
2024-09-20 1:20 ` Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150929202601.GK31505@google.com \
--to=computersforpeace@gmail.com \
--cc=furquan@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marex@denx.de \
--cc=shijie.huang@arm.com \
--cc=smbarber@chromium.org \
--cc=zajec5@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.