During the read of NOR, the kernel actually calls the inline_map_copy_from() to read the data out. And inline_map_copy_from() will use the memcpy_fromio() to do the real job. The memcpy_fromio macro maps _memcpy_fromio() in the current code. But the _memcpy_fromio() will use readb() to do the copy work one byte by one byte. This makes the read performance of NOR very slow(about 2~3MB/s). A similiar discussion could be found in: http://lists.infradead.org/pipermail/linux-arm-kernel/2009-November/003860.html This patch replace the memcpy_fromio with memcpy which is optimized by the kernel. The following is the result from mtd_speedtest with M29W256GL7AN6E: ================================================= mtd_speedtest: MTD device: 2 mtd_speedtest: not NAND flash, assume page size is 512 bytes. mtd_speedtest: MTD device size 4194304, eraseblock size 131072, page size 512, count of eraseblocks 32, pages per eraseblock 256, OOB size 0 mtd_speedtest: testing eraseblock write speed mtd_speedtest: eraseblock write speed is 845 KiB/s mtd_speedtest: testing eraseblock read speed mtd_speedtest: eraseblock read speed is 19504 KiB/s mtd_speedtest: testing page write speed mtd_speedtest: page write speed is 845 KiB/s mtd_speedtest: testing page read speed mtd_speedtest: page read speed is 19140 KiB/s mtd_speedtest: testing 2 page write speed mtd_speedtest: 2 page write speed is 846 KiB/s mtd_speedtest: testing 2 page read speed mtd_speedtest: 2 page read speed is 19320 KiB/s mtd_speedtest: Testing erase speed mtd_speedtest: erase speed is 233 KiB/s mtd_speedtest: Testing 2x multi-block erase speed mtd_speedtest: 2x multi-block erase speed is 225 KiB/s mtd_speedtest: Testing 4x multi-block erase speed mtd_speedtest: 4x multi-block erase speed is 224 KiB/s mtd_speedtest: Testing 8x multi-block erase speed mtd_speedtest: 8x multi-block erase speed is 225 KiB/s mtd_speedtest: Testing 16x multi-block erase speed mtd_speedtest: 16x multi-block erase speed is 225 KiB/s mtd_speedtest: Testing 32x multi-block erase speed mtd_speedtest: 32x multi-block erase speed is 225 KiB/s mtd_speedtest: Testing 64x multi-block erase speed mtd_speedtest: 64x multi-block erase speed is 224 KiB/s mtd_speedtest: finished ================================================= Signed-off-by: Huang Shijie <b32955@freescale.com>
New NAND controllers can perform read/write via HW engines which don't expose
OOB data in their DMA mode. To reflect this, we should rework the nand_chip /
nand_ecc_ctrl interfaces that assume that drivers will always read/write OOB
data in the nand_chip.oob_poi buffer. A better interface includes a boolean
argument that explicitly tells the callee when OOB data is requested by the
calling layer (for reading/writing to/from nand_chip.oob_poi).
This patch adds the 'oob_required' parameter to each relevant {read,write}_page
interface; all 'oob_required' parameters are left unused for now. The next
patch will set the parameter properly in the nand_base.c callers, and follow-up
patches will make use of 'oob_required' in some of the callee functions.
Note that currently, there is no harm in ignoring the 'oob_required' parameter
and *always* utilizing nand_chip.oob_poi, but there can be
performance/complexity/design benefits from avoiding filling oob_poi in the
common case. I will try to implement this for some drivers which can be ported
easily.
Note: I couldn't compile-test all of these easily, as some had ARCH
dependencies.
[Huang Shijie: I remove the unused code for the other drivers.]
[dwmw2: Merge later 1/0 vs. true/false cleanup]
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Acked-by: Jiandong Zheng <jdzheng@broadcom.com>
Acked-by: Mike Dunn <mikedunn@newsguy.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Huang Shijie <b32955@freescale.com>
Add a platform data to indicate whether the board support ONFI nand Signed-off-by: Allen Xu <allen.xu@freescale.com>
Add a new field to gpmi_nand_platform_data{}.
Make the BBT support to board specific.
Signed-off-by: Huang Shijie <b32955@freescale.com>
add the new macro to fix a compiling error. Signed-off-by: Huang Shijie <b32955@freescale.com>
Encapsulate last MTD partition parser argument into a separate structure. Currently it holds only 'origin' field for RedBoot parser, but will be extended in future to contain at least device_node for OF devices. Amended commentary to make kerneldoc happy Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Artem Bityutskiy <dedekind1@gmail.com>
Lots (nearly all) mtd drivers contain nearly the similar code that calls parse_mtd_partitions, provides some platform-default values, if parsing fails, and registers mtd device. This is an aim to provide single implementation of this scenario: mtd_device_parse_register() which will handle all this parsing and defaults. Artem: amended comments Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
The driver gpmi-nand should compile at least. This patch adds the missing gpmi-nand.h to fix the compile error below. CC drivers/mtd/nand/gpmi-nand/gpmi-nand.o CC drivers/mtd/nand/gpmi-nand/gpmi-lib.o drivers/mtd/nand/gpmi-nand/gpmi-nand.c:25:33: fatal error: linux/mtd/gpmi-nand.h: No such file or directory drivers/mtd/nand/gpmi-nand/gpmi-lib.c:21:33: fatal error: linux/mtd/gpmi-nand.h: No such file or directory This header is grabbed from patch below, which has not been postponed for merging. [PATCH v8 1/4] ARM: mxs: add GPMI-NAND support for imx23/imx28 http://permalink.gmane.org/gmane.linux.drivers.mtd/37338 Signed-off-by: Huang Shijie <b32955@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Signed-off-by: Rob Herring <r.herring@freescale.com>
Signed-off-by: Rob Herring <r.herring@freescale.com>