Merge tag 'for-linus-20140610' of git://git.infradead.org/linux-mtd
Pull MTD updates from Brian Norris: - refactor m25p80.c driver for use as a general SPI NOR framework for other drivers which may speak to SPI NOR flash without providing full SPI support (i.e., not part of drivers/spi/) - new Freescale QuadSPI driver (utilizing new SPI NOR framework) - updates for the STMicro "FSM" SPI NOR driver - fix sync/flush behavior on mtd_blkdevs - fixup subpage write support on a few NAND drivers - correct the MTD OOB test for odd-sized OOB areas - add BCH-16 support for OMAP NAND - fix warnings and trivial refactoring - utilize new ECC DT bindings in pxa3xx NAND driver - new LPDDR NVM driver - address a few assorted bugs caught by Coverity - add new imx6sx support for GPMI NAND - use a bounce buffer for NAND when non-DMA-able buffers are used * tag 'for-linus-20140610' of git://git.infradead.org/linux-mtd: (77 commits) mtd: gpmi: add gpmi support for imx6sx mtd: maps: remove check for CONFIG_MTD_SUPERH_RESERVE mtd: bf5xx_nand: use the managed version of kzalloc mtd: pxa3xx_nand: make the driver work on big-endian systems mtd: nand: omap: fix omap_calculate_ecc_bch() for-loop error mtd: nand: r852: correct write_buf loop bounds mtd: nand_bbt: handle error case for nand_create_badblock_pattern() mtd: nand_bbt: remove unused variable mtd: maps: sc520cdp: fix warnings mtd: slram: fix unused variable warning mtd: pfow: remove unused variable mtd: lpddr: fix Kconfig dependency, for I/O accessors mtd: nand: pxa3xx: Add supported ECC strength and step size to the DT binding mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding mtd: nand: pxa3xx: Clean pxa_ecc_init() error handling mtd: nand: Warn the user if the selected ECC strength is too weak mtd: nand: omap: Documentation: How to select correct ECC scheme for your device ? mtd: nand: omap: add support for BCH16_ECC - NAND driver updates mtd: nand: omap: add support for BCH16_ECC - ELM driver updates mtd: nand: omap: add support for BCH16_ECC - GPMC driver updates ...
This commit is contained in:
Linus Torvalds
35
Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
Normal file
35
Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
Normal file
@@ -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 {
|
||||
....
|
||||
};
|
||||
};
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user