Numonyx NOR and chip->mutex bug?

[Joakim Tjernlund]

Anders Grafström <grfstrm at users.sourceforge.net> wrote on 2011/02/10 14:21:36:
>
> On 2011-02-09 22:59, Michael Cashwell wrote:
> > On Feb 9, 2011, at 3:13 PM, Joakim Tjernlund wrote:
> >
> >> hmm, this sounds similar(from http://www.numonyx.com/Documents/Specification%20Updates/SU-309045_P30.pdf)
> >>
> >> 5. W602: erase suspend resume operation
> >> Problem: P30 product may fail to erase in intensive erase/suspend/resume environments. This is
> >>        due to an internal firmware issue that is exhibited in certain applications that require at
> >>       least 3000 to 4000 erase/suspend/resume cycles during the erase of a single block.
> >> Implication: Customer may see erase failure (SR reports “A0”) during a background erase. This
> >>                does not damage the device in any way, but data in the block may be disturbed from its
> >>               original state.
>
> I've seen this issue with Intel 28F640J5 chips as well.
>
> There's an old thread on it.
> http://lists.infradead.org/pipermail/linux-mtd/2008-April/021266.html
>
> A delay was suggested similar to the one you're experimenting with I think.
> http://lists.infradead.org/pipermail/linux-mtd/2008-April/021436.html

Oh, I had forgotten about this thread :)

I agree with the latency theory, for Numonyx there is this:

W602 is the typical time between an initial block erase or erase resume command and the a subsequent erase suspend
command. Violating the specification repeatedly during any particular block erase may cause erase failures.

W602 is defined to 500us

Adding a delay after resume will do it but is a bit crude. Possibly one
could add a timestamp at resume/initial erase and a check in suspend that enough time has passed
before suspending again.

How does that sound?

 Jocke