Numonyx NOR and chip->mutex bug?
mboards at prograde.net
Thu Feb 10 11:41:23 EST 2011
On Feb 10, 2011, at 11:05 AM, Joakim Tjernlund wrote:
> Michael Cashwell <mboards at prograde.net> wrote on 2011/02/10 16:59:50:
>>> A simpler impl. would be a suspend counter. When no. of suspends > 1000, do usleep(500) or usleep(500) every 100-500 suspends.
>> Our messages crossed each other. I just saw this problem with 29 suspends.
>> I wonder if THAT is what's different between these chips and the older 130nm parts. And none of that addresses whether or not this change is just an anomaly in this batch or if we would continue to get them.
>> I'm going to run my test on the older 130nm (2003 vintage) parts just for grins.
> Here is another idea, don't resume between every write_buffer etc. If less than 500 us has passed, just continue with the next write_buffer. That would be much more efficient.
Wouldn't that extend the wrong time. That would ensure the erase stays *suspended* for at least 500us. But doesn't W602 specify that an erase should be allowed *to run* for 500us before suspension?
It seems the other way around.
More information about the linux-mtd