5 files changed, 152 insertions, 2 deletions

diff --git a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
new file mode 100644
index 000000000000..823d13412195
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
@@ -0,0 +1,35 @@
+* Freescale Quad Serial Peripheral Interface(QuadSPI)
+
+Required properties:
+  - compatible : Should be "fsl,vf610-qspi"
+  - reg : the first contains the register location and length,
+          the second contains the memory mapping address and length
+  - reg-names: Should contain the reg names "QuadSPI" and "QuadSPI-memory"
+  - interrupts : Should contain the interrupt for the device
+  - clocks : The clocks needed by the QuadSPI controller
+  - clock-names : the name of the clocks
+
+Optional properties:
+  - fsl,qspi-has-second-chip: The controller has two buses, bus A and bus B.
+                              Each bus can be connected with two NOR flashes.
+                              Most of the time, each bus only has one NOR flash
+                              connected, this is the default case.
+                              But if there are two NOR flashes connected to the
+                              bus, you should enable this property.
+                              (Please check the board's schematic.)
+
+Example:
+
+qspi0: quadspi@40044000 {
+        compatible = "fsl,vf610-qspi";
+        reg = <0x40044000 0x1000>, <0x20000000 0x10000000>;
+        reg-names = "QuadSPI", "QuadSPI-memory";
+        interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&clks VF610_CLK_QSPI0_EN>,
+                <&clks VF610_CLK_QSPI0>;
+        clock-names = "qspi_en", "qspi";
+
+        flash0: s25fl128s@0 {
+                ....
+        };
+};
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index eb05255b6788..65f4f7c43136 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -28,6 +28,8 @@ Optional properties:
                 "ham1"          1-bit Hamming ecc code
                 "bch4"          4-bit BCH ecc code
                 "bch8"          8-bit BCH ecc code
+                "bch16"         16-bit BCH ECC code
+                Refer below "How to select correct ECC scheme for your device ?"
 
  - ti,nand-xfer-type:           A string setting the data transfer type. One of:
 
@@ -90,3 +92,46 @@ Example for an AM33xx board:
                 };
         };
 
+How to select correct ECC scheme for your device ?
+--------------------------------------------------
+Higher ECC scheme usually means better protection against bit-flips and
+increased system lifetime. However, selection of ECC scheme is dependent
+on various other factors also like;
+
+(1) support of built in hardware engines.
+        Some legacy OMAP SoC do not have ELM harware engine, so those SoC cannot
+        support ecc-schemes with hardware error-correction (BCHx_HW). However
+        such SoC can use ecc-schemes with software library for error-correction
+        (BCHx_HW_DETECTION_SW). The error correction capability with software
+        library remains equivalent to their hardware counter-part, but there is
+        slight CPU penalty when too many bit-flips are detected during reads.
+
+(2) Device parameters like OOBSIZE.
+        Other factor which governs the selection of ecc-scheme is oob-size.
+        Higher ECC schemes require more OOB/Spare area to store ECC syndrome,
+        so the device should have enough free bytes available its OOB/Spare
+        area to accomodate ECC for entire page. In general following expression
+        helps in determining if given device can accomodate ECC syndrome:
+        "2 + (PAGESIZE / 512) * ECC_BYTES" >= OOBSIZE"
+        where
+                OOBSIZE         number of bytes in OOB/spare area
+                PAGESIZE        number of bytes in main-area of device page
+                ECC_BYTES       number of ECC bytes generated to protect
+                                512 bytes of data, which is:
+                                '3' for HAM1_xx ecc schemes
+                                '7' for BCH4_xx ecc schemes
+                                '14' for BCH8_xx ecc schemes
+                                '26' for BCH16_xx ecc schemes
+
+        Example(a): For a device with PAGESIZE = 2048 and OOBSIZE = 64 and
+                trying to use BCH16 (ECC_BYTES=26) ecc-scheme.
+                Number of ECC bytes per page = (2 + (2048 / 512) * 26) = 106 B
+                which is greater than capacity of NAND device (OOBSIZE=64)
+                Hence, BCH16 cannot be supported on given device. But it can
+                probably use lower ecc-schemes like BCH8.
+
+        Example(b): For a device with PAGESIZE = 2048 and OOBSIZE = 128 and
+                trying to use BCH16 (ECC_BYTES=26) ecc-scheme.
+                Number of ECC bytes per page = (2 + (2048 / 512) * 26) = 106 B
+                which can be accomodate in the OOB/Spare area of this device
+                (OOBSIZE=128). So this device can use BCH16 ecc-scheme.
diff --git a/Documentation/devicetree/bindings/mtd/m25p80.txt b/Documentation/devicetree/bindings/mtd/m25p80.txt
index 6d3d57609470..4611aa83531b 100644
--- a/Documentation/devicetree/bindings/mtd/m25p80.txt
+++ b/Documentation/devicetree/bindings/mtd/m25p80.txt
@@ -5,8 +5,8 @@ Required properties:
   representing partitions.
 - compatible : Should be the manufacturer and the name of the chip. Bear in mind
                the DT binding is not Linux-only, but in case of Linux, see the
