Hi Scott,
From: Scott Wood [mailto:scottwood@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