Merge tag 'for-linus-20140610' of git://git.infradead.org/linux-mtd

* 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 {

		....

	};

};

		"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:

		};

	};

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.

  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

 - 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:

                          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.