http://blog.gmane.org/gmane.linux.drivers.mtd hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.linux.drivers.mtd/46997 <pre> Our current reference Linux kernel for the MAX32590 (JIBE) is based on v2.6.36. (Unfortunately, upgrading to a more recent version is not within the timeframe for solving the current problem.) Our recent reference boards use one of those Micron NAND chips with an on-die 4-bit ECC, which we have basically ignored: To-date, we have simply used the usual 1-bit ECC (i.e., living dangerously!). This must change, and indeed we now have a case on my desk where, had we been using the on-die ECC, it would have saved us a ton of grief. The problem is our kernel version is far too old to take advantage of any of the recent-ish work for on-die ECC. Hence, I am looking into the possibility of adding on-die ECC support to our JIBE controller driver specifically for such NAND chips (or at least the specific Micron NAND chip on the reference boards). Broadly, pretending JIBE's H/W directly supports on-die ECC, but actually doing the work in the driver. A similar trick we played in the past (bitwise-inverted ECC (now obsoleted and long-removed from the driver)) suggests this is not too difficult. I am looking for hints (suggestions), gotchas (warnings), and/or any examples of similar (or other plausible) approaches. Or for something I am overlooking in (or available for) kernels of approximately the vintage we are using. Thanks &amp; cheers! -blf- p.s. At the present time, I am not too interested in the problem of converting existing boards. This MAY change as the scope and details of the solution become more apparent. </pre> Brian Foster 2013-06-19T14:14:53 http://comments.gmane.org/gmane.linux.drivers.mtd/46989 <pre>This patch series enable NFC support for SAMA5 soc. It can send command, address cycles automaticly. Also when enable NFC sram, NFC will transfer data to sram. Which can save lots of cpu time. The mtd speed test results (non-NFC vs NFC), run in sama5d3x-ek with DMA enable, is in the end of this patch. v3 --&gt; v4: 1) refine the commit message for ofpart.c patch and also change the description in partition.txt 2) remove len parameter for ofpart.c's change. 3) use devm_ioremap_resource instead of devm_requrest_and_ioremap. 4) add BIT_POS macro definition for magic number. v2 --&gt; v3: 1) Change the dts usage for NFC. Now use a NFC child node of atmel nand to enable NFC driver. In this way the atmel nand driver will include a NFC driver, which will be probed if dts has NFC node. 2) can enable/disable NFC write by sram in dts. 3) merged J.C's patch(use devm_xxx to simple the code) in this series. 4) remove unused NFC register definitions. Change the definition names. 5) trival fix accroding to J.C's suggestion. 6) modify the ofpart.c for child node check. If the child node has compatible property then this node is a device not a partition. v1 --&gt; v2: 1) rebase it with latest l2-mtd git tree: - remove useless nand commands (NAND_CMD_DEPLETE1, NAND_CMD_STATUS_ERRORx). - adopt to the new nand write function's parameters. Add error message when handle subpage write via nfc sram. 2) rewrite pmecc_enable function. Now I use exist NAND_ECC_READ/WRITE const instead of using a new enum definition. Jean-Christophe PLAGNIOL-VILLARD (1): MTD: atmel_nand: use devm_xxx gpio kzalloc, gpio and ioremap Josh Wu (5): mtd: atmel_nand: replace pmecc enable code with one function. mtd: atmel_nand: add Nand Flash Controller (NFC) support mtd: atmel_nand: enable Nand Flash Controller (NFC) read data via sram mtd: atmel_nand: enable Nand Flash Controller (NFC) write via sram mtd: ofpart: add compatible check for child nodes .../devicetree/bindings/mtd/atmel-nand.txt | 28 + .../devicetree/bindings/mtd/partition.txt | 1 + drivers/mtd/nand/atmel_nand.c | 876 ++++++++++++++++---- drivers/mtd/nand/atmel_nand_nfc.h | 98 +++ drivers/mtd/ofpart.c | 13 +- 5 files changed, 853 insertions(+), 163 deletions(-) create mode 100644 drivers/mtd/nand/atmel_nand_nfc.h mtd_speedtest is run in 60M partition with DMA enabled for two cases: 1. Using NFC and sram read/write with DMA enabled. 2. Using Non-NFC with DMA enabled. Summary of the two test results: 1. With NFC and sram read/write enabled, the write speed will become %10 slower and the cpu load also is reduce a lot (50% -&gt; 20%): Non-NFC NFC Page write Speed: 5536KiB : 46% ~ 64% --&gt; 4989KiB : 13% ~ 22% 2 Page write speed: 5567KiB : 52% ~ 69% --&gt; 5043KiB : 10% ~ 20% 2. With NFC and sram read/write enabled, the read speed is almost same and the cpu load is reduced (30% -&gt; 15%): Non-NFC NFC Page read Speed: 9361KiB : %24 ~ 46% --&gt; 9340KiB : 13% ~ 19% 2 Page read Speed: 9361KiB : %21 ~ 57% --&gt; 9426KiB : 8% ~ 15% Following is the detail test log: case 1: Non-NFC with DMA: ================================================= mtd_speedtest: MTD device: 2 mtd_speedtest: MTD device size 62914560, eraseblock size 131072, page size 2048, count of eraseblocks 480, pages per eraseblock 64, OOB size 64 mtd_speedtest: scanning for bad eraseblocks mtd_speedtest: scanned 480 eraseblocks, 0 are bad mtd_speedtest: testing eraseblock write speed top -n 130 -d 1 | grep speedtest 513 504 root R 1164 0% 62% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root D 1164 0% 53% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 57% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 58% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 53% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 60% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 55% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 55% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 59% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 57% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 62% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: eraseblock write speed is 5594 KiB/s mtd_speedtest: testing eraseblock read speed 513 504 root R 1164 0% 27% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 14% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 5% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 1% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 2% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 1% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: eraseblock read speed is 9442 KiB/s mtd_speedtest: testing page write speed 513 504 root R 1164 0% 46% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 64% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 57% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 64% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 56% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 59% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 59% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 56% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 59% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 62% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 60% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: page write speed is 5536 KiB/s mtd_speedtest: testing page read speed 513 504 root R 1164 0% 46% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 24% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 30% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 30% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 26% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 25% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: page read speed is 9361 KiB/s 513 504 root R 1164 0% 24% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: testing 2 page write speed 513 504 root R 1164 0% 69% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 56% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 57% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 61% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 55% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 61% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 55% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 52% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 55% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 58% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: 2 page write speed is 5567 KiB/s mtd_speedtest: testing 2 page read speed 513 504 root D 1164 0% 57% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 26% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 21% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 23% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 24% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 25% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 23% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: 2 page read speed is 9361 KiB/s mtd_speedtest: Testing erase speed mtd_speedtest: erase speed is 167411 KiB/s mtd_speedtest: Testing 2x multi-block erase speed mtd_speedtest: 2x multi-block erase speed is 326808 KiB/s mtd_speedtest: Testing 4x multi-block erase speed 513 504 root R 1164 0% 74% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: 4x multi-block erase speed is 301176 KiB/s mtd_speedtest: Testing 8x multi-block erase speed mtd_speedtest: 8x multi-block erase speed is 326808 KiB/s mtd_speedtest: Testing 16x multi-block erase speed mtd_speedtest: 16x multi-block erase speed is 328556 KiB/s mtd_speedtest: Testing 32x multi-block erase speed mtd_speedtest: 32x multi-block erase speed is 328556 KiB/s mtd_speedtest: Testing 64x multi-block erase speed mtd_speedtest: 64x multi-block erase speed is 325079 KiB/s mtd_speedtest: finished ================================================= case 2: NFC with DMA: ================================================= mtd_speedtest: MTD device: 2 mtd_speedtest: MTD device size 62914560, eraseblock size 131072, page size 2048, count of eraseblocks 480, pages per eraseblock 64, OOB size 64 mtd_speedtest: scanning for bad eraseblocks mtd_speedtest: scanned 480 eraseblocks, 0 are bad top -n 130 -d 1 | grep speedtest mtd_speedtest: testing eraseblock write speed 514 504 root R 1164 0% 8% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 12% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 10% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 13% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root D 1164 0% 15% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root D 1164 0% 14% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 11% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 9% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 15% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 11% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 15% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 12% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: eraseblock write speed is 5105 KiB/s mtd_speedtest: testing eraseblock read speed 514 504 root R 1164 0% 14% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 20% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 17% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 8% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 6% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 15% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: eraseblock read speed is 9512 KiB/s 514 504 root R 1164 0% 6% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: testing page write speed 514 504 root R 1164 0% 17% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 20% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 13% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 12% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 14% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 17% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 11% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 22% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 17% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 14% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 17% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: page write speed is 4989 KiB/s mtd_speedtest: testing page read speed 514 504 root R 1164 0% 16% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 13% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 17% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 16% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 18% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 19% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 16% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: page read speed is 9340 KiB/s mtd_speedtest: testing 2 page write speed 514 504 root R 1164 0% 20% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 10% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 14% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 16% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 15% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 12% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 16% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 18% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 15% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 16% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 17% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 13% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: 2 page write speed is 5043 KiB/s mtd_speedtest: testing 2 page read speed 514 504 root R 1164 0% 8% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 9% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 14% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 12% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 12% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 15% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: 2 page read speed is 9426 KiB/s mtd_speedtest: Testing erase speed 514 504 root R 1164 0% 12% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: erase speed is 157943 KiB/s mtd_speedtest: Testing 2x multi-block erase speed mtd_speedtest: 2x multi-block erase speed is 308743 KiB/s mtd_speedtest: Testing 4x multi-block erase speed mtd_speedtest: 4x multi-block erase speed is 313469 KiB/s mtd_speedtest: Testing 8x multi-block erase speed mtd_speedtest: 8x multi-block erase speed is 313469 KiB/s mtd_speedtest: Testing 16x multi-block erase speed mtd_speedtest: 16x multi-block erase speed is 315076 KiB/s mtd_speedtest: Testing 32x multi-block erase speed 514 504 root R 1164 0% 12% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: 32x multi-block erase speed is 298252 KiB/s mtd_speedtest: Testing 64x multi-block erase speed mtd_speedtest: 64x multi-block erase speed is 311878 KiB/s mtd_speedtest: finished ================================================= </pre> Josh Wu 2013-06-19T06:23:11 http://comments.gmane.org/gmane.linux.drivers.mtd/47002 <pre>Hi all, I've a question regarding a PC that needs to boot from CFC (Compact Flash card), hope this is the correct place to ask. I would need a PC to boot from a CFC-card that has R/W enabled. At this time I have been testing it with EXT2/EXT3 but when POWERING down abruptly it seems that the CFC-ext2/ext3 file system gets corrupted, finally resulting in a NON bootable system. At this time I have partitioned the CFC into 2 partitions 1-FAT16 (to store the kernel) and 1-ext2/ext3 partition that has the root-file system. What would be the correct file-system (and/or mount /build options) to put on a CFC ... so that it is able to survive abrupt-power downs ? Or is the somewhere a guide (URL) that explains me some more stuff regarding this. Thanks and Regards, Noel ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ </pre> Vellemans, Noel 2013-06-20T06:55:49 http://comments.gmane.org/gmane.linux.drivers.mtd/47001 <pre>I have will my estate to you for the work of humanity, for more information contact Attorney Newton Blackwell on email: npowell&lt; at &gt;rogers.com ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ </pre> Alec Duncan 2013-06-20T05:06:36 http://comments.gmane.org/gmane.linux.drivers.mtd/46997 <pre> Our current reference Linux kernel for the MAX32590 (JIBE) is based on v2.6.36. (Unfortunately, upgrading to a more recent version is not within the timeframe for solving the current problem.) Our recent reference boards use one of those Micron NAND chips with an on-die 4-bit ECC, which we have basically ignored: To-date, we have simply used the usual 1-bit ECC (i.e., living dangerously!). This must change, and indeed we now have a case on my desk where, had we been using the on-die ECC, it would have saved us a ton of grief. The problem is our kernel version is far too old to take advantage of any of the recent-ish work for on-die ECC. Hence, I am looking into the possibility of adding on-die ECC support to our JIBE controller driver specifically for such NAND chips (or at least the specific Micron NAND chip on the reference boards). Broadly, pretending JIBE's H/W directly supports on-die ECC, but actually doing the work in the driver. A similar trick we played in the past (bitwise-inverted ECC (now obsoleted and long-removed from the driver)) suggests this is not too difficult. I am looking for hints (suggestions), gotchas (warnings), and/or any examples of similar (or other plausible) approaches. Or for something I am overlooking in (or available for) kernels of approximately the vintage we are using. Thanks &amp; cheers! -blf- p.s. At the present time, I am not too interested in the problem of converting existing boards. This MAY change as the scope and details of the solution become more apparent. </pre> Brian Foster 2013-06-19T14:14:53 http://comments.gmane.org/gmane.linux.drivers.mtd/46989 <pre>This patch series enable NFC support for SAMA5 soc. It can send command, address cycles automaticly. Also when enable NFC sram, NFC will transfer data to sram. Which can save lots of cpu time. The mtd speed test results (non-NFC vs NFC), run in sama5d3x-ek with DMA enable, is in the end of this patch. v3 --&gt; v4: 1) refine the commit message for ofpart.c patch and also change the description in partition.txt 2) remove len parameter for ofpart.c's change. 3) use devm_ioremap_resource instead of devm_requrest_and_ioremap. 4) add BIT_POS macro definition for magic number. v2 --&gt; v3: 1) Change the dts usage for NFC. Now use a NFC child node of atmel nand to enable NFC driver. In this way the atmel nand driver will include a NFC driver, which will be probed if dts has NFC node. 2) can enable/disable NFC write by sram in dts. 3) merged J.C's patch(use devm_xxx to simple the code) in this series. 4) remove unused NFC register definitions. Change the definition names. 5) trival fix accroding to J.C's suggestion. 6) modify the ofpart.c for child node check. If the child node has compatible property then this node is a device not a partition. v1 --&gt; v2: 1) rebase it with latest l2-mtd git tree: - remove useless nand commands (NAND_CMD_DEPLETE1, NAND_CMD_STATUS_ERRORx). - adopt to the new nand write function's parameters. Add error message when handle subpage write via nfc sram. 2) rewrite pmecc_enable function. Now I use exist NAND_ECC_READ/WRITE const instead of using a new enum definition. Jean-Christophe PLAGNIOL-VILLARD (1): MTD: atmel_nand: use devm_xxx gpio kzalloc, gpio and ioremap Josh Wu (5): mtd: atmel_nand: replace pmecc enable code with one function. mtd: atmel_nand: add Nand Flash Controller (NFC) support mtd: atmel_nand: enable Nand Flash Controller (NFC) read data via sram mtd: atmel_nand: enable Nand Flash Controller (NFC) write via sram mtd: ofpart: add compatible check for child nodes .../devicetree/bindings/mtd/atmel-nand.txt | 28 + .../devicetree/bindings/mtd/partition.txt | 1 + drivers/mtd/nand/atmel_nand.c | 876 ++++++++++++++++---- drivers/mtd/nand/atmel_nand_nfc.h | 98 +++ drivers/mtd/ofpart.c | 13 +- 5 files changed, 853 insertions(+), 163 deletions(-) create mode 100644 drivers/mtd/nand/atmel_nand_nfc.h mtd_speedtest is run in 60M partition with DMA enabled for two cases: 1. Using NFC and sram read/write with DMA enabled. 2. Using Non-NFC with DMA enabled. Summary of the two test results: 1. With NFC and sram read/write enabled, the write speed will become %10 slower and the cpu load also is reduce a lot (50% -&gt; 20%): Non-NFC NFC Page write Speed: 5536KiB : 46% ~ 64% --&gt; 4989KiB : 13% ~ 22% 2 Page write speed: 5567KiB : 52% ~ 69% --&gt; 5043KiB : 10% ~ 20% 2. With NFC and sram read/write enabled, the read speed is almost same and the cpu load is reduced (30% -&gt; 15%): Non-NFC NFC Page read Speed: 9361KiB : %24 ~ 46% --&gt; 9340KiB : 13% ~ 19% 2 Page read Speed: 9361KiB : %21 ~ 57% --&gt; 9426KiB : 8% ~ 15% Following is the detail test log: case 1: Non-NFC with DMA: ================================================= mtd_speedtest: MTD device: 2 mtd_speedtest: MTD device size 62914560, eraseblock size 131072, page size 2048, count of eraseblocks 480, pages per eraseblock 64, OOB size 64 mtd_speedtest: scanning for bad eraseblocks mtd_speedtest: scanned 480 eraseblocks, 0 are bad mtd_speedtest: testing eraseblock write speed top -n 130 -d 1 | grep speedtest 513 504 root R 1164 0% 62% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root D 1164 0% 53% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 57% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 58% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 53% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 60% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 55% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 55% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 59% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 57% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 62% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: eraseblock write speed is 5594 KiB/s mtd_speedtest: testing eraseblock read speed 513 504 root R 1164 0% 27% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 14% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 5% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 1% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 2% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 1% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: eraseblock read speed is 9442 KiB/s mtd_speedtest: testing page write speed 513 504 root R 1164 0% 46% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 64% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 57% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 64% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 56% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 59% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 59% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 56% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 59% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 62% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 60% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: page write speed is 5536 KiB/s mtd_speedtest: testing page read speed 513 504 root R 1164 0% 46% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 24% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 30% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 30% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 26% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 25% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: page read speed is 9361 KiB/s 513 504 root R 1164 0% 24% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: testing 2 page write speed 513 504 root R 1164 0% 69% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 56% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 57% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 61% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 55% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 61% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 55% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 52% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 55% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 58% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: 2 page write speed is 5567 KiB/s mtd_speedtest: testing 2 page read speed 513 504 root D 1164 0% 57% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 26% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 21% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 23% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 24% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 25% insmod /root/mtd_test/mtd_speedtest.ko 513 504 root R 1164 0% 23% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: 2 page read speed is 9361 KiB/s mtd_speedtest: Testing erase speed mtd_speedtest: erase speed is 167411 KiB/s mtd_speedtest: Testing 2x multi-block erase speed mtd_speedtest: 2x multi-block erase speed is 326808 KiB/s mtd_speedtest: Testing 4x multi-block erase speed 513 504 root R 1164 0% 74% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: 4x multi-block erase speed is 301176 KiB/s mtd_speedtest: Testing 8x multi-block erase speed mtd_speedtest: 8x multi-block erase speed is 326808 KiB/s mtd_speedtest: Testing 16x multi-block erase speed mtd_speedtest: 16x multi-block erase speed is 328556 KiB/s mtd_speedtest: Testing 32x multi-block erase speed mtd_speedtest: 32x multi-block erase speed is 328556 KiB/s mtd_speedtest: Testing 64x multi-block erase speed mtd_speedtest: 64x multi-block erase speed is 325079 KiB/s mtd_speedtest: finished ================================================= case 2: NFC with DMA: ================================================= mtd_speedtest: MTD device: 2 mtd_speedtest: MTD device size 62914560, eraseblock size 131072, page size 2048, count of eraseblocks 480, pages per eraseblock 64, OOB size 64 mtd_speedtest: scanning for bad eraseblocks mtd_speedtest: scanned 480 eraseblocks, 0 are bad top -n 130 -d 1 | grep speedtest mtd_speedtest: testing eraseblock write speed 514 504 root R 1164 0% 8% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 12% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 10% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 13% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root D 1164 0% 15% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root D 1164 0% 14% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 11% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 9% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 15% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 11% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 15% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 12% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: eraseblock write speed is 5105 KiB/s mtd_speedtest: testing eraseblock read speed 514 504 root R 1164 0% 14% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 20% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 17% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 8% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 6% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 15% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: eraseblock read speed is 9512 KiB/s 514 504 root R 1164 0% 6% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: testing page write speed 514 504 root R 1164 0% 17% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 20% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 13% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 12% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 14% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 17% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 11% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 22% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 17% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 14% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 17% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: page write speed is 4989 KiB/s mtd_speedtest: testing page read speed 514 504 root R 1164 0% 16% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 13% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 17% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 16% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 18% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 19% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 16% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: page read speed is 9340 KiB/s mtd_speedtest: testing 2 page write speed 514 504 root R 1164 0% 20% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 10% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 14% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 16% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 15% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 12% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 16% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 18% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 15% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 16% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 17% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 13% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: 2 page write speed is 5043 KiB/s mtd_speedtest: testing 2 page read speed 514 504 root R 1164 0% 8% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 9% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 14% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 12% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 12% insmod /root/mtd_test/mtd_speedtest.ko 514 504 root R 1164 0% 15% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: 2 page read speed is 9426 KiB/s mtd_speedtest: Testing erase speed 514 504 root R 1164 0% 12% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: erase speed is 157943 KiB/s mtd_speedtest: Testing 2x multi-block erase speed mtd_speedtest: 2x multi-block erase speed is 308743 KiB/s mtd_speedtest: Testing 4x multi-block erase speed mtd_speedtest: 4x multi-block erase speed is 313469 KiB/s mtd_speedtest: Testing 8x multi-block erase speed mtd_speedtest: 8x multi-block erase speed is 313469 KiB/s mtd_speedtest: Testing 16x multi-block erase speed mtd_speedtest: 16x multi-block erase speed is 315076 KiB/s mtd_speedtest: Testing 32x multi-block erase speed 514 504 root R 1164 0% 12% insmod /root/mtd_test/mtd_speedtest.ko mtd_speedtest: 32x multi-block erase speed is 298252 KiB/s mtd_speedtest: Testing 64x multi-block erase speed mtd_speedtest: 64x multi-block erase speed is 311878 KiB/s mtd_speedtest: finished ================================================= </pre> Josh Wu 2013-06-19T06:23:11 http://comments.gmane.org/gmane.linux.drivers.mtd/46951 <pre>Dear UBIFS developers Kernel version : 2.6.37-2.8 Nand : Micron MT29F32G08CBACA (4GB, MLC) Hi, I am using ubifs for 4GB MLC nandflash and basic working is well done. But some issue torture me. I untar large file sometimes. But there are wide variations in untar speed. I spend 5~15 min(in sync mode) for 150MB file to untar. even spend 25 min for same file. Why is this happening? Of course I read ubi and ubifs documentations. (http://www.linux-mtd.infradead.org/doc) And I read "Does UBIFS become slower when it is full?" (http://www.linux-mtd.infradead.org/faq/ubifs.html#L_slow_when_full) But my nandflash is not close to full. I have 1.5GB more available capacity. I wonder that ubifs io performance is consistency or not. Please help me some tips for in this case. I need to be consistency for io operations. Thanks for reading my short English. Respectfully yours ________________________________ The above message is intended solely for the named addressee and may contain trade secret and confidential information otherwise protected under applicable law. Any unauthorized dissemination or use of the information contained in this communication is strictly prohibited. If you have received this communication in error, please notify the sender by email and delete this communication immediately. The Future of SmartTV and Connected Home... KaonMedia Co. Ltd. www.kaonmedia.com&lt;http://www.kaonmedia.com&gt; ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ </pre> 서기석[Seo Ki Seok] 2013-06-14T02:18:42 http://comments.gmane.org/gmane.linux.drivers.mtd/46947 <pre>Hi, I am using TI OMAP AM3517 with Linux 2.6.32. From time to time I see errors when I update mtd partitions i use the following commands flash_eraseall -j /dev/mtd10 mount -t jffs2 /dev/mtdblock10 /tmp/nand cd nand tar -xzf rootfs.tar.gz the erase operation goes successfully, however I see the following errors at the time of mount/writing ,ffffffff} JFFS2 notice: (429) jffs2_get_inode_nodes: Node header CRC failed at 0xe1018d4. {ffff,ffff,ffffffff,ffffffff} JFFS2 notice: (429) jffs2_get_inode_nodes: Node header CRC failed at 0xe101690. {ffff,ffff,ffffffff,ffffffff} JFFS2 notice: (429) jffs2_get_inode_nodes: Node header CRC failed at 0xe10144c. {ffff,ffff,ffffffff,ffffffff} JFFS2 notice: (429) jffs2_get_inode_nodes: Node header CRC failed at 0xe101208. {ffff,ffff,ffffffff,ffffffff} JFFS2 notice: (429) jffs2_get_inode_nodes: Node header CRC failed at 0xe100fc4. {ffff,ffff,ffffffff,ffffffff} JFFS2 notice: (429) jffs2_get_inode_nodes: Node header CRC failed at 0xe100d80. {ffff,ffff,ffffffff,ffffffff} JFFS2 notice: (429) jffs2_get_inode_nodes: Node header CRC failed at 0xe100b3c. {ffff,ffff,ffffffff,ffffffff} JFFS2 notice: (429) jffs2_get_inode_nodes: Node header CRC failed at 0xe100000. {ffff,ffff,ffffffff,ffffffff} and finally, I see the following messages before I get the command prompt JFFS2 warning: (429) jffs2_do_read_inode_internal: no data nodes found for ino #11487 Returned error for crccheck of ino #11487. Expect badness... Header CRC failed on REF_PRISTINE node at 0x11f57414: Read 0xffffffff, calculated 0x44660075 Header CRC failed on REF_PRISTINE node at 0x11f57ba8: Read 0xffffffff, calculated 0x44660075 Header CRC failed on REF_PRISTINE node at 0x11f5abfc: Read 0xffffffff, calculated 0x44660075 Node CRC ffffffff != calculated CRC f09e7845 for node at 11f5adfc read of old metadata failed in jffs2_garbage_collect_metadata(): -5 Error garbage collecting node at 11f5adfc! No space for garbage collection. Aborting GC thread Node CRC ffffffff != calculated CRC f09e7845 for node at 11f5adfc read of old metadata failed in jffs2_garbage_collect_metadata(): -5 Error garbage collecting node at 11f5adfc! Node CRC ffffffff != calculated CRC f09e7845 for node at 11f5adfc read of old metadata failed in jffs2_garbage_collect_metadata(): -5 Error garbage collecting node at 11f5adfc! Node CRC ffffffff != calculated CRC f09e7845 for node at 11f5adfc read of old metadata failed in jffs2_garbage_collect_metadata(): -5 Error garbage collecting node at 11f5adfc! One more thing I found is that the target keeps throwing the following messages. root&lt; at &gt;ti-omap3-am3517-evm:/tmp# Node CRC ffffffff != calculated CRC f09e7845 for node at 11f5adfc read of old metadata failed in jffs2_garbage_collect_metadata(): -5 Error garbage collecting node at 11f5adfc! Also, when I type some of the commands it fails with the errors root&lt; at &gt;ti-omap3-am3517-evm:/tmp# umount nand JFFS2 warning: (1183) jffs2_get_inode_nodes: Eep. No valid nodes for ino #11253. JFFS2 warning: (1183) jffs2_do_read_inode_internal: no data nodes found for ino #11253 iget() failed for ino #11253 -bash: umount: command not found I would really appreciate your comments to fix this. -- Thanks &amp; Regards Harsh ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ </pre> harsh poshtiwala 2013-06-13T18:58:43 http://comments.gmane.org/gmane.linux.drivers.mtd/46938 <pre>Hi, we try the following: 1) setup some data in an 8kByte block in RAM 2) frequently modify this data during normal operation 3) on a power fail signal write the block to a file on an UBIFS partition 4) recover from the written data after the power cut The time between power failure notification and the uP-reset is guaranteed by hardware and is about 20ms. We first thought about using fallocate() to allocate a corresponding block on the partition but soon found that UBIFS does not implement a native fallocate() and thus the generic one simply wrote the file to 8k of zeros. This of course will not help. Simply fsync()ing the file in case of a power cut does not seem reliable, for - the file system might be full - write back cache operation may interfere with the synch-ing of our file - the garbage collector might run to free dirty LEBs and erase the corresponding PEBs The latter 2 overstretching our timing requirements. This is on an embedded system (i.mx31, arm1136&lt; at &gt;532MHz) running Linux 3.something (we are quite flexible in adapting new kernel versions), currently testing on 3.0.45. Could someone hint the course to follow for this szenario? Any pointers appreciated, Helmut -- Scanned by MailScanner. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ </pre> Helmut Raiger 2013-06-13T11:42:18 http://comments.gmane.org/gmane.linux.drivers.mtd/46917 <pre>From: avinash philip &lt;avinashphilip&lt; at &gt;ti.com&gt; Support for pm_runtime add to GPMC driver. Signed-off-by: Philip Avinash &lt;avinashphilip&lt; at &gt;ti.com&gt; Signed-off-by: Pekon Gupta &lt;pekon&lt; at &gt;ti.com&gt; --- arch/arm/mach-omap2/gpmc.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index fb6f241..1380cee 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c &lt; at &gt;&lt; at &gt; -30,6 +30,7 &lt; at &gt;&lt; at &gt; #include &lt;linux/of_mtd.h&gt; #include &lt;linux/of_device.h&gt; #include &lt;linux/mtd/nand.h&gt; +#include &lt;linux/pm_runtime.h&gt; #include &lt;linux/platform_data/mtd-nand-omap2.h&gt; &lt; at &gt;&lt; at &gt; -1594,7 +1595,8 &lt; at &gt;&lt; at &gt; static int gpmc_probe(struct platform_device *pdev) return PTR_ERR(gpmc_l3_clk); } -clk_prepare_enable(gpmc_l3_clk); +pm_runtime_enable(&amp;pdev-&gt;dev); +pm_runtime_get_sync(&amp;pdev-&gt;dev); gpmc_dev = &amp;pdev-&gt;dev; &lt; at &gt;&lt; at &gt; -1634,7 +1636,7 &lt; at &gt;&lt; at &gt; static int gpmc_probe(struct platform_device *pdev) rc = gpmc_probe_dt(pdev); if (rc &lt; 0) { -clk_disable_unprepare(gpmc_l3_clk); +pm_runtime_put_sync(&amp;pdev-&gt;dev); clk_put(gpmc_l3_clk); dev_err(gpmc_dev, "failed to probe DT parameters\n"); return rc; &lt; at &gt;&lt; at &gt; -1647,6 +1649,8 &lt; at &gt;&lt; at &gt; static int gpmc_remove(struct platform_device *pdev) { gpmc_free_irq(); gpmc_mem_exit(); +pm_runtime_put_sync(&amp;pdev-&gt;dev); +pm_runtime_disable(&amp;pdev-&gt;dev); gpmc_dev = NULL; return 0; } </pre> Pekon Gupta 2013-06-12T10:50:33 http://comments.gmane.org/gmane.linux.drivers.mtd/46908 <pre>Hi, I am working on qspi flash device S25FL256S at u-boot level. I am trying to make use of the existing spi_flash.c framework available at u-boot for erasing/reading/writing into the flash device. There are several issues(mentioned below), which I faced while using S25FL256s flash device with my dra7xx board which has a qspi controller to which the above mentioned flash device is attached. 1. Erase (spi_flash_cmd_erase) Issuing a command something like this.. sf erase 0x0 0x50000 - erases only first 0x20000 bytes of flash device, anything above that is not erase. I need to issue separate commands after 0x20000 for every 0x10000 bytes. Am i missing anything here? 2. read sf read 81000000 0 0x10000 Read is not happening properly. The last few byte along the 4k boundary always shows zero. Above 4k bytes, read is not happening. For ex: DRA752 EVM # md 81000f00 81000f00: ffffffff ffffffff ffffffff ffffffff ................ 81000f10: ffffffff ffffffff ffffffff ffffffff ................ 81000f20: ffffffff ffffffff ffffffff ffffffff ................ 81000f30: ffffffff ffffffff ffffffff ffffffff ................ 81000f40: ffffffff ffffffff ffffffff ffffffff ................ 81000f50: ffffffff ffffffff ffffffff ffffffff ................ 81000f60: ffffffff ffffffff ffffffff ffffffff ................ 81000f70: ffffffff ffffffff ffffffff ffffffff ................ 81000f80: ffffffff ffffffff ffffffff ffffffff ................ 81000f90: ffffffff ffffffff ffffffff ffffffff ................ 81000fa0: ffffffff ffffffff ffffffff ffffffff ................ 81000fb0: ffffffff ffffffff ffffffff ffffffff ................ 81000fc0: ffffffff ffffffff ffffffff ffffffff ................ 81000fd0: ffffffff ffffffff ffffffff ffffffff ................ 81000fe0: ffffffff ffffffff ffffffff ffffffff ................ 81000ff0: ffffffff ffffffff 00ffffff 00000000 ................ In this dump, if you see 81000ff0 the last column shows 000000 which is not expected. and it happens along every 4k bytes. So, to get rid of the above issue, I switched to page read with the below patch[1], which is giving me the correct result. [1]: &lt; at &gt;&lt; at &gt; -147,17 +153,40 &lt; at &gt;&lt; at &gt; int spi_flash_read_common(struct spi_flash *flash, const u8 *cmd, int spi_flash_cmd_read_fast(struct spi_flash *flash, u32 offset, size_t len, void *data) { - u8 cmd[5]; + unsigned long page_addr, byte_addr, page_size; + size_t chunk_len, actual; + int ret = 0; + u8 cmd[4]; /* Handle memory-mapped SPI */ if (flash-&gt;memory_map) memcpy(data, flash-&gt;memory_map + offset, len); + page_size = flash-&gt;page_size; + page_addr = offset / page_size; + byte_addr = offset % page_size; + + cmd[0] = CMD_READ_ARRAY_SLOW; + for (actual = 0; actual &lt; len; actual += chunk_len) { + chunk_len = min(len - actual, page_size - byte_addr); + + cmd[1] = page_addr &gt;&gt; 8; + cmd[2] = page_addr; + cmd[3] = byte_addr; + + ret = spi_flash_read_common(flash, cmd, sizeof(cmd), data + actual, chunk_len); + if (ret &lt; 0) { + debug("SF: read failed"); + break; + } - cmd[0] = CMD_READ_ARRAY_FAST; - spi_flash_addr(offset, cmd); - cmd[4] = 0x00; + byte_addr += chunk_len; + if (byte_addr == page_size) { + page_addr++; + byte_addr = 0; + } + } - return spi_flash_read_common(flash, cmd, sizeof(cmd), data, len); + return ret; } Any idea about this? 3. write (spi_flash_cmd_write_multi) write not happening properly. observations: only able to write single page, anything after a page is not getting written. Workaround: I did a write disable latch at the end of every write cycle(page program) and enable it again for the next loop. With this, I see I get rid of the above issue. &lt; at &gt;&lt; at &gt; -117,6 +117,12 &lt; at &gt;&lt; at &gt; int spi_flash_cmd_write_multi(struct spi_flash *flash, u32 offset, if (ret) break; + ret = spi_flash_cmd_write_disable(flash); + if (ret &lt; 0) { + printf("SF: disabling write failed\n"); + break; + } + Have anyone seen the above mentioned issues regarding read/write/erase? OR is there any configurations that I might be missing ? ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ </pre> Sourav Poddar 2013-06-12T07:30:16 http://comments.gmane.org/gmane.linux.drivers.mtd/46893 <pre>This patch fixes some issues in the error handling and simplifies the code by converting to devm* functions. If the kzalloc call fails it is unnecessary to use the label no_res and pass a NULL pointer to kfree. If the devm_kzalloc call fails on line 110 we forget to call iounmap for the previous ioremap call. The following changes are introduced: - Convert to devm_kzalloc and remove calls to kfree. - Convert to devm_ioremap_resource that adds a missing call to *request_mem_region and remove calls to iounmap. - The devm_ioremap_resource function checks the passed resource so we can remove the NULL check after the platform_get_resource call. Signed-off-by: Emil Goode &lt;emilgoode&lt; at &gt;gmail.com&gt; --- This patch is only build tested v2: Fix change log typo and remove error messages for kzalloc calls drivers/mtd/nand/orion_nand.c | 49 +++++++++++++---------------------------- 1 file changed, 15 insertions(+), 34 deletions(-) diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c index 8fbd002..76b9fba 100644 --- a/drivers/mtd/nand/orion_nand.c +++ b/drivers/mtd/nand/orion_nand.c &lt; at &gt;&lt; at &gt; -85,35 +85,24 &lt; at &gt;&lt; at &gt; static int __init orion_nand_probe(struct platform_device *pdev) int ret = 0; u32 val = 0; -nc = kzalloc(sizeof(struct nand_chip) + sizeof(struct mtd_info), GFP_KERNEL); -if (!nc) { -printk(KERN_ERR "orion_nand: failed to allocate device structure.\n"); -ret = -ENOMEM; -goto no_res; -} +nc = devm_kzalloc(&amp;pdev-&gt;dev, sizeof(struct nand_chip) + + sizeof(struct mtd_info), GFP_KERNEL); +if (!nc) +return -ENOMEM; + mtd = (struct mtd_info *)(nc + 1); res = platform_get_resource(pdev, IORESOURCE_MEM, 0); -if (!res) { -ret = -ENODEV; -goto no_res; -} - -io_base = ioremap(res-&gt;start, resource_size(res)); -if (!io_base) { -printk(KERN_ERR "orion_nand: ioremap failed\n"); -ret = -EIO; -goto no_res; -} +io_base = devm_ioremap_resource(&amp;pdev-&gt;dev, res); +if (IS_ERR(io_base)) +return PTR_ERR(io_base); if (pdev-&gt;dev.of_node) { board = devm_kzalloc(&amp;pdev-&gt;dev, sizeof(struct orion_nand_data), -GFP_KERNEL); -if (!board) { -printk(KERN_ERR "orion_nand: failed to allocate board structure.\n"); -ret = -ENOMEM; -goto no_res; -} + GFP_KERNEL); +if (!board) +return -ENOMEM; + if (!of_property_read_u32(pdev-&gt;dev.of_node, "cle", &amp;val)) board-&gt;cle = (u8)val; else &lt; at &gt;&lt; at &gt; -167,7 +156,7 &lt; at &gt;&lt; at &gt; static int __init orion_nand_probe(struct platform_device *pdev) if (nand_scan(mtd, 1)) { ret = -ENXIO; -goto no_dev; +goto disable_clk; } mtd-&gt;name = "orion_nand"; &lt; at &gt;&lt; at &gt; -176,20 +165,17 &lt; at &gt;&lt; at &gt; static int __init orion_nand_probe(struct platform_device *pdev) board-&gt;parts, board-&gt;nr_parts); if (ret) { nand_release(mtd); -goto no_dev; +goto disable_clk; } return 0; -no_dev: +disable_clk: if (!IS_ERR(clk)) { clk_disable_unprepare(clk); clk_put(clk); } platform_set_drvdata(pdev, NULL); -iounmap(io_base); -no_res: -kfree(nc); return ret; } &lt; at &gt;&lt; at &gt; -197,15 +183,10 &lt; at &gt;&lt; at &gt; no_res: static int orion_nand_remove(struct platform_device *pdev) { struct mtd_info *mtd = platform_get_drvdata(pdev); -struct nand_chip *nc = mtd-&gt;priv; struct clk *clk; nand_release(mtd); -iounmap(nc-&gt;IO_ADDR_W); - -kfree(nc); - clk = clk_get(&amp;pdev-&gt;dev, NULL); if (!IS_ERR(clk)) { clk_disable_unprepare(clk); </pre> Emil Goode 2013-06-10T00:00:42 http://comments.gmane.org/gmane.linux.drivers.mtd/46887 <pre>It's better to use actual device name as a prefix in error messages. Signed-off-by: Andy Shevchenko &lt;andy.shevchenko&lt; at &gt;gmail.com&gt; --- drivers/mtd/nand/orion_nand.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c index 8fbd002..ba38853 100644 --- a/drivers/mtd/nand/orion_nand.c +++ b/drivers/mtd/nand/orion_nand.c &lt; at &gt;&lt; at &gt; -87,7 +87,7 &lt; at &gt;&lt; at &gt; static int __init orion_nand_probe(struct platform_device *pdev) nc = kzalloc(sizeof(struct nand_chip) + sizeof(struct mtd_info), GFP_KERNEL); if (!nc) { -printk(KERN_ERR "orion_nand: failed to allocate device structure.\n"); +dev_err(&amp;pdev-&gt;dev, "failed to allocate device structure.\n"); ret = -ENOMEM; goto no_res; } &lt; at &gt;&lt; at &gt; -101,7 +101,7 &lt; at &gt;&lt; at &gt; static int __init orion_nand_probe(struct platform_device *pdev) io_base = ioremap(res-&gt;start, resource_size(res)); if (!io_base) { -printk(KERN_ERR "orion_nand: ioremap failed\n"); +dev_err(&amp;pdev-&gt;dev, "ioremap failed\n"); ret = -EIO; goto no_res; } &lt; at &gt;&lt; at &gt; -110,7 +110,8 &lt; at &gt;&lt; at &gt; static int __init orion_nand_probe(struct platform_device *pdev) board = devm_kzalloc(&amp;pdev-&gt;dev, sizeof(struct orion_nand_data), GFP_KERNEL); if (!board) { -printk(KERN_ERR "orion_nand: failed to allocate board structure.\n"); +dev_err(&amp;pdev-&gt;dev, +"failed to allocate board structure.\n"); ret = -ENOMEM; goto no_res; } </pre> Andy Shevchenko 2013-06-09T21:16:54 http://comments.gmane.org/gmane.linux.drivers.mtd/46878 <pre>From: Julia Lawall &lt;Julia.Lawall&lt; at &gt;lip6.fr&gt; The argument to kfree should not be the address of a structure field. The argument is adjusted to correspond to what is found in the subsequent remove function. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // &lt;smpl&gt; &lt; at &gt;&lt; at &gt; expression e; identifier f; &lt; at &gt;&lt; at &gt; * kfree(&amp;e-&gt;f) // &lt;/smpl&gt; Signed-off-by: Julia Lawall &lt;Julia.Lawall&lt; at &gt;lip6.fr&gt; --- drivers/mtd/devices/bcm47xxsflash.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/devices/bcm47xxsflash.c b/drivers/mtd/devices/bcm47xxsflash.c index 2060856..59848e7 100644 --- a/drivers/mtd/devices/bcm47xxsflash.c +++ b/drivers/mtd/devices/bcm47xxsflash.c &lt; at &gt;&lt; at &gt; -155,7 +155,7 &lt; at &gt;&lt; at &gt; static int bcm47xxsflash_bcma_probe(struct platform_device *pdev) return 0; err_dev_reg: -kfree(&amp;b47s-&gt;mtd); +kfree(b47s); out: return err; } ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ </pre> Julia Lawall 2013-06-08T15:36:23 http://comments.gmane.org/gmane.linux.drivers.mtd/46873 <pre>Could someone explain why the following situation might occur: In drivers/mtd/nand/nand_base.c, we have: int nand_scan_tail(struct mtd_info *mtd) { int i; struct nand_chip *chip = mtd-&gt;priv; /* New bad blocks should be marked in OOB, flash-based BBT, or both */ BUG_ON((chip-&gt;bbt_options &amp; NAND_BBT_NO_OOB_BBM) &amp;&amp; !(chip-&gt;bbt_options &amp; NAND_BBT_USE_FLASH)); if (!(chip-&gt;options &amp; NAND_OWN_BUFFERS)) chip-&gt;buffers = kmalloc(sizeof(*chip-&gt;buffers), GFP_KERNEL); if (!chip-&gt;buffers) return -ENOMEM; ... For some reason, the kmalloc always fails on my configuration/hardware (arch-vt8500: WonderMedia/VIA APC8750). The strange thing is that if I add the NAND_OWN_BUFFERS option, and allocate my own buffers in the driver probe everything is fine. Driver probe code below: priv-&gt;nand.buffers = devm_kzalloc(priv-&gt;dev, sizeof(*priv-&gt;nand.buffers), GFP_KERNEL); if (!priv-&gt;nand.buffers) { dev_err(priv-&gt;dev, "failed to allocate NAND buffers\n"); return -ENOMEM; } The devm_kzalloc does occur earlier than the nand_scan_tail alloc would have, but there doesn't appear to be a shortage of memory on the platform so I don't think it's failing for a memory shortage. Is there any real difference between using kmalloc and devm_kzalloc to allocate the buffer (other than the obvious 0'ing of the buffer)? Why would one call fail and the other succeed? Regards Tony Prisk ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ </pre> Tony Prisk 2013-06-07T09:03:26 http://comments.gmane.org/gmane.linux.drivers.mtd/46871 <pre>On one of our products, we have 2 64Mbit NOR devices:- one to hold the kernel, filesystem, etc, and the other to store "user" data. The gotcha is that the "user" data is stored using our own wear levelling code, with read / write / erase operations being carried out on the raw flash device. We are now designing a new CPU board with a single 1Gbit Spansion NOR part on it, rather than the 2 separate devices. I am planning to allocate 512Mbit to the "system" partitions (eg bootloader, kernel, filesystem) and have the other 512Mbit as the "data" partition. Currently our wear levelling code uses mmap() to gain direct access to the flash chip, which is not an issue, since all filesystem updates etc are all carried out on the completely separate chip (via jffs2). What I would like to know is, when the "system" and "user" partitions reside on the *same" flash device, if I read/write directly to the "user" partition, how do I maintain the jffs2 integrity on other "system" partitions that may be doing their own read/write/erase operations ? If I can't read/write directly, can the same be achieved using the mtd character device using something like:- fd = open("/dev/mtd4", ..); seek(fd, 1234); write(fd, buff, ...); ...etc... If I need to "manually" erase a sector on our custom data partition, how can that be handled without disrupting any jffs2 flash access on the other "system" partitions ? Do the mtd ioctl() functions handle all the flash locking for me ? Or is this a bit hole I'm digging for myself ? Thanks for any help anyone can offer. Regards Mark J. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ </pre> Mark Jackson 2013-06-06T19:18:09 http://comments.gmane.org/gmane.linux.drivers.mtd/46851 <pre>These timeout initializations are arbitrary and pointless. We simply overwrite them with new values anyway. (In one case, the variable is not ever even used, so we kill it.) Signed-off-by: Brian Norris &lt;computersforpeace&lt; at &gt;gmail.com&gt; --- drivers/mtd/chips/cfi_cmdset_0002.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c index 89b9d68..6c85f61 100644 --- a/drivers/mtd/chips/cfi_cmdset_0002.c +++ b/drivers/mtd/chips/cfi_cmdset_0002.c &lt; at &gt;&lt; at &gt; -1146,7 +1146,6 &lt; at &gt;&lt; at &gt; static int cfi_amdstd_read (struct mtd_info *mtd, loff_t from, size_t len, size_ static inline int do_read_secsi_onechip(struct map_info *map, struct flchip *chip, loff_t adr, size_t len, u_char *buf) { DECLARE_WAITQUEUE(wait, current); -unsigned long timeo = jiffies + HZ; struct cfi_private *cfi = map-&gt;fldrv_priv; retry: &lt; at &gt;&lt; at &gt; -1160,7 +1159,6 &lt; at &gt;&lt; at &gt; static inline int do_read_secsi_onechip(struct map_info *map, struct flchip *chi schedule(); remove_wait_queue(&amp;chip-&gt;wq, &amp;wait); -timeo = jiffies + HZ; goto retry; } &lt; at &gt;&lt; at &gt; -1228,7 +1226,7 &lt; at &gt;&lt; at &gt; static int cfi_amdstd_secsi_read (struct mtd_info *mtd, loff_t from, size_t len, static int __xipram do_write_oneword(struct map_info *map, struct flchip *chip, unsigned long adr, map_word datum) { struct cfi_private *cfi = map-&gt;fldrv_priv; -unsigned long timeo = jiffies + HZ; +unsigned long timeo; /* * We use a 1ms + 1 jiffies generic timeout for writes (most devices * have a max write time of a few hundreds usec). However, we should &lt; at &gt;&lt; at &gt; -1466,7 +1464,7 &lt; at &gt;&lt; at &gt; static int __xipram do_write_buffer(struct map_info *map, struct flchip *chip, int len) { struct cfi_private *cfi = map-&gt;fldrv_priv; -unsigned long timeo = jiffies + HZ; +unsigned long timeo; /* see comments in do_write_oneword() regarding uWriteTimeo. */ unsigned long uWriteTimeout = ( HZ / 1000 ) + 1; int ret = -EIO; &lt; at &gt;&lt; at &gt; -1900,7 +1898,7 &lt; at &gt;&lt; at &gt; static int cfi_amdstd_panic_write(struct mtd_info *mtd, loff_t to, size_t len, static int __xipram do_erase_chip(struct map_info *map, struct flchip *chip) { struct cfi_private *cfi = map-&gt;fldrv_priv; -unsigned long timeo = jiffies + HZ; +unsigned long timeo; unsigned long int adr; DECLARE_WAITQUEUE(wait, current); int ret = 0; &lt; at &gt;&lt; at &gt; -1990,7 +1988,7 &lt; at &gt;&lt; at &gt; static int __xipram do_erase_chip(struct map_info *map, struct flchip *chip) static int __xipram do_erase_oneblock(struct map_info *map, struct flchip *chip, unsigned long adr, int len, void *thunk) { struct cfi_private *cfi = map-&gt;fldrv_priv; -unsigned long timeo = jiffies + HZ; +unsigned long timeo; DECLARE_WAITQUEUE(wait, current); int ret = 0; </pre> Brian Norris 2013-06-04T01:46:44 http://comments.gmane.org/gmane.linux.drivers.mtd/46844 <pre>Register a MTD LED trigger called "mtd-disk" (similar to the "ide-disk" and "nand-disk" triggers) to indicate read / write / erase acitivity. Panic writes and OOB reads / writes are not covered as of now. The trigger is global as it does not discriminate between individual devices or partitions. The patch uses the generic LED trigger interface which can be configured via SYSFS (/sys/class/leds/&lt;name&gt;/trigger) or DTS file entry for "gpio-leds" (linux,default-trigger = "mtd-disk"). Since the MTD framework is independant of the memory devices, driver-specific LED triggers like "nand-disk" will indicate a subset of all MTD activity. Tested on Microblaze architecture with Micron N25Q256A serial flash. Added a bit of documentation (including other new LED triggers). Signed-off-by: Jens Renner &lt;renner at efe-gmbh.de&gt; --- Changes in v2: - fix whitespace problem drivers/mtd/mtdcore.c | 25 ++++++++++++++++++-- Documentation/devicetree/bindings/leds/common.txt | 4 ++++ 2 files changed, 27 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c index c400c57..fbf1ed8 100644 --- a/drivers/mtd/mtdcore.c +++ b/drivers/mtd/mtdcore.c &lt; at &gt;&lt; at &gt; -37,6 +37,7 &lt; at &gt;&lt; at &gt; #include &lt;linux/backing-dev.h&gt; #include &lt;linux/gfp.h&gt; #include &lt;linux/slab.h&gt; +#include &lt;linux/leds.h&gt; #include &lt;linux/mtd/mtd.h&gt; #include &lt;linux/mtd/partitions.h&gt; &lt; at &gt;&lt; at &gt; -100,6 +101,8 &lt; at &gt;&lt; at &gt; static LIST_HEAD(mtd_notifiers); #define MTD_DEVT(index) MKDEV(MTD_CHAR_MAJOR, (index)*2) +DEFINE_LED_TRIGGER(mtd_led_trigger); + /* REVISIT once MTD uses the driver model better, whoever allocates * the mtd_info will probably want to use the release() hook... */ &lt; at &gt;&lt; at &gt; -727,6 +730,7 &lt; at &gt;&lt; at &gt; EXPORT_SYMBOL_GPL(__put_mtd_device); */ int mtd_erase(struct mtd_info *mtd, struct erase_info *instr) { +int ret_code; if (instr-&gt;addr &gt; mtd-&gt;size || instr-&gt;len &gt; mtd-&gt;size - instr-&gt;addr) return -EINVAL; if (!(mtd-&gt;flags &amp; MTD_WRITEABLE)) &lt; at &gt;&lt; at &gt; -737,7 +741,11 &lt; at &gt;&lt; at &gt; int mtd_erase(struct mtd_info *mtd, struct erase_info *instr) mtd_erase_callback(instr); return 0; } -return mtd-&gt;_erase(mtd, instr); +led_trigger_event(mtd_led_trigger, LED_FULL); +ret_code = mtd-&gt;_erase(mtd, instr); +led_trigger_event(mtd_led_trigger, LED_OFF); + +return ret_code; } EXPORT_SYMBOL_GPL(mtd_erase); &lt; at &gt;&lt; at &gt; -800,12 +808,17 &lt; at &gt;&lt; at &gt; int mtd_read(struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, if (!len) return 0; +led_trigger_event(mtd_led_trigger, LED_FULL); + /* * In the absence of an error, drivers return a non-negative integer * representing the maximum number of bitflips that were corrected on * any one ecc region (if applicable; zero otherwise). */ ret_code = mtd-&gt;_read(mtd, from, len, retlen, buf); + +led_trigger_event(mtd_led_trigger, LED_OFF); + if (unlikely(ret_code &lt; 0)) return ret_code; if (mtd-&gt;ecc_strength == 0) &lt; at &gt;&lt; at &gt; -817,6 +830,7 &lt; at &gt;&lt; at &gt; EXPORT_SYMBOL_GPL(mtd_read); int mtd_write(struct mtd_info *mtd, loff_t to, size_t len, size_t *retlen, const u_char *buf) { +int ret_code; *retlen = 0; if (to &lt; 0 || to &gt; mtd-&gt;size || len &gt; mtd-&gt;size - to) return -EINVAL; &lt; at &gt;&lt; at &gt; -824,7 +838,11 &lt; at &gt;&lt; at &gt; int mtd_write(struct mtd_info *mtd, loff_t to, size_t len, size_t *retlen, return -EROFS; if (!len) return 0; -return mtd-&gt;_write(mtd, to, len, retlen, buf); +led_trigger_event(mtd_led_trigger, LED_FULL); +ret_code = mtd-&gt;_write(mtd, to, len, retlen, buf); +led_trigger_event(mtd_led_trigger, LED_OFF); + +return ret_code; } EXPORT_SYMBOL_GPL(mtd_write); &lt; at &gt;&lt; at &gt; -1187,6 +1205,8 &lt; at &gt;&lt; at &gt; static int __init init_mtd(void) if (ret) goto out_procfs; +led_trigger_register_simple("mtd-disk", &amp;mtd_led_trigger); + return 0; out_procfs: &lt; at &gt;&lt; at &gt; -1205,6 +1225,7 &lt; at &gt;&lt; at &gt; err_reg: static void __exit cleanup_mtd(void) { +led_trigger_unregister_simple(mtd_led_trigger); cleanup_mtdchar(); if (proc_mtd) remove_proc_entry("mtd", NULL); diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt index 2d88816..9875cd2 100644 --- a/Documentation/devicetree/bindings/leds/common.txt +++ b/Documentation/devicetree/bindings/leds/common.txt &lt; at &gt;&lt; at &gt; -12,6 +12,10 &lt; at &gt;&lt; at &gt; Optional properties for child nodes: property in Documentation/devicetree/bindings/gpio/led.txt) "heartbeat" - LED "double" flashes at a load average based rate "ide-disk" - LED indicates disk activity + "mtd-disk" - LED indicates MTD activity + "nand-disk" - LED indicates NAND activity + "mmc&lt;n&gt;" - LED indicates activity of SD/MMC #n (e.g. "mmc0") + "cpu&lt;n&gt;" - LED indicates activity of CPU #n (e.g. "cpu0") "timer" - LED flashes at a fixed, configurable rate Examples: ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ </pre> Jens Renner (EFE 2013-06-02T15:53:13 http://comments.gmane.org/gmane.linux.drivers.mtd/46843 <pre>The usage of strict_strtoul() is not preferred, because strict_strtoul() is obsolete. Thus, kstrtoul() should be used. Signed-off-by: Jingoo Han &lt;jg1.han&lt; at &gt;samsung.com&gt; --- drivers/mtd/mtdswap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/mtdswap.c b/drivers/mtd/mtdswap.c index c92f0f6..8b33b26 100644 --- a/drivers/mtd/mtdswap.c +++ b/drivers/mtd/mtdswap.c &lt; at &gt;&lt; at &gt; -1425,7 +1425,7 &lt; at &gt;&lt; at &gt; static void mtdswap_add_mtd(struct mtd_blktrans_ops *tr, struct mtd_info *mtd) return; while ((this_opt = strsep(&amp;parts, ",")) != NULL) { -if (strict_strtoul(this_opt, 0, &amp;part) &lt; 0) +if (kstrtoul(this_opt, 0, &amp;part) &lt; 0) return; if (mtd-&gt;index == part) </pre> Jingoo Han 2013-06-01T07:17:37 http://comments.gmane.org/gmane.linux.drivers.mtd/46840 <pre>The loop that polls the status register after a write or erase operation is a simple loop that is independent of the processor clock rate. This bit of sloppiness came back to bite me when I increased the clock rate and timeouts started occurring. This patch cleans this up by basing the timeout on jiffies. Signed-off-by: Mike Dunn &lt;mikedunn&lt; at &gt;newsguy.com&gt; --- This is a rework of an earlier patch, based on Artem's suggestion to use jiffies. I did not call it 'v2' because the original description is no longer correct (udelay() is not used in this patch). Thanks Artem. drivers/mtd/nand/docg4.c | 15 ++++++--------- 1 files changed, 6 insertions(+), 9 deletions(-) diff --git a/drivers/mtd/nand/docg4.c b/drivers/mtd/nand/docg4.c index fa25e7a..6c3be21 100644 --- a/drivers/mtd/nand/docg4.c +++ b/drivers/mtd/nand/docg4.c &lt; at &gt;&lt; at &gt; -44,6 +44,7 &lt; at &gt;&lt; at &gt; #include &lt;linux/mtd/nand.h&gt; #include &lt;linux/bch.h&gt; #include &lt;linux/bitrev.h&gt; +#include &lt;linux/jiffies.h&gt; /* * In "reliable mode" consecutive 2k pages are used in parallel (in some &lt; at &gt;&lt; at &gt; -269,7 +270,7 &lt; at &gt;&lt; at &gt; static int poll_status(struct docg4_priv *doc) */ uint16_t flash_status; -unsigned int timeo; +unsigned long timeo; void __iomem *docptr = doc-&gt;virtadr; dev_dbg(doc-&gt;dev, "%s...\n", __func__); &lt; at &gt;&lt; at &gt; -277,22 +278,18 &lt; at &gt;&lt; at &gt; static int poll_status(struct docg4_priv *doc) /* hardware quirk requires reading twice initially */ flash_status = readw(docptr + DOC_FLASHCONTROL); -timeo = 1000; +timeo = jiffies + msecs_to_jiffies(200); /* generous timeout */ do { cpu_relax(); flash_status = readb(docptr + DOC_FLASHCONTROL); -} while (!(flash_status &amp; DOC_CTRL_FLASHREADY) &amp;&amp; --timeo); +} while (!(flash_status &amp; DOC_CTRL_FLASHREADY) &amp;&amp; + time_before(jiffies, timeo)); - -if (!timeo) { +if (unlikely(!(flash_status &amp; DOC_CTRL_FLASHREADY))) { dev_err(doc-&gt;dev, "%s: timed out!\n", __func__); return NAND_STATUS_FAIL; } -if (unlikely(timeo &lt; 50)) -dev_warn(doc-&gt;dev, "%s: nearly timed out; %d remaining\n", - __func__, timeo); - return 0; } </pre> Mike Dunn 2013-05-31T18:00:31 http://comments.gmane.org/gmane.linux.drivers.mtd/46833 <pre> Hello. I have a problem with attach NAND UBI in 16 bit mode. NAND works fine if I specify NAND_BUSWIDTH_16 option, but not working with NAND_BUSWIDTH_AUTO option. In second case NAND chip is identifyed with ONFI. Logs below. Can anyone help me with this issue? Is it a known problem? Thanks. PS: Kernel 3.9.3 New chip, first start, NAND_BUSWIDTH_AUTO: ONFI param page 0 valid ONFI flash detected NAND device: Manufacturer ID: 0x2c, Chip ID: 0xca (Micron MT29F2G16ABAEAWP), 256MiB, page size: 2048, OOB size: 64 Scanning device for bad blocks Creating 1 MTD partitions on "MT29F2G16ABAEAWP": 0x000000000000-0x000010000000 : "nand-gpio" UBI: attaching mtd4 to ubi0 UBI: scanning is finished UBI: empty MTD device detected UBI: attached mtd4 (name "nand-gpio", size 256 MiB) to ubi0 UBI: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512 UBI: VID header offset: 512 (aligned 512), data offset: 2048 UBI: good PEBs: 2048, bad PEBs: 0, corrupted PEBs: 0 UBI: user volume: 0, internal volumes: 1, max. volumes count: 128 UBI: max/mean erase counter: 0/0, WL threshold: 4096, image sequence number: 2920475650 UBI: available PEBs: 2004, total reserved PEBs: 44, PEBs reserved for bad PEB handling: 40 UBI: background thread "ubi_bgt0d" started, PID 22 sync &amp;&amp; reboot: ONFI param page 0 valid ONFI flash detected NAND device: Manufacturer ID: 0x2c, Chip ID: 0xca (Micron MT29F2G16ABAEAWP), 256MiB, page size: 2048, OOB size: 64 Scanning device for bad blocks Creating 1 MTD partitions on "MT29F2G16ABAEAWP": 0x000000000000-0x000010000000 : "nand-gpio" UBI: attaching mtd4 to ubi0 UBI: fixable bit-flip detected at PEB 2 UBI: fixable bit-flip detected at PEB 3 UBI: fixable bit-flip detected at PEB 4 UBI: fixable bit-flip detected at PEB 5 UBI: fixable bit-flip detected at PEB 6 UBI: fixable bit-flip detected at PEB 7 ... NAND_BUSWIDTH_16: Trying ONFI probe in 16 bits mode, aborting ! NAND device: Manufacturer ID: 0x2c, Chip ID: 0xca (Micron NAND 256MiB 3,3V 16-bit), 256MiB, page size: 2048, OOB size: 64 Scanning device for bad blocks Creating 1 MTD partitions on "NAND 256MiB 3,3V 16-bit": 0x000000000000-0x000010000000 : "nand-gpio" UBI: attaching mtd4 to ubi0 UBI: scanning is finished UBI: empty MTD device detected UBI: attached mtd4 (name "nand-gpio", size 256 MiB) to ubi0 UBI: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512 UBI: VID header offset: 512 (aligned 512), data offset: 2048 UBI: good PEBs: 2048, bad PEBs: 0, corrupted PEBs: 0 UBI: user volume: 0, internal volumes: 1, max. volumes count: 128 UBI: max/mean erase counter: 0/0, WL threshold: 4096, image sequence number: 2573182024 UBI: available PEBs: 2004, total reserved PEBs: 44, PEBs reserved for bad PEB handling: 40 UBI: background thread "ubi_bgt0d" started, PID 23 --- ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ </pre> Alexander Shiyan 2013-05-30T12:07:08 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.drivers.mtd