On Wed, 8 Dec 2010 22:26:59 +0100
Joakim Tjernlund [off-list ref] wrote:

Scott Wood [off-list ref] wrote on 2010/12/08 21:25:51:

quoted

On Wed, 8 Dec 2010 21:11:08 +0100
Joakim Tjernlund [off-list ref] wrote:

quoted

Scott Wood [off-list ref] wrote on 2010/12/08 20:59:28:

quoted

On Wed, 8 Dec 2010 20:57:03 +0100
Joakim Tjernlund [off-list ref] wrote:

quoted

Can you think of any workaround such as not connecting the BUSY pin at all?

Maybe connect the busy pin to a gpio?

Is BUSY required for sane operation or it an optimization?

You could probably get away without it by inserting delays if you know
the chip specs well enough.

Urgh, that does not feel like a good solution.

No, but you asked if it could be done, and if it was just a
performance issue. :-)

quoted

quoted

Is there any risk that the NAND device will drive the LB and corrupt
the bus for other devices?

I think the only thing the NAND chip should be driving is the busy pin,

OK, good. What function is actually lost if one uses an GPIO instead of
BUSY?

Not much, if you enable interrupts on the GPIO pin.  The driver would
have to be reworked a bit, of course.

You think Freescale could test and validate a GPIO solution? I don't
think we will be very happy to design our board around an unproven
workaround.

Ask your sales/support contacts.

An even better workaround would be if one could add logic between the
NAND and the CPU which would compensate for this defect without needing
special SW fixes.

The problem with that is when would you assert the chipselect again to
check if it's done?  Current SW depends on being able to tell the LBC
to interrupt (or take other action) when busy goes away.

I suppose you could poll with status reads, which could at least be
preempted if you've got something higher priority to do with the LBC.

-Scott