Re: Numonyx NOR and chip->mutex bug?

From: Joakim Tjernlund <joakim.tjernlund@transmode.se>
To: Michael Cashwell <mboards@prograde.net>
Cc: linux-mtd@lists.infradead.org, stefan.bigler@keymile.com,
	"Holger brunck" <holger.brunck@keymile.com>,
	"Anders Grafström" <grfstrm@users.sourceforge.net>
Subject: Re: Numonyx NOR and chip->mutex bug?
Date: Thu, 10 Feb 2011 16:51:21 +0100	[thread overview]
Message-ID: <OF99405172.EDDBCEBE-ONC1257833.0056D2A4-C1257833.005719A5@transmode.se> (raw)
In-Reply-To: <AACADCF3-69C5-4D7F-810F-6E60945769BC@prograde.net>

Michael Cashwell <mboards@prograde.net> wrote on 2011/02/10 16:43:40:
>
> On Feb 10, 2011, at 9:04 AM, Joakim Tjernlund wrote:
>
> > Anders Grafström <grfstrm@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.

29 sounds very low, it may be some additional issue you see.

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

I don't know, I have seen drivers(mpc52xx_spi.c) use get_tbl() though.