[U-Boot] [PATCH v4 4/5] mtd: nand: omap: add CONFIG_SYS_NAND_DEVICE_WIDTH to determine NAND device bus-width

[Gupta, Pekon]

Hi Scott,

>From: Scott Wood [mailto:scottwood at freescale.com]
>>On Mon, 2014-04-28 at 17:11 +0530, Pekon Gupta wrote:
>> +   CONFIG_SYS_NAND_DEVICE_WIDTH
>> +	Specifies bus-width of the default NAND device connected to SoC.
>> +	This config is useful for driver which cannot self initialize or
>> +	parse ONFI parameter (like SPL drivers), or for supporting non-ONFI
>> +	compliant devices.
>> +	This config can take following values:
>> +	- 8: x8 NAND devices is connected
>> +	- 16: x16 NAND device is connected
>
>Please list here the drivers that pay attention to this config symbol.
>
Different drivers use different approach.
- Some driver like omap_gpmc.c require users to hack their board file
 and do NAND device-width configurations by themselves.
- Others drivers uses some different CONFIG_SYS_NAND_xx symbols
which is not documented in doc/README.nand

- atmel_nand.c: uses CONFIG_SYS_NAND_DBW_16
- fsl_ifc_nand.c:  depends on configuration done in board file
- fsmc_nand.c: CONFIG_SYS_FSMC_NAND_16BIT
- mpc5121_nfc.c: depends on configurations done in board file
- mxc_nand.c: uses CONFIG_SYS_NAND_BUSWIDTH_16BIT
- ndfc.c: uses CONFIG_SYS_NAND_BUSWIDTH_16BIT
- tegra_nand.c: ??

I just realize OMAP driver can also _reuse_ CONFIG_SYS_NAND_BUSWIDTH_16BIT
instead of adding new config. Is this okay ? I missed it because it wasn't documented.


>I'm not sure what this has to do with CONFIG_SYS_NAND_SELF_INIT -- or
>did you mean something different by "self initialize"?
>
GPMC controller has a configuration bit, which needs to be programmed
based on bus-width of the NAND device attached to it. This configuration
has to be done at _driver_ probe itself, in board_nand_init().

*Current Implementation*
Current implementation of OMAP NAND driver uses nand_init_chip()
which calls board_nand_init() *before* any NAND device is scanned.
So, it's not possible to do use the information from ONFI PARAMs and
re-configure the controller as execution flow never return back to
board_nand_init().

-------
File: drivers/mtd/nand/nand.c
#ifndef CONFIG_SYS_NAND_SELF_INIT
static void nand_init_chip(int i)
{
	struct mtd_info *mtd = &nand_info[i];
	struct nand_chip *nand = &nand_chip[i];
	ulong base_addr = base_address[i];
	int maxchips = CONFIG_SYS_NAND_MAX_CHIPS;

	if (maxchips < 1)
		maxchips = 1;

	mtd->priv = nand;
	nand->IO_ADDR_R = nand->IO_ADDR_W = (void  __iomem *)base_addr;

	if (board_nand_init(nand))     <-------- driver initialization happens before 
		return;

	if (nand_scan(mtd, maxchips))    <------ device scan (where ONFI params are read)
		return;

	nand_register(i);
}
#endif
-------
Therefore, all the drivers which need to configure controllers *before*
the ONFI PARAMs are read from the device, need some or the other
CONFIG_NAND_xx or board file hacks to configure their controller.
This is the background of this patch.



*Alternative Implementation*
An alternate to this was to use "CONFIG_SYS_NAND_SELF_INIT", which gives
freedom to board_nand_init() to do device scan as required. And driver can add
initialization code in-between the calls to nand_scan_ident() and nand_scan_tail()

Reference: doc/README.nand

	if (nand_scan_ident(mtd, CONFIG_SYS_MAX_NAND_CHIPS, NULL))
		error out

	/*
	 * Insert here any code you wish to run after the chip has been
	 * identified, but before any other I/O is done.
	 */

	if (nand_scan_tail(mtd))
		error out


- Moving OMAP NAND driver to use CONFIG_SYS_NAND_SELF_INIT as
given in alternate implementation, requires some larger changes.

- As SPL code flow does not support ONFI param scanning, so some
CONFIG_NAND_xx is required to tell SPL driver about device bus-width.


with regards, pekon