Numonyx NOR and chip->mutex bug?

Joakim Tjernlund joakim.tjernlund at
Thu Feb 10 13:26:34 EST 2011

> >
> > Michael Cashwell <mboards at> wrote on 2011/02/10 18:10:18:
> > >
> > > On Feb 10, 2011, at 12:02 PM, Joakim Tjernlund wrote:
> > >
> > > > And this reminds me that if the spec is to be trusted, the delay should be just before erase suspend, otherwise you miss the time between the initial erase and the first suspend.
> > >
> > > Probably true to be completely sure. I bet the need for "repeated violations" is why I've been able to make it work by delaying after. But I agree.
> >
> > Yes, but you also indicated that a throw away status read made the problem go away?
> > Can you move that status read to just before suspend and get the same results?
> hmm, Figure 31: Program Suspend/Resume Flowchart and
> Figure 36: Erase Suspend/Resume Flowchart actually specifies
> a read status(0x70) before suspend(0xb0)

Furthermore, the read status has to be to the same "partition" and you have
to end the resume with a read status too
 "If the suspended partition was placed in Read Array mode or a Program Loop"

Mike, I think some of this supports your findings.
I guess we need to save the block address which are being erased
to fulfil "same partition"


More information about the linux-mtd mailing list