[PATCH 0/1] Fix OMAP2 NAND ONFI device detection

[Gupta, Pekon]

> From: Ezequiel Garcia [mailto:ezequiel.garcia at free-electrons.com]
> > On Wed, Oct 30, 2013 at 09:18:53PM +0000, Gupta, Pekon wrote:
> > >
> > > I'm not sure, of course, but I don't see why not. It's more likely to
> > > break for x16 than it is for x8.
> > >
> > Another question here is ..
> > The above patch assumes that user has configured GPMC bus-width
> > correctly, so if user is already providing GPMC bus-width information
> > via DT, then do we really need to detect NAND device bus-width again
> > using NAND_BUSWIDTH_AUTO ?
> >
> 
> Hm.. I think you're forgetting the original motivation for this patch,
> which was initially explained by you :-) The problem is ONFI doesn't work
> in 16-bit mode.
> 
> Let me clarify. Since GPMC and NAND widths *must* match (otherwise, it
> wouldn't make much sense, right?) we don't really need to autodetect the
> NAND width.
> 
> However, since ONFI doesn't work in 16-bit mode, we would have to do
> something like this (untested pseudo code):
> 
>   nand_scan_ident(...);
> 
>   if (platform_data->devsize == 16)
>   	nand_chip->options |= NAND_BUSWIDTH_16;
> 
> And in some cases we might even get away with such solution. However,
> we can't guarantee nand_scan_ident() doesn't need to swith to 16-bit mode
> inside to perform other commands (maybe some ONFI extended parameter
> page).
> 
> Therefore, and given the width can be autodetected in any case (array
> or ONFI based carry such information) it's much cleaner to simply do:
> 
>   nand_chip->options |= NAND_BUSWIDTH_AUTOMAGIC;
>   nand_scan_ident(...);
> 
> See? Much cleaner, no?
> 
but still dependent on DT property for GPMC configurations...
I preferred NAND bus-width detection to be completely independent
of 'any' DT property.


> And remember: the fact that we must know the device width to configure
> the GPMC correctly (which being a hardware parameter belongs to the DT)
> is OMAP specific. Other SoCs might not have such memory controller
> and thus won't need such knowledge before hand, although that sounds
> unlikely to me.
> 
> The outcome of this discussion seems to be that no driver should ever
> need to specify the 'nand-bus-width' DT property, as Brian
> previously suggested, right?
> 
Right.. And this is where I'm suggesting that in-order to completely
eliminate the dependency on 'nand-bus-width' DT property, you need
to also update GPMC driver, so that its registers can be re-configured with
correct NAND bus-width after nand_scan_ident().


> I must admit I'm a bit puzzled by seeing most drivers setting 16-bit
> before calling nand_scan_ident(). I guess none of them relies on ONFI?
> 
May be, but going forward we should make NAND_BUSWIDTH_AUTO
as a mandatory option, because most of the NAND devices have adopted
to ONFI, and remaining legacy (if any) are part of nand_flash_id[] table.
So either way the device would get detected, if you start with x8
(lowest minimum capability bus-width). Thus there is no need for user
to specify NAND device bus-width property via DT.


with regards, pekon