- 05 Aug, 2013 40 commits
-
-
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 <josh.wu@atmel.com> Acked-by:
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by:
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com>
-
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 <akinobu.mita@gmail.com> 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:Brian Norris <computersforpeace@gmail.com> 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:
-
Josh Wu authored
Atmel PMECC support 2, 4, 8, 12, 24 bit error correction. So if the ecc requirement in ONFI is <= 2, 4, 8, 12, 24. We will use 2, 4, 8, 12, 24. This patch fix the typo. Use '<=' replace '<'. Reported-by:
Scott Wood <scottwood@freescale.com> Signed-off-by:
-
Brian Norris authored
The code for NAND_BUSWIDTH_AUTO is broken. According to Alexander: "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." See his report for the rest of the details: http://lists.infradead.org/pipermail/linux-mtd/2013-July/047515.html Anyway, the problem is that nand_set_defaults() is called twice, we intend it to reset the chip functions to their x16 buswidth verions if the buswidth changed from x8 to x16; however, nand_set_defaults() does exactly nothing if called a second time. Fix this by hacking nand_set_defaults() to reset the buswidth-dependent functions if they were set to the x8 version the first time. Note that this does not do anything to reset from x16 to x8, but that's not the supported use case for NAND_BUSWIDTH_AUTO anyway. Signed-off-by:
Alexander Shiyan <shc_work@mail.ru> Tested-by:
-
Michael Opdenacker authored
This patch proposes to remove kernel configuration parameters defined in drivers/mtd/devices/Kconfig, but used nowhere in the makefiles and source code (except in comments). Signed-off-by:
Michael Opdenacker <michael.opdenacker@free-electrons.com> Acked-by:
Kees Cook <keescook@chromium.org> Acked-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Kees Cook authored
This reduces the size of the stack frame when calling request_module(). Performing the sprintf before the call is not needed. Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Reviewed-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
-
Wolfram Sang authored
Since commit ab78029e (drivers/pinctrl: grab default handles from device core), we can rely on device core for setting the default pins. Compile tested only. Acked-by: Linus Walleij <linus.walleij@linaro.org> (personally at LCE13) Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Wolfram Sang authored
Since commit ab78029e (drivers/pinctrl: grab default handles from device core), we can rely on device core for setting the default pins. Compile tested only. Acked-by: Linus Walleij <linus.walleij@linaro.org> (personally at LCE13) Signed-off-by:
-
Fabio Estevam authored
devm_ioremap_resource() checks its arguments, so there is no need for explicitly checking the return value from platform_get_resource(). Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
-
Paul Bolle authored
JEDEC device support was removed in v2.6.22. (It had been marked as BROKEN (indirectly) since at least v2.6.12.) When it was removed the two JEDEC mapping drivers that depended on it should have been removed too. Do so now. Signed-off-by:
Paul Bolle <pebolle@tiscali.nl> Acked-by:
-
Richard Genoud authored
We don't have to issue a warning when a stronger error correcting capability is chosen. Signed-off-by:
Richard Genoud <richard.genoud@gmail.com> Acked-by:
-
avinash philip authored
ELM is used for locating bit-flip errors in when using BCH ECC scheme. This patch adds suspend/resume support for leaf level ELM driver, And also provides ELM register context save & restore support, so that configurations are preserved across hardware power-off/on transitions. Signed-off-by:
Philip Avinash <avinashphilip@ti.com> Signed-off-by:
Pekon Gupta <pekon@ti.com> Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
Marc Kleine-Budde <mkl@blackshift.org> Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d063 (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
-