-               "m25p_ids" table in drivers/mtd/devices/m25p80.c for the list of
-               supported chips.
+               "spi_nor_ids" table in drivers/mtd/spi-nor/spi-nor.c for the list
+               of supported chips.
 - reg : Chip-Select number
 - spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at
 
diff --git a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt
index 86e0a5601ff5..de8b517a5521 100644
--- a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt
@@ -17,6 +17,14 @@ Optional properties:
  - num-cs:                      Number of chipselect lines to usw
  - nand-on-flash-bbt:           boolean to enable on flash bbt option if
                                 not present false
+ - nand-ecc-strength:           number of bits to correct per ECC step
+ - nand-ecc-step-size:          number of data bytes covered by a single ECC step
+
+The following ECC strength and step size are currently supported:
+
+ - nand-ecc-strength = <1>, nand-ecc-step-size = <512>
+ - nand-ecc-strength = <4>, nand-ecc-step-size = <512>
+ - nand-ecc-strength = <8>, nand-ecc-step-size = <512>
 
 Example:
 
diff --git a/Documentation/mtd/spi-nor.txt b/Documentation/mtd/spi-nor.txt
new file mode 100644
index 000000000000..548d6306ebca
--- /dev/null
+++ b/Documentation/mtd/spi-nor.txt
@@ -0,0 +1,62 @@
+                          SPI NOR framework
+               ============================================
+
+Part I - Why do we need this framework?
+---------------------------------------
+
+SPI bus controllers (drivers/spi/) only deal with streams of bytes; the bus
+controller operates agnostic of the specific device attached. However, some
+controllers (such as Freescale's QuadSPI controller) cannot easily handle
+arbitrary streams of bytes, but rather are designed specifically for SPI NOR.
+
+In particular, Freescale's QuadSPI controller must know the NOR commands to
+find the right LUT sequence. Unfortunately, the SPI subsystem has no notion of
+opcodes, addresses, or data payloads; a SPI controller simply knows to send or
+receive bytes (Tx and Rx). Therefore, we must define a new layering scheme under
+which the controller driver is aware of the opcodes, addressing, and other
+details of the SPI NOR protocol.
+
+Part II - How does the framework work?
+--------------------------------------
+
+This framework just adds a new layer between the MTD and the SPI bus driver.
+With this new layer, the SPI NOR controller driver does not depend on the
+m25p80 code anymore.
+
+   Before this framework, the layer is like:
+
+                   MTD
+         ------------------------
+                  m25p80
+         ------------------------
+               SPI bus driver
+         ------------------------
+                SPI NOR chip
+
+   After this framework, the layer is like:
+                   MTD
+         ------------------------
+              SPI NOR framework
+         ------------------------
+                  m25p80
+         ------------------------
+               SPI bus driver
+         ------------------------
+               SPI NOR chip
+
+  With the SPI NOR controller driver (Freescale QuadSPI), it looks like:
+                   MTD
+         ------------------------
+              SPI NOR framework
+         ------------------------
+                fsl-quadSPI
+         ------------------------
+               SPI NOR chip
+
+Part III - How can drivers use the framework?
+---------------------------------------------
+
+The main API is spi_nor_scan(). Before you call the hook, a driver should
+initialize the necessary fields for spi_nor{}. Please see
+drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to fsl-quadspi.c
+when you want to write a new driver for a SPI NOR controller.