Numonyx NOR and chip->mutex bug?

[Joakim Tjernlund]

>
> Michael Cashwell <mboards at prograde.net> wrote on 2011/02/02 22:19:58:
> >
> > On Feb 2, 2011, at 3:12 PM, Joakim Tjernlund wrote:

...

> >
> > >      map_write(map, CMD(0xd0), adr);
> > > +    /* some numonyx P30 parts have an apparent delay after starting or
> > > +     resuming some commands. this is normally covered by the cache
> > > +     invalidation done between the command and the start of reading
> > > +     for the busy status bit to clear. but no such cache invalidation
> > > +     is done when resuming and this allows the status-reading thread
> > > +     awakened below to read the status too soon and think its operation
> > > +     has finished when it fact its resumption is still underway. */
> > > +    udelay(20);
> > >
> > > I don't follow your reasoning here. This Read Status command isn't saved anywhere so how can the code get confused later on?
> >
> > It's not that the read happens here and is saved. It happens in the thread awakened a few lines later. That thread went to sleep while waiting for its WSM operation to complete so it's in a loop reading and testing that. The first thing it does on wake up is read the WSM status.
> >
> > My point is that in the case of erase-resume there is much less real time between the write of the resume command and the later read of the status register than there is when starting an erase or program operation anew. This is because the latter perform a cache flush that takes time.
> >
> > My failures were caused by the erase-resume status read "seeing" a non-busy WSM. Adding a 20µs delay before that read (actually after the command write, but it amounts to the same thing) prevents this from happening. By the time awakened "wait-for-completion" code does its first status read it
> sees the WSM as busy as it should until the erase actually finishes.

Perhaps you can test for ESS(SR.6) too?
something like:
  if DWS && !ESS

 Jocke