- 07 Nov, 2013 40 commits
-
-
Pekon Gupta authored
OMAP NAND driver support multiple ECC scheme, which can used in different flavours, depending on in-build Hardware engines present on SoC. This patch updates following in DT bindings related to sectionion of ecc-schemes - ti,elm-id: replaces elm_id (maintains backward compatibility) - ti,nand-ecc-opts: selection of h/w or s/w implementation of an ecc-scheme depends on ti,elm-id. (supported values ham1, bch4, and bch8) - maintain backward compatibility to deprecated DT bindings (sw, hw, hw-romcode) Below table shows different flavours of ecc-schemes supported by OMAP devices +---------------------------------------+---------------+---------------+ | ECC scheme |ECC calculation|Error detection| +---------------------------------------+---------------+---------------+ |OMAP_ECC_HAM1_CODE_HW |H/W (GPMC) |S/W | +---------------------------------------+---------------+---------------+ |OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W | |(requires CONFIG_MTD_NAND_ECC_BCH) | | | +---------------------------------------+---------------+---------------+ |OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) | |(requires CONFIG_MTD_NAND_OMAP_BCH && | | | | ti,elm-id in DT) | | | +---------------------------------------+---------------+---------------+ To optimize footprint of omap2-nand driver, selection of some ECC schemes also require enabling following Kconfigs, in addition to setting appropriate DT bindings - Kconfig:CONFIG_MTD_NAND_ECC_BCH error detection done in software - Kconfig:CONFIG_MTD_NAND_OMAP_BCH error detection done by h/w engine Signed-off-by:
Pekon Gupta <pekon@ti.com> Reviewed-by:
Felipe Balbi <balbi@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Tested-by:
Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by:
Brian Norris <computersforpeace@gmail.com>
-
Brian Norris authored
It seems like the following commit was never necessary commit 5f949137 Author: Shaohui Xie <Shaohui.Xie@freescale.com> Date: Fri Oct 14 15:49:00 2011 +0800 mtd: m25p80: don't probe device which has status of 'disabled' because it duplicates the code in of_platform_device_create_pdata() which ensures that 'disabled' nodes are never instantiated. Also, drop the __maybe_unused. Signed-off-by:Sourav Poddar <sourav.poddar@ti.com> Reviewed-by:
Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <rob.herring@calxeda.com> Cc: <devicetree@vger.kernel.org>
-
Brian Norris authored
Remove the compile-time option for FAST_READ, since we have run-time support for detecting it. This refactors the logic for enabling fast-read, such that for DT-enabled devices, we honor the "m25p,fast-read" property but for non-DT devices, we default to using FAST_READ whenever the flash device supports it. Normal READ and FAST_READ differ only in the following: * FAST_READ supports SPI higher clock frequencies [1] * number of dummy cycles; FAST_READ requires 8 dummy cycles (whereas READ requires 0) to allow the flash sufficient setup time, even when running at higher clock speeds Thus, for flash chips which support FAST_READ, there is otherwise no limiting reason why we cannot use the FAST_READ opcode instead of READ. It simply allows the SPI controller to run at higher clock rates. So theoretically, nobody should be needing the compile-time option anyway. [1] I have a Spansion S25FL128S datasheet which says: "The maximum operating clock frequency for the READ command is 50 MHz." And: "The maximum operating clock frequency for FAST READ command is 133 MHz." Signed-off-by: -
Brian Norris authored
No change in the table data. Signed-off-by:
-
Brian Norris authored
The FIXME and NOTE have already been fixed (we have FAST_READ support). Signed-off-by:
Marek Vasut <marex@denx.de>
-
Brian Norris authored
This patch fixes two memory errors: 1. During a probe failure (in mtd_device_parse_register?) the command buffer would not be freed. 2. The command buffer's size is determined based on the 'fast_read' boolean, but the assignment of fast_read is made after this allocation. Thus, the buffer may be allocated "too small". To fix the first, just switch to the devres version of kzalloc. To fix the second, increase MAX_CMD_SIZE unconditionally. It's not worth saving a byte to fiddle around with the conditions here. This problem was reported by Yuhang Wang a while back. Signed-off-by:
Yuhang Wang <wangyuhang2014@gmail.com> Reviewed-by:
-
Huang Shijie authored
In the imx6, all the ready/busy pins are binding togeter. So we should always check the ready/busy pin of the chip 0. In the other word, when the CS1 is enabled, we should also check the ready/busy of chip 0; if we check the ready/busy of chip 1, we will get the wrong result. Signed-off-by:
Huang Shijie <b32955@freescale.com> Signed-off-by:
-
Huang Shijie authored
Some nand chip has two DIEs in a single chip, such as Micron MT29F32G08QAA. Each die has its own chip select pin, so this chip acts as two nand chips. If we only scan one chip, we may find that we only get 2G for this chip, but in actually, this chip's size is 4G. So scan two chips by default. Signed-off-by:
-
Huang Shijie authored
We only have one DMA channel : the channel 0. Use DMA channel 0 to access all the nand chips. Signed-off-by:
-
Huang Shijie authored
Decouple the chip select from the DMA channel, we use the DMA channel 0 to accecc all the nand devices. Signed-off-by:
-
Prabhakar Kushwaha authored
as per controller description, "While programming a NAND flash, status read should never skipped. Because it may happen that a new command is issued to the NAND Flash, even when the device has not yet finished processing the previous request. This may result in unpredictable behaviour." IFC controller never polls for R/B signal after command send. It just return control to software. This behaviour may not occur with NAND flash access. because new commands are sent after polling R/B signal. But it may happen in scenario where GPCM-ASIC and NAND flash device are working simultaneously. Update the controller driver to take care of this requirement Signed-off-by:
Prabhakar Kushwaha <prabhakar@freescale.com> Signed-off-by:
-
Prabhakar Kushwaha authored
Current IFC driver supports till 4K page size NAND flash. Add support of 8K Page size NAND flash - Add nand_ecclayout for 4 bit & 8 bit ecc - Defines constants - also fix ecc.strength for 8bit ecc of 8K page size NAND Signed-off-by:
-
Wang Haitao authored
Hardware: CPU: XLP832,the 64-bit OS NOR Flash:S29GL128S 128M Software: Kernel:2.6.32.41 Filesystem:JFFS2 When writing files, errors appear: Write len 182 but return retlen 180 Write of 182 bytes at 0x072c815c failed. returned -5, retlen 180 Write len 186 but return retlen 184 Write of 186 bytes at 0x072caff4 failed. returned -5, retlen 184 These errors exist only in 64-bit systems,not in 32-bit systems. After analysis, we found that the left shift operation is wrong in map_word_load_partial. For instance: unsigned char buf[3] ={0x9e,0x3a,0xea}; map_bankwidth(map) is 4; for (i=0; i < 3; i++) { int bitpos; bitpos = (map_bankwidth(map)-1-i)*8; orig.x[0] &= ~(0xff << bitpos); orig.x[0] |= buf[i] << bitpos; } The value of orig.x[0] is expected to be 0x9e3aeaff, but in this situation(64-bit System) we'll get the wrong value of 0xffffffff9e3aeaff due to the 64-bit sign extension: buf[i] is defined as "unsigned char" and the left-shift operation will convert it to the type of "signed int", so when left-shift buf[i] by 24 bits, the final result will get the wrong value: 0xffffffff9e3aeaff. If the left-shift bits are less than 24, then sign extension will not occur. Whereas the bankwidth of the nor flash we used is 4, therefore this BUG emerges. Signed-off-by:Pang Xunlei <pang.xunlei@zte.com.cn> Signed-off-by:
Zhang Yi <zhang.yi20@zte.com.cn> Signed-off-by:
Lu Zhongjun <lu.zhongjun@zte.com.cn> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Ezequiel Garcia authored
This patch moves the char and block major number definitions to major.h to be with the rest of the major numbers. While doing this, include major.h in the files that need it. Signed-off-by:
-
Rafał Miłecki authored
A new type of partition with magic FCTY was found on Huawei E970: 46 43 54 59 4b 51 37 4e 41 42 31 38 41 32 39 30 |FCTYKQ7NAB18A290| Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
Rafał Miłecki authored
Most of the bcm47xx devices use TRX format for storing kernel and some partition like Squashfs or JFFS2. This is pretty flexible solution, CFE (the bootloader) just writes (and later boots) TRX at some hardcoded place and paritions can vary in the size. However some devices don't use TRX format. Very recently we have discovered ZTE H218N that has kernel and rootfs partitions at some "random" places. This patch allows Linux find a rootfs partition after installing custom image with a CFE bootloader. Signed-off-by:
-
Hauke Mehrtens authored
Handle return NULL in malloc. Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
-
Sachin Kamat authored
devm_kzalloc is device managed and simplifies the code. Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by:
-
Sachin Kamat authored
module_platform_driver simplifies the code by removing boiler plate. Signed-off-by:
-
Sachin Kamat authored
module_platform_driver simplifies the code by removing boiler plate. Signed-off-by:
-
Brian Norris authored
Some bright specification writers decided to write this in the ONFI spec (from ONFI 3.0, Section 3.1): "The number of blocks and number of pages per block is not required to be a power of two. In the case where one of these values is not a power of two, the corresponding address shall be rounded to an integral number of bits such that it addresses a range up to the subsequent power of two value. The host shall not access upper addresses in a range that is shown as not supported." This breaks every assumption MTD makes about NAND block/chip-size dimensions -- they *must* be a power of two! And of course, an enterprising manufacturer has made use of this lovely freedom. Exhibit A: Micron MT29F32G08CBADAWP "- Plane size: 2 planes x 1064 blocks per plane - Device size: 32Gb: 2128 blockss [sic]" This quickly hits a BUG() in nand_base.c, since the extra dimensions overflow so we think it's a second chip (on my single-chip setup): ONFI param page 0 valid ONFI flash detected NAND device: Manufacturer ID: 0x2c, Chip ID: 0x44 (Micron MT29F32G08CBADAWP), 4256MiB, page size: 8192, OOB size: 744 ------------[ cut here ]------------ kernel BUG at drivers/mtd/nand/nand_base.c:203! Internal error: Oops - BUG: 0 [#1] SMP ARM [... trim ...] [<c02cf3e4>] (nand_select_chip+0x18/0x2c) from [<c02d25c0>] (nand_do_read_ops+0x90/0x424) [<c02d25c0>] (nand_do_read_ops+0x90/0x424) from [<c02d2dd8>] (nand_read+0x54/0x78) [<c02d2dd8>] (nand_read+0x54/0x78) from [<c02ad2c8>] (mtd_read+0x84/0xbc) [<c02ad2c8>] (mtd_read+0x84/0xbc) from [<c02d4b28>] (scan_read.clone.4+0x4c/0x64) [<c02d4b28>] (scan_read.clone.4+0x4c/0x64) from [<c02d4c88>] (search_bbt+0x148/0x290) [<c02d4c88>] (search_bbt+0x148/0x290) from [<c02d4ea4>] (nand_scan_bbt+0xd4/0x5c0) [... trim ...] ---[ end trace 0c9363860d865ff2 ]--- So to fix this, just truncate these dimensions down to the greatest power-of-2 dimension that is less than or equal to the specified dimension. Signed-off-by: -
Ezequiel Garcia authored
This commit replaces the currently hardcoded buffer size, by a dynamic detection scheme. First a small 256 bytes buffer is allocated so the device can be detected (using READID and friends commands). After detection, this buffer is released and a new buffer is allocated to acommodate the page size plus out-of-band size. Signed-off-by:
Daniel Mack <zonque@gmail.com> Signed-off-by:
-
Ezequiel Garcia authored
Instead of setting info->dma each time a command is prepared, we can move it after the DMA buffers are allocated. This is more clear and it's the proper place to enable this, given DMA cannot be turned on and off during runtime. Signed-off-by:
-
Priyanka Jain authored
Micron N25Q512A is a spi flash memory with following features: -64MB size, 1.8V, Mulitple I/O, 4KB Sector erase memory. -Memory is organised as 1024(64KB) main sectors. -Each sector is divided into 256 pages. -Register set/Opcodes are similar to other N25Q family products. Signed-off-by:
Priyanka Jain <Priyanka.Jain@freescale.com> Acked-by:
-
Wei Yongjun authored
Use free_bch() instead of kfree() to free init_bch() allocated data. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Acked-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Mike Dunn authored
The loop that polls the status register waiting for an operation to complete foolishly bases the timeout simply on the number of loop iterations that have ocurred. When I increased the processor clock speed, timeouts started to appear for long block erasure operations. This patch measures the timeout using jiffies. Signed-off-by:
Mike Dunn <mikedunn@newsguy.com> Signed-off-by:
-
Sachin Kamat authored
dev_err is preferred to printk. Signed-off-by:
-
Sachin Kamat authored
devm_kzalloc is device managed and makes code simpler. Signed-off-by:
-
Sachin Kamat authored
Driver core will set the driver data to NULL upon detach or probe failure. Signed-off-by:
-
Sachin Kamat authored
module_platform_driver removes boiler plate code and makes it simpler. Signed-off-by:
-
Sachin Kamat authored
Driver core will set the driver data to NULL upon detach or probe failure. Signed-off-by:
-
Sachin Kamat authored
devm_kzalloc is device managed and makes code simpler. Signed-off-by:
-
Sachin Kamat authored
Driver core will set the driver data to NULL upon detach or probe failure. Signed-off-by:
-
Ezequiel Garcia authored
Signed-off-by:
-
Sachin Kamat authored
The data structure of_match_ptr() protects is always compiled in. Hence of_match_ptr() is not needed. Signed-off-by:
-
Sachin Kamat authored
The data structure of_match_ptr() protects is always compiled in. Hence of_match_ptr() is not needed. Signed-off-by:
-
Sachin Kamat authored
The data structure of_match_ptr() protects is always compiled in. Hence of_match_ptr() is not needed. Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure. 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. 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. Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
-
