MPC831x (and others?) NAND erase performance improvements

[Scott Wood]

On Tue, 7 Dec 2010 18:24:45 -0500
Mark Mason <mason at postdiluvian.org> wrote:

> Scott Wood <scottwood at freescale.com> wrote:
> 
> > On Mon, 6 Dec 2010 22:15:54 -0500
> > Mark Mason <mason at postdiluvian.org> wrote:
> >
> > > What I found, though, was that the NAND did not inherently assert BUSY
> > > as part of the erase - BUSY was asserted because the driver polled for
> > > the status (NAND_CMD_STATUS).  If the status poll was delayed for the
> > > duration of the erase then the MPC could talk to the video chip while
> > > the erase was in progress.  At the end of the 1ms delay I would then
> > > poll for status, which would complete effectively immediately.
> > 
> > That's what we originially did.  The problem is that during this
> > interval the NAND chip will be driving the busy pin, which corrupts
> > other LBC transactions.
> 
> This is not what we observed with our flash part.  For a page erase,
> the NAND did not assert the busy pin until the status read was done.
> This was confirmed with a logic analyzer, and taking advantage of this
> behavior is the sole purpose of the change.

How would that work, in the normal case where you wait for busy to go
away before reading status?

We observed this corruption happening.  It was the motivation for
commit 476459a6cf46d20ec73d9b211f3894ced5f9871e.

> > Newer chips have this added text in their reference manuals under
> > "NAND Flash Block Erase Command Sequence Example":
> > 
> >   Note that operations specified by OP3 and OP4 (status read) should
> >   never be skipped while erasing a NAND Flash device, because, in
> >   case that happens, contention may arise on LGPL4.  A possible case
> >   is that the next transaction from eLBC may try to use that pin as
> >   an output and since the NAND Flash device might already be driving
> >   it, contention will occur.  In case OP3 and OP4 operations are
> >   skipped, it may also happen that a new command is issued to the
> >   NAND Flash device even when the device has not yet finished
> >   processing the previous request.  This may also result in
> >   unpredictable behavior.
> 
> I would expect those operations to be mandatory.

...but you remove them from the original FIR.  They're not just
mandatory to be done eventually, it has to be done within the one
transaction that is atomic at the LBC.

> > > I know almost nothing at all about the scheduler, but I'm pretty
> > > sure that this behavior would cause the scheduler to think the
> > > video thread was a CPU hog, since the video thread was running for
> > > 1ms for every 20us that the UBI BGT ran, which would cause the
> > > scheduler to unfairly prefer the UBI BGT.  I initially tried to
> > > address this problem with thread priorities, but the unfortunate
> > > reality was that either the NAND writes could fall behind or the
> > > video chip could fall behind, and there wasn't spare bandwidth to
> > > allow either.
> > 
> > If you set a realtime priority and have preemption enabled, you
> > should be able to avoid being delayed by more than one NAND
> > transaction, until the realtime thread sleeps.  Be careful to ensure
> > that it does sleep enough for other things to run.
> 
> I tried that, but if the erases were held off enough to get the other
> bus bandwidth we required then the NAND writes fell behind and the
> kernel oom'd.


Another possibility (but still hackish) is to have the NAND driver
poll rather than be interrupt driven, and disable interrupts while
polling.  Then, whenever anything else runs (assuming no SMP), it
should be safe to access LBC without high latency -- so the scheduler
shouldn't get confused.

To make it somewhat cleaner, provide the same benefit on SMP, and allow
non-LBC things to run, you could use a mutex to synchronize between all
LBC users, though that's more work and could be a nuisance if you want
to access the LBC from an interrupt handler.

-Scott