Numonyx NOR and chip->mutex bug?

[Michael Cashwell]

On Feb 10, 2011, at 9:04 AM, Joakim Tjernlund wrote:

> Anders Grafström <grfstrm at users.sourceforge.net> wrote on 2011/02/10 14:21:36:
> 
>> 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.

Interesting. I saw the W602 value but it also talks about "erase failures" which are not precisely what I'm seeing. I see failed buffered write. But it's sounding like the issue anyway.

I've just instrumented a suspend count and the erase that was active when a failed write occurred was suspended 29 times. That's not really very high so it fits with the idea that the issue is not the number of suspend/resumes but their timing.

> 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?


I like this idea but how do we deal with the lack of precision? 500µs "typical" and violating this timing "repeatedly"? Yuk. Without hard numbers coding it will be tricky. And what about this all being Numonyx-specific? Do we need to key off of the manufacturer ID or does it apply to all chips handled by this cmd set?

Lastly, what's the general kernel API for µs resolution time? I recall having issues in the past when high-resolution timers is not enabled in the kernel config.

-Mike