Add notes to describe how some SoCs integrate this NAND core a little
differently, and so we define extra compatibility strings and register
resources/names.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>

In commit 8ff16cf7 ("Documentation: devicetree: m25p80: add "nor-jedec"
binding"), we added a generic "nor-jedec" binding to catch all
mostly-compatible SPI NOR flash which can be detected via the READ ID
opcode (0x9F). This was discussed and reviewed at the time, however
objections have come up since then as part of this discussion:

  http://lkml.kernel.org/g/20150511224646.GJ32500@ld-irv-0074

It seems the parties involved agree that "jedec,spi-nor" does a better
job of capturing the fact that this is SPI-specific, not just any NOR
flash.

This binding was only merged for v4.1-rc1, so it's still OK to change
the naming.

At the same time, let's move the documentation to a better name.

Next up: stop referring to code (drivers/mtd/devices/m25p80.c) from the
documentation.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Rafał Miłecki <zajec5@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: devicetree@vger.kernel.org
Acked-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NMark Rutland <mark.rutland@arm.com>

Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>

Almost all flash that are "compatible" with m25p80 support the JEDEC
READ ID opcode (0x9F), and in fact, that is often the only thing that is
used to differentiate them. Let's add a compatible string that
represents this lowest common denominator of compatibility.

Device trees can still specify manufacturer/device names in addition,
but (until some reason is found to differentiate between them through
device tree) software will likely want to bind just against the generic
name, and avoid unnecessarily growing its device ID binding tables.

This is related to the work of commit a5b7616c ("mtd:
m25p80,spi-nor: Fix module aliases for m25p80"), which showed that
maintaining these device tables as stable device-tree/modalias binding
tables is not a worthwhile burden for mostly-comptatible flash.

At the same time, let's update the binding doc to point to the
m25p_ids[] ID list instead of spi_nor_ids[]. The former can be used for
device tree bindings, but the latter cannot. In the future, we should
pare down the m25p_ids[] list to only those IDs which are actually used
in device trees.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Cc: Rafał Miłecki <zajec5@gmail.com>
Reviewed-by: NMarek Vasut <marex@denx.de>

Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Signed-off-by: NBaruch Siach <baruch@tkos.co.il>
Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This patch adds the related dts binding document for Hisilicon 504 NAND
controller.
Signed-off-by: NZhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This patch fix multiple words such as "the the" and "which which"
in Documentation/devicetree.
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Since in SAMA5D4 chip, the PMECC can correct bit flips in erased page.
So we add a DT property to indicate this hardware character.

If the PMECC support correct bitflip erased page (all data are 0xff).
Then we can use the PMECC correct the page and skip the erased page
check.
Signed-off-by: NJosh Wu <josh.wu@atmel.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

UBI needs to know the physical erase block size, even on read-only
devices, since it defines the on-device layout. Use a device-tree
provided value to support previously written UBI on read-only NOR.

UBI also needs a non-zero writebufsize, so we set it to one.

Note: This was implemented because hardware write-protected CFI
      NOR cannot be probed for the physical erase block size.
Signed-off-by: NJoe Schultz <jschultz@xes-inc.ccom>
Signed-off-by: NAaron Sierra <asierra@xes-inc.ccom>
[Brian: removed unneeded #ifdef, note 'optional' erase-size property]
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

"fsl,imx6sx-qspi" is also a valid compatible string, so add an entry for it.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This sentence "We support only one NAND chip now" is not true any more.
Multiple chips are supported. So lets remove this sentence to not
confuse anyone.
Signed-off-by: NStefan Roese <sr@denx.de>
Cc: Huang Shijie <b32955@freescale.com>
Cc: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

If there is no PMECC lookup table stored in ROM, or lookup table offset is
not specified, PMECC driver should build it in DDR by itself.

That make the PMECC driver work for some board which doesn't have PMECC
lookup table in ROM.

The PMECC use the BCH algorithm, so based on the build_gf_tables()
function in lib/bch.c, we can build the Galois Field lookup table.

For more information can refer to section 5.4 of PMECC controller
application note:
	http://www.atmel.com/images/doc11127.pdfSigned-off-by: NJosh Wu <josh.wu@atmel.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Expand the description of the 'gpios' property in the GPIO assisted
NAND flash binding, to explicitly list the required GPIO pin references
and their order.

Update the example section to individually bracket the GPIO references,
and capitalize the signal names for improved readability.
Signed-off-by: NGerhard Sittig <gsi@denx.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Add the sunxi NAND Flash Controller dt bindings documentation.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Add documentation for the sandisk docg3 chip.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Cc: devicetree@vger.kernel.org
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Previously, the only way to map a NOR device as a simple ROM was to
use the obsolete "direct-mapped" compatible binding (which further
requires device_type = "nor" and probe-type = "NOR" properties).

This patch adds an "mtd-rom" compatible binding to the "map_rom"
probe type.
Signed-off-by: NAaron Sierra <asierra@xes-inc.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Retrieve the NFC clock to make sure it is enabled. Make that optional to ensure
compatibility with previous device trees but document it as mandatory so newer
device trees will include it.
Signed-off-by: NBoris BREZILLON <boris.brezillon@free-electrons.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: NJosh Wu <josh.wu@atmel.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Correct spelling typo in treewide.
Signed-off-by: NHayato Suzuki <hytszk@gmail.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

For v3.14 and prior, 1-bit Hamming code ECC via software was the
default choice for some boards e.g. 3430sdp.
Commit ac65caf5 in v3.15 changed the behaviour
to use 1-bit Hamming code via Hardware using a different ECC layout
i.e. (ROM code layout) than what is used by software ECC.

This ECC layout change causes NAND filesystems created in v3.14
and prior to be unusable in v3.15 and later. So don't mark "sw" scheme
as deperecated and support it.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

With a flash-based BBT there is no reason to move the Factory Bad
Block Marker from the data area buffer (to where it is mapped by the
GPMI NAND controller) to the OOB buffer. Thus, make this feature
configurable via DT. This is required for the Ka-Ro electronics
platforms.

In the original code 'this->swap_block_mark' was synonymous with
'!GPMI_IS_MX23()', so use the latter at the relevant places.
Signed-off-by: NLothar Waßmann <LW@KARO-electronics.de>
Acked-by: NHuang Shijie <b32955@freescale.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This commit updates the devicetree binding documentation for this driver
with the supported ECC strength and step size combinations.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

- Adds DT binding property for BCH16 ECC scheme
 - Adds describes on factors which determine choice of ECC scheme for particular device

CC: devicetree@vger.kernel.org
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The m25p80.c has used the SPI NOR framework now, and the m25p_ids has
been moved to spi-nor.c and renamed to spi_nor_ids.

This patch updates the document for m25p80.
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Fixed multiple spelling errors.
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NCarlos E. Garcia <carlos@cgarcia.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch adds the binding file for Freescale QuadSPI driver.
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Cc: devicetree@vger.kernel.org
Acked-by Angus Clark <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Some flashes can only be properly accessed when the ECC mode is
specified, so a way to describe such mode is required.

Together, the ECC strength and step size define the correction capability,
so that we say we will correct "{strength} bit errors per {size} bytes".

The interpretation of these parameters is implementation-defined, but they
often have ramifications on the formation, interpretation, and placement of
correction metadata on the flash. Not all implementations must support all
possible combinations. Implementations are encouraged to further define the
value(s) they support.
Acked-by: NBoris BREZILLON <b.brezillon.dev@gmail.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The Keystone arch has compatible nand device, so reuse it.
In case with Keystone it depends on TI_AEMIF because AEMIF
driver is responsible to set timings.

See http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdfReviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: NTaras Kondratiuk <taras@ti.com>
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The properties davinci-ecc-mode, davinci-nand-use-bbt, davinci-nand-buswidth
are MTD generic. Correct names for them are: nand-ecc-mode, nand-on-flash-bbt,
nand-bus-width accordingly. So rename them in dts and documentation.
Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: NTaras Kondratiuk <taras@ti.com>
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Extend bindings for davinci_nand driver to be more clear.
This is clarification only, without semantic changes.
Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: NTaras Kondratiuk <taras@ti.com>
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Move bindings under mtd. Do this in order to make davinci-nand
driver usable by keystone architecture.
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: NTaras Kondratiuk <taras@ti.com>
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Add support for flash-based bad block table using Marvell's
custom in-flash bad block table layout. The support is enabled
a 'flash_bbt' platform data or device tree parameter.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Tested-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Since the driver supports the new compatible string, the binding
documentation must be updated to reflect it.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Acked-by: NJason Cooper <jason@lakedaemon.net>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

In default way, we use the ecc_strength/ecc_step size calculated by ourselves
and use all the OOB area.

This patch adds a new property : "fsl,use-minimum-ecc"

If we enable it, we will firstly try to use the datasheet's minimum required
ECC provided by the MTD layer (the ecc_strength_ds/ecc_step_ds fields
in the nand_chip{}). So we may have free space in the OOB area by using the
minimum ECC, and we may support JFFS2 with some SLC NANDs, such as Micron's
SLC NAND.

If we fail to use the minimum ECC, we will use the legacy method to calculate
the ecc_strength and ecc_step size.
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

OMAP NAND driver currently supports multiple flavours of 1-bit Hamming
ecc-scheme, like:
- OMAP_ECC_HAMMING_CODE_DEFAULT
	1-bit hamming ecc code using software library
- OMAP_ECC_HAMMING_CODE_HW
	1-bit hamming ecc-code using GPMC h/w engine
- OMAP_ECC_HAMMING_CODE_HW_ROMCODE
	1-bit hamming ecc-code using GPMC h/w engin with ecc-layout compatible
	to ROM code.

This patch combines above multiple ecc-schemes into single implementation:
- OMAP_ECC_HAM1_CODE_HW
	1-bit hamming ecc-code using GPMC h/w engine with ROM-code compatible
	ecc-layout.
Signed-off-by: NPekon Gupta <pekon@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

OMAP NAND driver support multiple ECC scheme, which can used in different
flavours, depending on in-build Hardware engines present on SoC.

This patch updates following in DT bindings related to sectionion of ecc-schemes
- ti,elm-id: replaces elm_id (maintains backward compatibility)
- ti,nand-ecc-opts: selection of h/w or s/w implementation of an ecc-scheme
	depends on ti,elm-id. (supported values ham1, bch4, and bch8)
- maintain backward compatibility to deprecated DT bindings (sw, hw, hw-romcode)

Below table shows different flavours of ecc-schemes supported by OMAP devices
+---------------------------------------+---------------+---------------+
| ECC scheme                            |ECC calculation|Error detection|
+---------------------------------------+---------------+---------------+
|OMAP_ECC_HAM1_CODE_HW                  |H/W (GPMC)     |S/W            |
+---------------------------------------+---------------+---------------+
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW     |H/W (GPMC)     |S/W            |
|(requires CONFIG_MTD_NAND_ECC_BCH)     |               |               |
+---------------------------------------+---------------+---------------+
|OMAP_ECC_BCH8_CODE_HW                  |H/W (GPMC)     |H/W (ELM)      |
|(requires CONFIG_MTD_NAND_OMAP_BCH &&  |               |               |
| ti,elm-id in DT)                      |               |               |
+---------------------------------------+---------------+---------------+

To optimize footprint of omap2-nand driver, selection of some ECC schemes
also require enabling following Kconfigs, in addition to setting appropriate
DT bindings
- Kconfig:CONFIG_MTD_NAND_ECC_BCH        error detection done in software
- Kconfig:CONFIG_MTD_NAND_OMAP_BCH       error detection done by h/w engine
Signed-off-by: NPekon Gupta <pekon@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

In case that the nand device will support some features like Nand Flash
Controller, we want to make the sub feature as a sub node of nand device.

Use such organization it is easy to enable/disable feature, also it is back
compatible and more readable.

If the sub-node has a compatible property then it is a driver not partition.
Signed-off-by: NJosh Wu <josh.wu@atmel.com>
Acked-by: NBrian Norris <computersforpeace@gmail.com>
Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
[ added a missing newline -Brian ]
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This patch enable writing nand flash via NFC SRAM. It will minimize the CPU
overhead. The SRAM write only support ECC_NONE and ECC_HW with PMECC.

To enable this NFC write by SRAM feature, you can add a string in dts under
NFC driver node.

This driver has been tested on SAMA5D3X-EK with JFFS2, YAFFS2, UBIFS and
mtd-utils.

Here is part of mtd_speedtest (writing test) result, compare with non-NFC
writing, it reduces %65 cpu load with loss %12 speed.

- commands use to test:
  # insmod /mnt/mtd_speedtest.ko dev=2 &
  # top -n 30 -d 1 | grep speedtest

- test result:
=================================================
mtd_speedtest: MTD device: 2
mtd_speedtest: MTD device size 41943040, eraseblock size 131072, page size 2048, count of eraseblocks 320, pages per eraseblock 64, OOB size 64
mtd_speedtest: testing eraseblock write speed
  509   495 root     D     1164   0%   7% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%   8% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     R     1164   0%   5% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: eraseblock write speed is 5194 KiB/s
mtd_speedtest: testing page write speed
  509   495 root     D     1164   0%  32% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  27% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  25% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  30% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: page write speed is 5024 KiB/s
Signed-off-by: NJosh Wu <josh.wu@atmel.com>
Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Nand Flash Controller (NFC) can handle automatic transfers, sending the
commands and address cycles to the NAND Flash.

To use NFC in this driver, user needs to add NFC child node in nand flash
driver. The NFC child node includes NFC's compatible string and regiters
of the address and size of NFC command registers, NFC registers (embedded
in HSMC) and NFC SRAM.
Also user need to set up the HSMC irq, which use to check whether nfc
command is finish or not.

This driver has been tested on SAMA5D3X-EK board with JFFS2, YAFFS,
UBIFS and mtd-utils.

I put the part of the mtd_speedtest result here for your information.
>From the mtd_speedtest, we can see the NFC will reduce the %50 of cpu load
when writing nand flash. No change when reading.
In the meantime, the speed will be slow about %8.

- commands use to test:
    #insmod /mnt/mtd_speedtest.ko dev=2 &
    #top -n 30 -d 1 | grep speedtest

- test result:

Before the patch:
=================================================
mtd_speedtest: MTD device: 2
mtd_speedtest: MTD device size 41943040, eraseblock size 131072, page size 2048, count of eraseblocks 320, pages per eraseblock 64, OOB size 64
  515   495 root     R     1164   0%  93% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  98% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  99% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: eraseblock write speed is 5768 KiB/s
mtd_speedtest: testing eraseblock read speed
  515   495 root     R     1164   0%  92% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  91% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  94% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: eraseblock read speed is 5932 KiB/s
mtd_speedtest: testing page write speed
  515   495 root     R     1164   0%  94% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  98% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  98% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: page write speed is 5770 KiB/s
mtd_speedtest: testing page read speed
  515   495 root     R     1164   0%  91% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  89% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  91% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: page read speed is 5910 KiB/s

After the patch:
=================================================
mtd_speedtest: MTD device: 2
mtd_speedtest: MTD device size 41943040, eraseblock size 131072, page size 2048, count of eraseblocks 320, pages per eraseblock 64, OOB size 64
mtd_speedtest: testing eraseblock write speed
  509   495 root     D     1164   0%  49% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  50% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  47% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: eraseblock write speed is 5370 KiB/s
mtd_speedtest: testing eraseblock read speed
  509   495 root     R     1164   0%  92% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     R     1164   0%  91% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     R     1164   0%  95% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: eraseblock read speed is 5715 KiB/s
mtd_speedtest: testing page write speed
  509   495 root     D     1164   0%  48% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  47% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  50% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: page write speed is 5224 KiB/s
mtd_speedtest: testing page read speed
  509   495 root     R     1164   0%  89% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     R     1164   0%  94% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     R     1164   0%  93% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: page read speed is 5641 KiB/s
Signed-off-by: NJosh Wu <josh.wu@atmel.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>