[PATCH] mtd: cfi: Wait for Block Erase operation to finish

Paul Parsons lost.distance at yahoo.com
Thu Mar 1 13:50:29 EST 2012


--- On Thu, 1/3/12, Joakim Tjernlund <joakim.tjernlund at transmode.se> wrote:
> > > > It seems to me that waiting for SR[7:6]=00
> instead of
> > > just
> > > > SR.6=0 would:
> > > > 1. Have the same outcome.
> > > > 2. Be strictly within spec; SR[7:6] have been
> cleared
> > > > therefore the Erase
> > > > Resume command has been accepted.
> > >
> > > Actually on second thoughts maybe not: if the
> erase has
> > > actually completed
> > > when we issue an Erase Resume command then SR.7
> should read
> > > back as 1 and we
> > > end up looping forever. hmm...
> >
> > OK, how about this:
> >
> > 1. Erase Suspend now checks SR.6, exactly as it
> *should* according to the
> > spec flowchart.
> >
> > 2. If SR.6=0 then the erase has already completed, and
> there is no need to set chip->erase_suspended or
> subsequently issue an Erase Resume command.
> 
> Wont work when you have interleaved chips, there one chip
> may complete and the other not.

OK, I see, I think: one chip might have finished erasing by the time we
issue an Erase Suspend, but the other might not. Yikes, they don't make it
easy for us.

> It would be an optimization though, if all chips complete
> then skip suspend state.

And it might just preclude other problems elsewhere. Issuing an unnecessary
Erase Resume does seem risky, given that the command code - 0xd0 - is so
overloaded:
1. 3rd cycle of Buffered Program.
2. 2nd cycle of Buffered Enhanced Factory Program.
3. 2nd cycle of Block Erase.
4. 1st cycle of Program Resume.
5. 1st cycle of Erase Resume.
6. 2nd cycle of Unlock Block.
That said, I presume the state machine already prevents any ambiguity.

> > 3. If an Erase Resume command is needed then we know
> that the erase has
> > not completed, therefore it should be safe to wait for
> SR[7:6]=00.
> 
> Just wait for SR.6 to clear might work.

That is what my 2nd patch does. Should I just submit that as V2?

> Perhaps adding 1 or 2 extra throw away status reads to
> create a small delay instead?

How much delay is enough for which platform and which chips? I would
prefer just waiting for SR.6 to clear if that works.



More information about the linux-mtd mailing list