summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2014-01-28 18:56:37 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2014-01-28 18:56:37 -0800
commit0e47c969c65e213421450c31043353ebe3c67e0c (patch)
tree5057541fd3dc3521cb0946880d6925f1185dc7b7 /Documentation
parent268943fb7529a15254a5247372119ba4bd735e94 (diff)
parent0ff76a920e3558307567b45aa0a91fb914924bfc (diff)
Merge tag 'for-linus-20140127' of git://git.infradead.org/linux-mtd
Pull MTD updates from Brian Norris: - Add me (Brian Norris) as an additional MTD maintainer (it'd be nice to get David's "ack" for this; I'm sure he approves, but he's been pretty silent lately) - Add Ezequiel Garcie as maintainer for the pxa3xx NAND driver - Last (?) round of pxa3xx improvements for supporting Armada 370/XP - Typical churn in driver boilerplate (OOM messages, printk()'s, devm_*, etc.) - Quad read mode support for SPI NOR driver (m25p80) - Update Davinci NAND driver to prepare for use on new platforms - Begin to kill off NAND_MAX_{PAGE,OOB}SIZE macros; more work is pending - Miscellaneous NAND device support (new IDs) - Add READ RETRY support for Micron MLC NAND - Support new GPMI NAND ECC layout device-tree binding - Avoid mapping stack/vmalloc() memory for GPMI NAND DMA * tag 'for-linus-20140127' of git://git.infradead.org/linux-mtd: (151 commits) mtd: gpmi: add sanity check when mapping DMA for read_buf/write_buf mtd: gpmi: allocate a proper buffer for non ECC read/write mtd: m25p80: Set rx_nbits for Quad SPI transfers mtd: m25p80: Enable Quad SPI read transfers for s25fl512s mtd: s3c2410: Merge plat/regs-nand.h into s3c2410.c mtd: mtdram: add missing 'const' mtd: m25p80: assign default read command mtd: nuc900_nand: remove redundant return value check of platform_get_resource() mtd: plat_nand: remove redundant return value check of platform_get_resource() mtd: nand: add Intel manufacturer ID mtd: nand: add SanDisk manufacturer ID mtd: nand: add support for Samsung K9LCG08U0B mtd: nand: pxa3xx: Add support for 2048 bytes page size devices mtd: m25p80: Use OPCODE_QUAD_READ_4B for 4-byte addressing mtd: nand: don't use {read,write}_buf for 8-bit transfers mtd: nand: use __packed shorthand mtd: nand: support Micron READ RETRY mtd: nand: add generic READ RETRY support mtd: nand: add ONFI vendor block for Micron mtd: nand: localize ECC failures per page ...
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/devicetree/bindings/arm/davinci/nand.txt46
-rw-r--r--Documentation/devicetree/bindings/mtd/davinci-nand.txt94
-rw-r--r--Documentation/devicetree/bindings/mtd/gpmi-nand.txt8
-rw-r--r--Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt6
-rw-r--r--Documentation/mtd/nand/pxa3xx-nand.txt113
5 files changed, 220 insertions, 47 deletions
diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt b/Documentation/devicetree/bindings/arm/davinci/nand.txt
deleted file mode 100644
index 3545ea704b50..000000000000
--- a/Documentation/devicetree/bindings/arm/davinci/nand.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-* Texas Instruments Davinci NAND
-
-This file provides information, what the device node for the
-davinci nand interface contain.
-
-Required properties:
-- compatible: "ti,davinci-nand";
-- reg : contain 2 offset/length values:
- - offset and length for the access window
- - offset and length for accessing the aemif control registers
-- ti,davinci-chipselect: Indicates on the davinci_nand driver which
- chipselect is used for accessing the nand.
-
-Recommended properties :
-- ti,davinci-mask-ale: mask for ale
-- ti,davinci-mask-cle: mask for cle
-- ti,davinci-mask-chipsel: mask for chipselect
-- ti,davinci-ecc-mode: ECC mode valid values for davinci driver:
- - "none"
- - "soft"
- - "hw"
-- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
-- ti,davinci-nand-buswidth: buswidth 8 or 16
-- ti,davinci-nand-use-bbt: use flash based bad block table support.
-
-nand device bindings may contain additional sub-nodes describing
-partitions of the address space. See partition.txt for more detail.
-
-Example(da850 EVM ):
-nand_cs3@62000000 {
- compatible = "ti,davinci-nand";
- reg = <0x62000000 0x807ff
- 0x68000000 0x8000>;
- ti,davinci-chipselect = <1>;
- ti,davinci-mask-ale = <0>;
- ti,davinci-mask-cle = <0>;
- ti,davinci-mask-chipsel = <0>;
- ti,davinci-ecc-mode = "hw";
- ti,davinci-ecc-bits = <4>;
- ti,davinci-nand-use-bbt;
-
- partition@180000 {
- label = "ubifs";
- reg = <0x180000 0x7e80000>;
- };
-};
diff --git a/Documentation/devicetree/bindings/mtd/davinci-nand.txt b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
new file mode 100644
index 000000000000..cfb18abe6001
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
@@ -0,0 +1,94 @@
+Device tree bindings for Texas instruments Davinci/Keystone NAND controller
+
+This file provides information, what the device node for the davinci/keystone
+NAND interface contains.
+
+Documentation:
+Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf
+Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf
+
+Required properties:
+
+- compatible: "ti,davinci-nand"
+ "ti,keystone-nand"
+
+- reg: Contains 2 offset/length values:
+ - offset and length for the access window.
+ - offset and length for accessing the AEMIF
+ control registers.
+
+- ti,davinci-chipselect: number of chipselect. Indicates on the
+ davinci_nand driver which chipselect is used
+ for accessing the nand.
+ Can be in the range [0-3].
+
+Recommended properties :
+
+- ti,davinci-mask-ale: mask for ALE. Needed for executing address
+ phase. These offset will be added to the base
+ address for the chip select space the NAND Flash
+ device is connected to.
+ If not set equal to 0x08.
+
+- ti,davinci-mask-cle: mask for CLE. Needed for executing command
+ phase. These offset will be added to the base
+ address for the chip select space the NAND Flash
+ device is connected to.
+ If not set equal to 0x10.
+
+- ti,davinci-mask-chipsel: mask for chipselect address. Needed to mask
+ addresses for given chipselect.
+
+- nand-ecc-mode: operation mode of the NAND ecc mode. ECC mode
+ valid values for davinci driver:
+ - "none"
+ - "soft"
+ - "hw"
+
+- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
+
+- nand-bus-width: buswidth 8 or 16. If not present 8.
+
+- nand-on-flash-bbt: use flash based bad block table support. OOB
+ identifier is saved in OOB area. If not present
+ false.
+
+Deprecated properties:
+
+- ti,davinci-ecc-mode: operation mode of the NAND ecc mode. ECC mode
+ valid values for davinci driver:
+ - "none"
+ - "soft"
+ - "hw"
+
+- ti,davinci-nand-buswidth: buswidth 8 or 16. If not present 8.
+
+- ti,davinci-nand-use-bbt: use flash based bad block table support. OOB
+ identifier is saved in OOB area. If not present
+ false.
+
+Nand device bindings may contain additional sub-nodes describing partitions of
+the address space. See partition.txt for more detail. The NAND Flash timing
+values must be programmed in the chip select’s node of AEMIF
+memory-controller (see Documentation/devicetree/bindings/memory-controllers/
+davinci-aemif.txt).
+
+Example(da850 EVM ):
+
+nand_cs3@62000000 {
+ compatible = "ti,davinci-nand";
+ reg = <0x62000000 0x807ff
+ 0x68000000 0x8000>;
+ ti,davinci-chipselect = <1>;
+ ti,davinci-mask-ale = <0>;
+ ti,davinci-mask-cle = <0>;
+ ti,davinci-mask-chipsel = <0>;
+ nand-ecc-mode = "hw";
+ ti,davinci-ecc-bits = <4>;
+ nand-on-flash-bbt;
+
+ partition@180000 {
+ label = "ubifs";
+ reg = <0x180000 0x7e80000>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
index 551b2a179d01..458d59634688 100644
--- a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
@@ -17,6 +17,14 @@ Required properties:
Optional properties:
- nand-on-flash-bbt: boolean to enable on flash bbt option if not
present false
+ - fsl,use-minimum-ecc: Protect this NAND flash with the minimum ECC
+ strength required. The required ECC strength is
+ automatically discoverable for some flash
+ (e.g., according to the ONFI standard).
+ However, note that if this strength is not
+ discoverable or this property is not enabled,
+ the software may chooses an implementation-defined
+ ECC scheme.
The device tree may optionally contain sub-nodes describing partitions of the
address space. See partition.txt for more detail.
diff --git a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt
index f1421e2bbab7..86e0a5601ff5 100644
--- a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt
@@ -2,7 +2,9 @@ PXA3xx NAND DT bindings
Required properties:
- - compatible: Should be "marvell,pxa3xx-nand"
+ - compatible: Should be set to one of the following:
+ marvell,pxa3xx-nand
+ marvell,armada370-nand
- reg: The register base for the controller
- interrupts: The interrupt to map
- #address-cells: Set to <1> if the node includes partitions
@@ -13,6 +15,8 @@ Optional properties:
- marvell,nand-keep-config: Set to keep the NAND controller config as set
by the bootloader
- num-cs: Number of chipselect lines to usw
+ - nand-on-flash-bbt: boolean to enable on flash bbt option if
+ not present false
Example:
diff --git a/Documentation/mtd/nand/pxa3xx-nand.txt b/Documentation/mtd/nand/pxa3xx-nand.txt
new file mode 100644
index 000000000000..840fd41c181b
--- /dev/null
+++ b/Documentation/mtd/nand/pxa3xx-nand.txt
@@ -0,0 +1,113 @@
+
+About this document
+===================
+
+Some notes about Marvell's NAND controller available in PXA and Armada 370/XP
+SoC (aka NFCv1 and NFCv2), with an emphasis on the latter.
+
+NFCv2 controller background
+===========================
+
+The controller has a 2176 bytes FIFO buffer. Therefore, in order to support
+larger pages, I/O operations on 4 KiB and 8 KiB pages is done with a set of
+chunked transfers.
+
+For instance, if we choose a 2048 data chunk and set "BCH" ECC (see below)
+we'll have this layout in the pages:
+
+ ------------------------------------------------------------------------------
+ | 2048B data | 32B spare | 30B ECC || 2048B data | 32B spare | 30B ECC | ... |
+ ------------------------------------------------------------------------------
+
+The driver reads the data and spare portions independently and builds an internal
+buffer with this layout (in the 4 KiB page case):
+
+ ------------------------------------------
+ | 4096B data | 64B spare |
+ ------------------------------------------
+
+Also, for the READOOB command the driver disables the ECC and reads a 'spare + ECC'
+OOB, one per chunk read.
+
+ -------------------------------------------------------------------
+ | 4096B data | 32B spare | 30B ECC | 32B spare | 30B ECC |
+ -------------------------------------------------------------------
+
+So, in order to achieve reading (for instance), we issue several READ0 commands
+(with some additional controller-specific magic) and read two chunks of 2080B
+(2048 data + 32 spare) each.
+The driver accommodates this data to expose the NAND core a contiguous buffer
+(4096 data + spare) or (4096 + spare + ECC + spare + ECC).
+
+ECC
+===
+
+The controller has built-in hardware ECC capabilities. In addition it is
+configurable between two modes: 1) Hamming, 2) BCH.
+
+Note that the actual BCH mode: BCH-4 or BCH-8 will depend on the way
+the controller is configured to transfer the data.
+
+In the BCH mode the ECC code will be calculated for each transfered chunk
+and expected to be located (when reading/programming) right after the spare
+bytes as the figure above shows.
+
+So, repeating the above scheme, a 2048B data chunk will be followed by 32B
+spare, and then the ECC controller will read/write the ECC code (30B in
+this case):
+
+ ------------------------------------
+ | 2048B data | 32B spare | 30B ECC |
+ ------------------------------------
+
+If the ECC mode is 'BCH' then the ECC is *always* 30 bytes long.
+If the ECC mode is 'Hamming' the ECC is 6 bytes long, for each 512B block.
+So in Hamming mode, a 2048B page will have a 24B ECC.
+
+Despite all of the above, the controller requires the driver to only read or
+write in multiples of 8-bytes, because the data buffer is 64-bits.
+
+OOB
+===
+
+Because of the above scheme, and because the "spare" OOB is really located in
+the middle of a page, spare OOB cannot be read or write independently of the
+data area. In other words, in order to read the OOB (aka READOOB), the entire
+page (aka READ0) has to be read.
+
+In the same sense, in order to write to the spare OOB the driver has to write
+an *entire* page.
+
+Factory bad blocks handling
+===========================
+
+Given the ECC BCH requires to layout the device's pages in a split
+data/OOB/data/OOB way, the controller has a view of the flash page that's
+different from the specified (aka the manufacturer's) view. In other words,
+
+Factory view:
+
+ -----------------------------------------------
+ | Data |x OOB |
+ -----------------------------------------------
+
+Driver's view:
+
+ -----------------------------------------------
+ | Data | OOB | Data x | OOB |
+ -----------------------------------------------
+
+It can be seen from the above, that the factory bad block marker must be
+searched within the 'data' region, and not in the usual OOB region.
+
+In addition, this means under regular usage the driver will write such
+position (since it belongs to the data region) and every used block is
+likely to be marked as bad.
+
+For this reason, marking the block as bad in the OOB is explicitly
+disabled by using the NAND_BBT_NO_OOB_BBM option in the driver. The rationale
+for this is that there's no point in marking a block as bad, because good
+blocks are also 'marked as bad' (in the OOB BBM sense) under normal usage.
+
+Instead, the driver relies on the bad block table alone, and should only perform
+the bad block scan on the very first time (when the device hasn't been used).