- 30 Aug, 2013 26 commits
-
-
Huang Shijie authored
From the ONFI spec, we can just get the ECC info from the @ecc_bits field of the parameter page. Signed-off-by:
Huang Shijie <b32955@freescale.com> Reviewed-and-tested-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com>
-
Huang Shijie authored
1.) Why add the ECC information to the nand_chip{} ? Each nand chip has its requirement for the ECC correctability, such as "4bit ECC for each 512Byte" or "40bit ECC for each 1024Byte". This ECC info is very important to the nand controller, such as gpmi. Take the Micron MT29F64G08CBABA for example, its geometry is 8KiB page size, 744 bytes oob size and it requires 40bit ECC per 1KiB. If we do not provide the ECC info to the gpmi nand driver, it has to calculate the ECC correctability itself. The gpmi driver will gets the 56bit ECC for per 1KiB which is beyond its BCH's 40bit ecc capibility. The gpmi will quits in this case. But in actually, the gpmi can supports this nand chip if it can get the right ECC info. 2.) about the new fields. The @ecc_strength_ds stands for the ecc bits needed within the @ecc_step_ds. The two fields should be set from the nand chip's datasheets. For example: "4bit ECC for each 512Byte" could be: @ecc_strength_ds = 4, @ecc_step_ds = 512. "40bit ECC for each 1024Byte" could be: @ecc_strength_ds = 40, @ecc_step_ds = 1024. 3.) Why do not re-use the @strength and @size in the nand_ecc_ctrl{}? The @strength and @size in nand_ecc_ctrl{} is used by the nand controller driver, while the @ecc_strength_ds and @ecc_step_ds are get from the datasheet. Signed-off-by: -
Josh Wu authored
It is better to do the sanity check for the parameter before any hardware operation. Signed-off-by:
Josh Wu <josh.wu@atmel.com> Signed-off-by:
-
Jingoo Han authored
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
Jingoo Han authored
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. Signed-off-by:
-
Jingoo Han authored
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. Signed-off-by:
-
Jingoo Han authored
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. Signed-off-by:
-
Akinobu Mita authored
Use NAND_CI_CELLTYPE_MSK to extract the cell type from nand_chip.cellinfo instead of hardcoded constant. Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Cc: Artem Bityutskiy <dedekind1@gmail.com> Signed-off-by:
-
Lothar Waßmann authored
Acked-by:
Lothar Waßmann <LW@KARO-electronics.de> Signed-off-by:
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by:
-
Josh Wu authored
This patch fix following warning: drivers/mtd/nand/atmel_nand.c:2007: warning: 'atmel_nand_nfc_match' defined but not used This patch add '#if defined(CONFIG_OF)' block to guard around the definition of atmel_nand_nfc_match, in order to avoid the warning when the kernel is configured without DT support. Signed-off-by:
-
Akinobu Mita authored
Use mtdtest_write() and mtdtest_erase_eraseblock() in mtd_test helpers. Signed-off-by:
-
Akinobu Mita authored
Use mtdtest_scan_for_bad_eraseblocks() and mtdtest_erase_good_eraseblocks() in mtd_test helpers. Signed-off-by:
-
Akinobu Mita authored
Use mtdtest_scan_for_bad_eraseblocks() and mtdtest_erase_good_eraseblocks() in mtd_test helpers. Signed-off-by:
-
Akinobu Mita authored
Use mtdtest_read(), mtdtest_write(), mtdtest_erase_eraseblock(), and mtdtest_scan_for_bad_eraseblocks() in mtd_test helpers. Signed-off-by:
-
Akinobu Mita authored
Use mtdtest_write(), mtdtest_read(), mtdtest_scan_for_bad_eraseblocks(), mtdtest_erase_good_eraseblocks() in mtd_test helpers. Signed-off-by:
-
Akinobu Mita authored
Use mtdtest_read() and mtdtest_scan_for_bad_eraseblocks() in mtd_test helpers. Signed-off-by:
-
Akinobu Mita authored
Use mtdtest_write(), mtdtest_read(), mtdtest_erase_eraseblock(), mtdtest_scan_for_bad_eraseblocks(), and mtdtest_erase_good_eraseblocks() in mtd_test helpers. [dwmw2: merge later 'remove always true condition' fix] Signed-off-by:
-
Akinobu Mita authored
Use mtdtest_scan_for_bad_eraseblocks(), mtdtest_erase_good_eraseblocks(), and mtdtest_erase_eraseblock() in mtd_test helpers. Signed-off-by:
-
Akinobu Mita authored
Each mtd test module have a single source whose name is the same as the module name. In order to link a single object including helper functions to every test module, this rename these sources to the different names. Signed-off-by:
-
Akinobu Mita authored
This introduces the helper functions which can be used by several mtd/tests modules. The following three functions are used all over the test modules. - mtdtest_erase_eraseblock() - mtdtest_scan_for_bad_eraseblocks() - mtdtest_erase_good_eraseblocks() The following are wrapper functions for mtd_read() and mtd_write() which can simplify the return value check. - mtdtest_read() - mtdtest_write() All helpers are put into a single .c file and it will be linked to every test module later. The code will actually be copied to every test module, but it is fine for our small test infrastructure. [dwmw2: merge later 'return -EIO when mtdtest_read() failed' fix] Signed-off-by:
-
Brian Norris authored
NAND_BBT_SCANEMPTY is a strange, badly-supported option with omap as its single remaining user. NAND_BBT_SCANEMPTY was likely used by accident in omap2[1]. And anyway, omap2 doesn't scan the chip for bad blocks (courtesy of NAND_SKIP_BBTSCAN), and so its use of this option is irrelevant. This patch drops the NAND_BBT_SCANEMPTY option. [1] http://lists.infradead.org/pipermail/linux-mtd/2012-July/042902.htmlSigned-off-by:
-
Brian Norris authored
nand_base.c shouldn't have to know the implementation details of nand_bbt's in-memory BBT. Specifically, nand_base shouldn't perform the bit masking and shifting to isolate a BBT entry. Instead, just move some of the BBT code into a new nand_markbad_bbt() interface. This interface allows external users (i.e., nand_base) to mark a single block as bad in the BBT. Then nand_bbt will take care of modifying the in-memory BBT and updating the flash-based BBT (if applicable). Signed-off-by:
-
Brian Norris authored
The chip->block_markbad pointer should really only be responsible for writing a bad block marker for new bad blocks. It should not take care of BBT-related functionality, nor should it handle bookkeeping of bad block stats. This patch refactors the 3 users of the block_markbad interface (plus the default nand_base implementation) so that the common code is kept in nand_block_markbad_lowlevel(). It removes some inconsistencies between the various implementations and should allow for more centralized improvements in the future. Because gpmi-nand no longer needs the nand_update_bbt() function, let's stop exporting it as well. Signed-off-by:
-
Brian Norris authored
Just make 'res' an int. Signed-off-by:
-
Brian Norris authored
The parent commit 771c568b ("mtd: nand: add accessors, macros for in-memory BBT") makes the following comment obsolete: /* * Note that numblocks is 2 * (real numblocks) here, see i+=2 * below as it makes shifting and masking less painful */ I don't think it ever could have been "less painful" to have to shift an extra bit (or 2, or 3) at various points in nand_bbt.c (and even outside, since we leak our in-memory format). But now it is certainly more painful, since we have nice macros and functions to retrieve the relevant portions of the BBT. This patch removes any points where the block number is doubled/halved/otherwise-shifted, instead representing the block number in its most natural form: as the actual block number. Signed-off-by:
-
Brian Norris authored
There is an abundance of magic numbers and complicated shifting/masking logic in the in-memory BBT code which makes the code unnecessary complex and hard to read. This patch adds macros to represent the 00b, 01b, 10b, and 11b memory-BBT magic numbers, as well as two accessor functions for reading and marking the memory-BBT bitfield for a given block. Signed-off-by:
-
- 05 Aug, 2013 14 commits
-
-
Josh Wu authored
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:
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by:
-
Josh Wu authored
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:
-
Josh Wu authored
NFC has embedded sram which can use to transfer data. This patch enable reading nand flash via NFC SRAM. It will minimize the CPU overhead. This driver has been tested on SAMA5D3X-EK with JFFS2, YAFFS2, UBIFS and mtd-utils. Here puts the part of mtd_speedtest (read test) result as following: Compare with non-NFC mtd_speedtest result, reading will reduce %45 cpu load with increase %80 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 read speed 509 495 root D 1164 0% 28% 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% 26% insmod /mnt/mtd_speedtest.ko dev=2 mtd_speedtest: eraseblock read speed is 9403 KiB/s mtd_speedtest: testing page read speed 509 495 root R 1164 0% 31% insmod /mnt/mtd_speedtest.ko dev=2 509 495 root D 1164 0% 57% insmod /mnt/mtd_speedtest.ko dev=2 509 495 root D 1164 0% 53% insmod /mnt/mtd_speedtest.ko dev=2 509 495 root D 1164 0% 71% insmod /mnt/mtd_speedtest.ko dev=2 mtd_speedtest: page read speed is 9258 KiB/s Signed-off-by:
-
Josh Wu authored
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: -
Josh Wu authored
Signed-off-by:
-
Jean-Christophe PLAGNIOL-VILLARD authored
this will allow to simply the error and remove path Cc: linux-mtd@lists.infradead.org Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Akinobu Mita authored
ns->geom.oobshift holds bits number in OOB size, but OOB size is not always power of two. So it is useless and it actually isn't used in this driver except for just printing the value at module loading. Signed-off-by:
-
Akinobu Mita authored
Remove the leftover from commit 831d316b ("mtd: nandsim: remove autoincrement code"). Signed-off-by:
-
Akinobu Mita authored
Use NS_RAW_OFFSET() to calculate the page offset in flash RAM image by (row, column) address. Signed-off-by:
-
Akinobu Mita authored
Simplify the definision of NS_RAW_OFFSET() by using (ns)->geom.pgszoob which holds the sum of page size and OOB size. Signed-off-by:
-
Akinobu Mita authored
Use kasprintf() which combines kmalloc and sprintf. Signed-off-by:
-
Akinobu Mita authored
nandsim.pages_written[] is the array of unsigned char which is indexed by the page number and used for identifying which pages have been written when cache_file is used. Each entry holds 0 (not written) or 1 (written), so it can be converted to bitmap. This reduces the allocation size of pages_written[] by 1/8. Signed-off-by:
-
Brian Norris authored
Toshiba NAND datasheets have not been very forthcoming on OOB size information; they do not provide any bitfields in the ID string for spare area. In their 24nm technology flash, however, Toshiba migrated their NAND to have 32 bytes spare per 512 bytes of page area (up from the traditional 16 bytes), as they now require 8-bit ECC or higher. I have discussed this issue directly with Toshiba representatives, and they acknowledge this problem. They recommend detecting these flash based on their technology node as follows: For 24nm Toshiba SLC raw NAND (not BENAND -- Built-in Ecc NAND), there are 32 bytes of spare area for every 512 bytes of in-band data area. We can implement this rule with the following snippet of a device ID decode table, which applies to all their 43nm, 32nm, and 24nm SLC NAND (this table is not fully in the NAND datasheets, but it was provided directly by Toshiba representatives): - ID byte 5, bit[7]: 1 -> BENAND 0 -> raw SLC - ID byte 6, bits[2:0]: 100b -> 43nm 101b -> 32nm 110b -> 24nm 111b -> Reserved I'm also working with Toshiba on including this bitfield description for their 5th and 6th ID bytes in their public data sheets. I will provide the 8-byte ID strings from the two 24nm Toshiba samples I have; their first 6 bytes match the documentation I received from Toshiba: 24nm SLC 1Gbit TC58NVG0S3HTA00 0x98 0xf1 0x80 0x15 0x72 0x16 0x08 0x00 24nm SLC 2Gbit TC58NVG1S3HTA00 0x98 0xda 0x90 0x15 0x76 0x16 0x08 0x00 I have also tested for regressions with: 43nm SLC 4Gbit TC58NVG2S3ETA00 0x98 0xdc 0x90 0x15 0x76 0x14 0x03 0x10 32nm SLC 8Gbit TC58NVG3SOFA00 0x98 0xd3 0x90 0x26 0x76 0x15 0x02 0x08 Signed-off-by: -
Andrea Adami authored
Zaurus 5500 contains 2 LH28F640BFHE-PTTL90 (64M 4Mx16) and the LH28F640BFHE-PTTL90.pdf datasheet available on the net shows the exact erasesize and the OTP support. At the moment only jedec_probe can discover the chip and the NOR is mounted read only probably because of wrong vpp. Signed-off-by:
Andrea Adami <andrea.adami@gmail.com> Signed-off-by:
-
