> From: Ezequiel Garcia [mailto:ezequiel.garcia@xxxxxxxxxxxxxxxxxx] > > 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 ��.n��������+%������w��{.n�����{�������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
