summaryrefslogtreecommitdiff
path: root/doc/README.nand
diff options
context:
space:
mode:
authorpekon gupta <pekon@ti.com>2014-05-06 00:46:19 +0530
committerTom Rini <trini@ti.com>2014-06-06 17:46:06 -0400
commitb80a66033856cc89c62886ae3e5ba54a7faf31ae (patch)
treeecf8d57a92382864f8bf75757761961e5c237b72 /doc/README.nand
parent6e1899e633c2ac3f6da7101d4990361c6ff2a9d2 (diff)
downloadu-boot-imx-b80a66033856cc89c62886ae3e5ba54a7faf31ae.zip
u-boot-imx-b80a66033856cc89c62886ae3e5ba54a7faf31ae.tar.gz
u-boot-imx-b80a66033856cc89c62886ae3e5ba54a7faf31ae.tar.bz2
mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width
GPMC controller needs to be configured based on bus-width of the NAND device connected to it. Also, dynamic detection of NAND bus-width from on-chip ONFI parameters is not possible in following situations: SPL: SPL NAND drivers does not support ONFI parameter reading. U-boot: GPMC controller iniitalization is done in omap_gpmc.c:board_nand_init() which is called before probing for devices, hence any ONFI parameter information is not available during GPMC initialization. Thus, OMAP NAND driver expected board developers to explicitely write GPMC configurations specific to NAND device attached on board in board files itself. But this was troublesome for board manufacturers as they need to dive into lengthy platform & SoC documents to find details of GPMC registers and appropriate configurations to get NAND device working. This patch instead adds existing CONFIG_SYS_NAND_BUSWIDTH_16BIT to board config hich indicates that connected NAND device has x16 bus-width. And then based on this config GPMC driver itself initializes itself based on NAND bus-width. This keeps board developers free from knowing GPMC controller specific internals. Signed-off-by: Pekon Gupta <pekon@ti.com>
Diffstat (limited to 'doc/README.nand')
-rw-r--r--doc/README.nand18
1 files changed, 18 insertions, 0 deletions
diff --git a/doc/README.nand b/doc/README.nand
index b91f198..2bc5b39 100644
--- a/doc/README.nand
+++ b/doc/README.nand
@@ -190,6 +190,24 @@ Configuration Options:
This is used by SoC platforms which do not have built-in ELM
hardware engine required for BCH ECC correction.
+ CONFIG_SYS_NAND_BUSWIDTH_16BIT
+ Indicates that NAND device has 16-bit wide data-bus. In absence of this
+ config, bus-width of NAND device is assumed to be either 8-bit and later
+ determined by reading ONFI params.
+ Above config is useful when NAND device's bus-width information cannot
+ be determined from on-chip ONFI params, like in following scenarios:
+ - SPL boot does not support reading of ONFI parameters. This is done to
+ keep SPL code foot-print small.
+ - In current U-Boot flow using nand_init(), driver initialization
+ happens in board_nand_init() which is called before any device probe
+ (nand_scan_ident + nand_scan_tail), thus device's ONFI parameters are
+ not available while configuring controller. So a static CONFIG_NAND_xx
+ is needed to know the device's bus-width in advance.
+ Some drivers using above config are:
+ drivers/mtd/nand/mxc_nand.c
+ drivers/mtd/nand/ndfc.c
+ drivers/mtd/nand/omap_gpmc.c
+
Platform specific options
=========================