Handling multiple NAND chips -- take 2

Handling multiple NAND chips -- take 2

[J.D. Bakker]

[Recap: I started a thread on handling multi-NANDs on July 25th last 
year. The consensus then was that it Could Be Done, and CVS is 
halfway there (mostly wrt the chip numbers in the read/write/etc 
functions in nand.c). So now I have a board with a driver (which I'll 
happily submit if anyone wants it); all eight chips are detected on 
startup, and yaffs over mtd works just fine for the single chip 
scenario. Time to get the other seven to earn their pay]


Hi all,

I'd like to add support for multiple NAND chips to 
drivers/mtd/nand/nand.c . I have gone over the current code (and the 
docs on the website), but I'd like to check some assumptions before I 
start coding (and possibly make a major fool of myself).

This is the plan; fire at will.

* Assumption: all devices are the same type and size.
* No support (yet) for building a wider data bus through putting 
multiple devices in parallel
* All detected devices are concatenated and represented as one large 
linear array of pages
* All devices are soldered to a motherboard. We are not interested in 
taking devices out of the array.
* 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


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 ?

JDB


[actually, I might end up implementing it the other way around, ie:

chip = global_page_addr % number_of_chips;
page = global_page_addr / number_of_chips;

Advantages: (1) higher likelihood of usable parallelism later on due 
to data locality, and (2) since number_of_chips will be << 
number_of_pages, the divide may end up cheaper, especially if I were 
to cheat and specify that number_of_chips must be a power of two. But 
that's starting to sound like premature optimizations...]
-- 
LART. 250 MIPS under one Watt. Free hardware design files.
http://www.lart.tudelft.nl/

Re: Handling multiple NAND chips -- take 2

[David Woodhouse]

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.

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.


-- 
dwmw2

Re: 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.
> 

Re: Handling multiple NAND chips -- take 2

[jasmine]

On Wed, 25 Feb 2004, 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? 

He's a no-good commie.

> 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.

What if you have a board with an onboard NAND (for the OS) and a 
SmartMedia slot?  That's surprisingly common.  It's very difficult to buy 
consistent Smartmedia cards, too-  they often have different parts in 
them during a run.

> > chip = global_page_addr / pages_per_chip;
> > page = global_page_addr % pages_per_chip;
> 
> I think so. I prefer it to the other.

divide not shift?

-J.

Re: Handling multiple NAND chips -- take 2

[J.D. Bakker]

At 6:29 PM +0000 25/2/04, jasmine@linuxgrrls.org wrote:
>  > 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.
>
>What if you have a board with an onboard NAND (for the OS) and a
>SmartMedia slot?  That's surprisingly common.  It's very difficult to buy
>consistent Smartmedia cards, too-  they often have different parts in
>them during a run.

That's true, but would you want the SmartMedia card to be part of the 
linear array ? What I'm doing here is to do for NAND devices what the 
linear (or possibly RAID0) driver does for disks. In both cases is 
the array size/configuration fixed on creation, in neither case will 
you have anything useful/usable when one of the components goes away.

It could well make sense to treat the (hot-plugged) SM card as a 
separate entity, with its own partitions and all. This, however, is 
not what I'm trying to achieve. What I want is the reverse, deal with 
multiple NAND chips as if they were one, larger, NAND device. I can't 
see how hot-plugging et al would be useful in such a scenario (but 
I'm open to any and all demonstrations of the narrow-mindedness of 
such an approach).

>  > > chip = global_page_addr / pages_per_chip;
>>  > page = global_page_addr % pages_per_chip;
>>
>>  I think so. I prefer it to the other.
>
>divide not shift?

I'd gladly shift if anyone can guarantee that pages_per_chip is a 
power of two, for all present, past and future NAND devices. 
Seriously, I don't know NAND well enough to know if this is true or 
not.

JDB.
-- 
Jan-Derk Bakker, bakker@mmc.et.tudelft.nl

The lazy man's proverb:
     'There's no business like slow business !'

Re: Handling multiple NAND chips -- take 2

[Thomas Gleixner]

On Wednesday 25 February 2004 20:35, J.D. Bakker wrote:
> At 6:29 PM +0000 25/2/04, jasmine@linuxgrrls.org wrote:
> >  > 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.
> >
> >What if you have a board with an onboard NAND (for the OS) and a
> >SmartMedia slot?  That's surprisingly common.  It's very difficult to buy
> >consistent Smartmedia cards, too-  they often have different parts in
> >them during a run.
>
> That's true, but would you want the SmartMedia card to be part of the
> linear array ? What I'm doing here is to do for NAND devices what the
> linear (or possibly RAID0) driver does for disks. In both cases is
> the array size/configuration fixed on creation, in neither case will
> you have anything useful/usable when one of the components goes away.

The mtdconcat layer provides this RAID0 function already, but it does not work 
with shared control lines. If you have seperate control lines you can use the 
code as is.

> It could well make sense to treat the (hot-plugged) SM card as a
> separate entity, with its own partitions and all. This, however, is
> not what I'm trying to achieve. What I want is the reverse, deal with
> multiple NAND chips as if they were one, larger, NAND device. I can't
> see how hot-plugging et al would be useful in such a scenario (but
> I'm open to any and all demonstrations of the narrow-mindedness of
> such an approach).

The point is that you can have some soldered chips and a SM card sharing the 
same control lines. The soldered chips could form a large parition mtd0 and 
the SM card would be mtd1. 

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: Handling multiple NAND chips -- take 2

[J.D. Bakker]

At 5:59 PM +0000 25/2/04, David Woodhouse wrote:
>Join us on IRC and tglx can heckle you too :)

