[PATCH] [MTD] [NAND] GPIO NAND flash driver

[Russell King - ARM Linux]

On Sun, Oct 12, 2008 at 04:56:37AM -0400, Mike Frysinger wrote:
> On Sun, Oct 12, 2008 at 04:28, Russell King - ARM Linux wrote:
> > Maybe you should reconsider that behaviour - this is a prime example
> > why such behaviour is wrong.  If you leave the NAND signals floating,
> > you're going to eat power - most CMOS based devices want inputs to be
> > either logic high or low, and not floating otherwise they eat power.
> >
> > Moreover, you don't want to leave memory control lines floating - you
> > don't want them to pick up noise which may be transmitted inside the
> > NAND chip and may cause malfunction.
> >
> > Lastly, you don't want spurious writes to the NAND memory region (think
> > DMA controller scribbling over memory because of some buggy driver) to
> > write into the NAND, or maybe cause the NAND to erase itself.
> >
> > There's another reason for doing this.  Think GPIO line connected to
> > a loudspeaker amplifier shutdown input.  Do you really want that line
> > floating when the sound driver isn't loaded?
> 
> this is what pull downs/pull ups are for.

So says you.  Not everyone will agree with that statement, especially
on designs which don't behave as you've described in your previous
mail.

> your arguments can just as readily be applied to the powering up state
> and initialization stages.  software cant (and shouldnt) rectify crappy
> hardware designs.

No they don't.  Consider the loudspeaker amplifier example.  Does it
matter if the amplifier is powered up for a few milliseconds on boot?
No.  Does it matter if the amplifier stays powered up afterwards?  Yes,
it'll kill your battery life.

Does it matter if the NAND control lines are at an indeterminent state
at boot?  Probably not, you'd hope that the boot software is small and
don't randomly scribble into your flash storage.  The boot software may
even setup the NAND control lines so it can read the kernel from flash.
Does it matter while the kernel is running, which will have setup the
entire system so there's more probability of things going wrong?

Yes, it could make your platform unbootable if the NAND gets corrupted.

> > On ARM, certainly PXA, the last GPIO state is preserved when free'd.
> 
> if certain behavior is expected, then it should be codified.  i see no
> mention (unless i just missed it) of expected behavior upon freeing in
> Documentation/gpio.txt.

It doesn't.  The fact that the GPIO state is preserved when free'd on
PXA is just that it takes _more_ code to do anything else.

Moreover, all ARM processors I've seen have the ability to set GPIO
state on low power modes, which makes the addition of lots of pull up
and pull down resistors not only a needlessly expense for production
runs, but also wastes power when the signal is held at the opposite
level to which it's being pulled to.

So, while you see "lack of pull ups" as crappy design, others will see
it as a power and cost saving measure.

I'll say that I've never liked this GPIO layer, because it breads ideas
like you're putting forward, which have traditionally not been needed
to be thought about when writing direct to the registers - where you
have system wide control of the GPIO state without any of this "on
gpio_free() such and such might happen" ideas.

Another example - think about a GPIO which is shared between two drivers.
Yes, there are platforms which do this.  No single driver owns the GPIO
signal.  What happens if it's gpio_free'd while the other driver is still
using it?  Yes, the GPIO layer sucks for that, but like it or not, it's
reality and the GPIO API doesn't cater for it.

And don't say, that's crappy hardware then.  Stop being a purist and
become a realist.  It's reality and there is no option but to make it
work.