Handling multiple NAND chips -- take 2

[Derek Jones]

On Wed, 2004-02-25 at 10:59, David Woodhouse wrote:
> On Wed, 2004-02-25 at 18:44 +0100, J.D. Bakker wrote:
> > This is the plan; fire at will.
> 
> Why? What'd poor Will do wrong?
> 
> Join us on IRC and tglx can heckle you too :)
> 
> > * Assumption: all devices are the same type and size.
> 
My current non-linux product allows for different NAND sizes to be
populated. I would prefer that support for different sizes be added.

> I think that's acceptable. It's _definitely_ OK on NOR. On NAND we may
> be sharing some control lines between different chips, but I still think
> it's OK and we can deal with that in the board-level driver.
> 
> > * No support (yet) for building a wider data bus through putting 
> > multiple devices in parallel
> 
> I think that's OK too.
> 
> > * All detected devices are concatenated and represented as one large 
> > linear array of pages
> 
> Look at the DiskOnChip Millennium Plus address-mangling code and
> comments above DoC_GetDataOffset().
> 
> If we could support that it would perhaps be useful.
> 
> > * All devices are soldered to a motherboard. We are not interested in 
> > taking devices out of the array.
> 
> Not sure. Look at how the new DiskOnChip driver has to screw around
> before the chip probing, so it can pretend this is true. T'would be nice
> to deal with a sparse array, at least.
> 
> And if you mean hotplug -- think SmartMedia.
> 
> > * No optimizations (yet) wrt accessing device n while device m is 
> > busy. Easier to get working code fast than to get fast code working, 
> > and I don't see a way to take advantage of parallelism without 
> > modifying higher layers
> 
> OK.
> 
> > The general idea is to take a 'global' page_addr and turn it into a 
> > (chip,page) tuple like this:
> > 
> > chip = global_page_addr / pages_per_chip;
> > page = global_page_addr % pages_per_chip;
> > 
> > Does that look sane ?
> 
> I think so. I prefer it to the other.
>