Time to install an IRC client, I suppose.

<snip>

>  > * 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.

I'll have a look at it, thanks.

>  > * 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.

Maybe. I don't have much of a problem of returning -EIO (or another 
more applicable error code) when higher layers access a non-present 
device. Then again, I don't see a useful response in such a scenario. 
What is a file system to do when part of the underlying (block) 
device is imply Not There ?

I'd very much like to keep this simplification. It makes the code 
much simpler: you can just rely on the fact that the array consists 
of all devices that were found during a probe. No config options 
needed, no 'raid blocks' on the NANDs.

>And if you mean hotplug -- think SmartMedia.

I'd rather not, thanks. Seriously though, I don't see many useful 
applications for a hot-swappable linear array.

Thanks,

JDB.
-- 
It was then I realized how dire my medical situation was.  Here I was,
a network admin, unable to leave, and here was someone with a broken
network.  And they didn't ask me to fix it.  They didn't even try to
casually pry a hint out of me.  -- Ryan Tucker , in the Monastery

Re: Handling multiple NAND chips -- take 2

[Thomas Gleixner]

On Wednesday 25 February 2004 18:44, J.D. Bakker wrote:

> * Assumption: all devices are the same type and size.
> * No support (yet) for building a wider data bus through putting
> multiple devices in parallel
> * All detected devices are concatenated and represented as one large
> linear array of pages
> * All devices are soldered to a motherboard. We are not interested in
> taking devices out of the array.
> * 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
If all devices share the same control lines (except CS) then an optimization 
of accessing device n while m is busy can be rather complex. 

I have already done some tests with 4 chips on a board. The scenario is, that 
all bus /  control lines except the CS lines are shared over all devices.

The idea is to add 3 pointers to the nand structure. 
p_state		points to state 
p_chip_lock	points to chip_lock
p_wq			points to wq

The pointers can either be initialized in the chip driver or are initialized 
by the nand_scan function to the default fields (state, chip_lock, wq). This 
would not break any existing chipdrivers.

All accesses to state, chiplock and wq must be modified so the access happens 
through the pointers instead of accessing the fields directly.

For your case you must initialize the pointers of chip 2 - 8 to share the 
state, chip_lock and wq field of the first chip. The hwcontrol function is 
shared for all chips.

Then you can use the existing mtdconcat layer to build partition(s) over 
several chips. 

This solution supports 
* different chip type / sizes
* removable devices 
* flexible partitioning

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: Handling multiple NAND chips -- take 2

[David Woodhouse]

On Wed, 2004-02-25 at 21:22 +0100, Thomas Gleixner wrote:
> The idea is to add 3 pointers to the nand structure. 
> p_state		points to state 
> p_chip_lock	points to chip_lock
> p_wq			points to wq

/me shudders. No Hungarian Notation please. :)

-- 
dwmw2