- 10 Mar, 2016 3 commits
-
-
Archit Taneja authored
The Qualcomm NAND controller is found in SoCs like IPQ806x, MSM7xx, MDM9x15 series. It exists as a sub block inside the IPs EBI2 (External Bus Interface 2) and QPIC (Qualcomm Parallel Interface Controller). These IPs provide a broader interface for external slow peripheral devices such as LCD and NAND/NOR flash memory or SRAM like interfaces. We add support for the NAND controller found within EBI2. For the SoCs of our interest, we only use the NAND controller within EBI2. Therefore, it's safe for us to assume that the NAND controller is a standalone block within the SoC. The controller supports 512B, 2kB, 4kB and 8kB page 8-bit and 16-bit NAND flash devices. It contains a HW ECC block that supports BCH ECC (4, 8 and 16 bit correction/step) and RS ECC(4 bit correction/step) that covers main and spare data. The controller contains an internal 512 byte page buffer to which we read/write via DMA. The EBI2 type NAND controller uses ADM DMA for register read/write and data transfers. The controller performs page reads and writes at a codeword/step level of 512 bytes. It can support up to 2 external chips of different configurations. The driver prepares register read and write configuration descriptors for each codeword, followed by data descriptors to read or write data from the controller's internal buffer. It uses a single ADM DMA channel that we get via dmaengine API. The controller requires 2 ADM CRCIs for command and data flow control. These are passed via DT. The ecc layout used by the controller is syndrome like, but we can't use the standard syndrome ecc ops because of several reasons. First, the amount of data bytes covered by ecc isn't same in each step. Second, writing to free oob space requires us writing to the entire step in which the oob lies. This forces us to create our own ecc ops. One more difference is how the controller accesses the bad block marker. The controller ignores reading the marker when ECC is enabled. ECC needs to be explicity disabled to read or write to the bad block marker. The nand_bbt helpers library hence can't access BBMs for the controller. For now, we skip the creation of BBT and populate chip->block_bad and chip->block_markbad helpers instead. Reviewed-by:
Andy Gross <agross@codeaurora.org> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
Archit Taneja <architt@codeaurora.org> Reviewed-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
Brian Norris <computersforpeace@gmail.com>
-
Archit Taneja authored
Add DT bindings document for the Qualcomm NAND controller driver. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Archit Taneja authored
One of the arguments passed to struct nand_chip's block_bad op is 'getchip', which, if true, is supposed to get and select the nand device, and later unselect and release the device. This op is intended to be replaceable by drivers. The drivers shouldn't be responsible for selecting/unselecting chip. Like other ops, the chip should already be selected before the block_bad op is called. Remove the getchip argument from the block_bad op and nand_block_checkbad. Move the chip selection to nand_block_isbad, since it is the only caller to nand_block_checkbad which requires chip selection. Modify nand_block_bad (the default function for the op) such that it doesn't select the chip. Remove the getchip argument from the bad_block funcs in cafe_nand, diskonchip and docg4 drivers. Reviewed-by:
-
- 08 Mar, 2016 12 commits
-
-
Brian Norris authored
These are recent Winbond models that are known to have lock/unlock support via writing the Status Register, and that also support the TB (Top/Bottom) protection bit. Tested on w25q32dw. [Note on style: these entries are getting pretty long lines, so I picked a style that seems reasonable for splitting up the flags separate from the other mostly-similar fields.] Signed-off-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Tested-by:
-
Brian Norris authored
Some flash support a bit in the status register that inverts protection so that it applies to the bottom of the flash, not the top. This yields additions to the protection range table, as noted in the comments. Because this feature is not universal to all flash that support lock/unlock, control it via a new flag. Signed-off-by:
-
Brian Norris authored
We can't determine this purely by manufacturer type (see commit 67b9bcd3 ("mtd: spi-nor: fix Spansion regressions (aliased with Winbond)")), and it's not autodetectable by anything like SFDP. So make a new flag for it. Signed-off-by:
-
Brian Norris authored
It's a little easier to read and make sure there are no collisions (IMO). Signed-off-by:
-
Brian Norris authored
Locking the flash is most useful if it provides real hardware security. Otherwise, it's little more than a software permission bit. A reasonable use case that provides real HW security might be like follows: (1) hardware WP# is deasserted (2) program flash (3) flash range is protected via status register (4) hardware WP# is asserted (5) flash protection range can no longer be changed, until WP# is deasserted In this way, flash protection is co-owned by hardware and software. Now, one would expect to be able to perform step (3) with ioctl(MEMLOCK), except that the spi-nor driver does not set the Status Register Protect bit (a.k.a. Status Register Write Disable (SRWD)), so even though the range is now locked, it does not satisfy step (5) -- it can still be changed by a call to ioctl(MEMUNLOCK). So, let's enable status register protection after the first lock command, and disable protection only when the flash is fully unlocked. Signed-off-by: -
Brian Norris authored
There are a few different corner cases to the current logic that seem undesirable: * mtd_lock() with offs==0 trips a bounds issue on ofs - mtd->erasesize < 0 * mtd_unlock() on the middle of a flash that is already unlocked will return -EINVAL * probably other corner cases So, let's stop doing "smart" checks like "check the block below us", let's just do the following: (a) pass only non-negative offsets/lengths to stm_is_locked_sr() (b) add a similar stm_is_unlocked_sr() function, so we can check if the *entire* range is unlocked (and not just whether some part of it is unlocked) Then armed with (b), we can make lock() and unlock() much more symmetric: (c) short-circuit the procedure if there is no work to be done, and (d) check the entire range above/below This also aligns well with the structure needed for proper TB (Top/Bottom) support. Signed-off-by: -
Brian Norris authored
If, for instance, the entire flash is already unlocked and I try to mtd_unlock() the entire device, I don't expect to see an EINVAL error. It should just silently succeed. Ditto for mtd_lock(). Signed-off-by:
-
Brian Norris authored
Fixup a piece leftover by commit 32321e95 ("mtd: spi-nor: wait until lock/unlock operations are ready"). That commit made us wait for the WIP bit to settle after lock/unlock operations, but it missed the open-coded "unlock" that happens at probe() time. We should probably have this code utilize the unlock() routines in the future, to avoid duplication, but unfortunately, flash which need to be unlocked don't all have a proper ->flash_unlock() callback. Signed-off-by:
-
Boris BREZILLON authored
nand_bch_init() requires several arguments which could directly be deduced from the mtd device. Get rid of those useless parameters. nand_bch_init() is also requiring the caller to provide a proper eccbytes value, while this value could be deduced from the ecc.size and ecc.strength value. Fallback to eccbytes calculation when it is set to 0. Signed-off-by:
-
Boris BREZILLON authored
If the MTD device does not have OOB, the mtd->oobsize and mtd->oobavail fields are set to zero, and we are testing those values in the following test. Remove the useless if (!mtd->ecclayout) test. Signed-off-by:
-
Boris BREZILLON authored
Currently, all MTD drivers/sublayers exposing an OOB area are doing the same kind of test to extract the available OOB size based on the mtd_info and mtd_oob_ops structures. Move this common logic into an inline function and make use of it. Signed-off-by:
Priit Laes <plaes@plaes.org> Signed-off-by:
-
Boris BREZILLON authored
ecclayout->oobavail is just redundant with the mtd->oobavail field. Moreover, it prevents static const definition of ecc layouts since the NAND framework is calculating this value based on the ecclayout->oobfree field. Signed-off-by:
-
- 07 Mar, 2016 9 commits
-
-
Brian Norris authored
In commit b70af9be ("mtd: nand: increase ready wait timeout and report timeouts"), we increased the likelihood of scheduling during nand_wait(). This makes us more likely to hit the time_before(...) condition, since a lot of time may pass before we get scheduled again. Now, the loop was already buggy, since we don't check if the NAND is ready after exiting the loop; we simply print out a timeout warning. Fix this by doing a final status check before printing a timeout message. This isn't actually a critical bug, since the only effect is a false warning print. But too many prints never hurt anyone, did they? :) Side note: perhaps I'm not smart enough, but I'm not sure what the best policy is for this kind of loop; do we busy loop (i.e., no cond_resched()) to keep the lowest I/O latency (it's not great if the resched is delaying Richard's system ~400ms)? Or do we allow rescheduling, to play nice with the rest of the system (since some operations can take quite a while)? Reported-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
Harvey Hunt <harvey.hunt@imgtec.com>
-
Brian Norris authored
Fixes this warning: >> drivers/mtd/bcm63xxpart.c:175:4: note: in expansion of macro 'pr_err' pr_err("invalid rootfs address: %*ph\n", ^ >> include/linux/kern_levels.h:4:18: warning: field width specifier '*' expects argument of type 'int', but argument 2 has type 'long unsigned int' [-Wformat=] Reported-by:kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
Alexander Stein authored
ubifs uses the write buffer size in recovery algorithm. When inspecting an unclean ubifs recovery fails with writebuf size 64 in mtdram while recovery on actual mtd device with writebuf size of 1024 succeeds. So add a parameter for setting this property. Signed-off-by:
Alexander Stein <alexander.stein@systec-electronic.com> Reviewed-by:
-
Brian Norris authored
With this removal, we don't need to 'get' the second DMA resource either, as it's also unused. Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Yao Yuan authored
Add optional properties for QSPI: big-endian if the register is big endian on this platform. Signed-off-by:
Yuan Yao <yao.yuan@nxp.com> Acked-by:
Han xu <han.xu@nxp.com> Signed-off-by:
-
Yao Yuan authored
new compatible string: "fsl,ls2080a-qspi". Signed-off-by:
-
Yao Yuan authored
LS1043a and LS2080A in the Layerscape family also support Freescale Quad SPI, make Quad SPI selectable for these hardwares. Signed-off-by:
-
Yao Yuan authored
LS1021a also support Freescale Quad SPI controller. Add fsl-quadspi support for ls1021a chip and make SPI_FSL_QUADSPI selectable for LS1021A SOC hardwares. Signed-off-by:
Han xu <han.xu@freescale.com> Acked-by:
-
Yao Yuan authored
Add R/W functions for big- or little-endian registers: The qSPI controller's endian is independent of the CPU core's endian. So far, the qSPI have two versions for big-endian and little-endian. Signed-off-by:
-
- 05 Mar, 2016 3 commits
-
-
Ezequiel García authored
Micron n25q128axx support subsector (4K) erase so let's update the flags. Tested on n25q128a13. Signed-off-by:
-
Robert Jarzmik authored
When the driver is initialized in a pure device-tree platform, the driver's probe fails allocating the dma channel : [ 525.624435] pxa3xx-nand 43100000.nand: no resource defined for data DMA [ 525.632088] pxa3xx-nand 43100000.nand: alloc nand resource failed The reason is that the DMA IO resource is not acquired through platform resources but by OF bindings. Fix this by ensuring that DMA IO resources are only queried in the non device-tree case. Fixes: 8f5ba31a ("mtd: nand: pxa3xx-nand: switch to dmaengine") Signed-off-by:
-
Boris BREZILLON authored
mtd->priv is no longer pointing to the struct nand_chip it is attached to. Replace those accesses by mtd_to_nand() calls. Signed-off-by:
-
- 29 Feb, 2016 2 commits
-
-
David Woodhouse authored
We need to finish doing the CRC checks before we can allow writes to happen, and we currently process the inodes in order. This means a call to jffs2_get_ino_cache() for each possible inode# up to c->highest_ino. There may be a lot of lookups which fail, if the inode# space is used sparsely. And the inode# space is *often* used sparsely, if a file system contains a lot of stuff that was put there in the original image, followed by lots of creation and deletion of new files. Instead of processing them numerically with a lookup each time, just walk the hash buckets instead. [fix locking typo reported by Dan Carpenter] Signed-off-by:David Woodhouse <David.Woodhouse@intel.com>
-
Florian Fainelli authored
The BRCMNAND controller revision 7.1 is almost 100% compatible with the previous v6.0 register offset layout, except for the Correctable Error Reporting Threshold registers. Fix this by adding another table with the correct offsets for CORR_THRESHOLD and CORR_THRESHOLD_EXT. Fixes: 27c5b17c ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
- 24 Feb, 2016 1 commit
-
-
Aaro Koskinen authored
Commit 5942ddbc ("mtd: introduce mtd_block_markbad interface") incorrectly changed onenand_block_markbad() to call mtd_block_markbad instead of onenand_chip's block_markbad function. As a result the function will now recurse and deadlock. Fix by reverting the change. Fixes: 5942ddbc ("mtd: introduce mtd_block_markbad interface") Signed-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by:
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
- 12 Feb, 2016 10 commits
-
-
Cyrille Pitchen authored
This patch remove the micron_quad_enable() function which force the Quad SPI mode. However, once this mode is enabled, the Micron memory expect ALL commands to use the SPI 4-4-4 protocol. Hence a failure does occur when calling spi_nor_wait_till_ready() right after the update of the Enhanced Volatile Configuration Register (EVCR) in the micron_quad_enable() as the SPI controller driver is not aware about the protocol change. Since there is almost no performance increase using Fast Read 4-4-4 commands instead of Fast Read 1-1-4 commands, we rather keep on using the Extended SPI mode than enabling the Quad SPI mode. Let's take the example of the pretty standard use of 8 dummy cycles during Fast Read operations on 64KB erase sectors: Fast Read 1-1-4 requires 8 cycles for the command, then 24 cycles for the 3byte address followed by 8 dummy clock cycles and finally 65536*2 cycles for the read data; so 131112 clock cycles. On the other hand the Fast Read 4-4-4 would require 2 cycles for the command, then 6 cycles for the 3byte address followed by 8 dummy clock cycles and finally 65536*2 cycles for the read data. So 131088 clock cycles. The theorical bandwidth increase is 0.0%. Now using Fast Read operations on 512byte pages: Fast Read 1-1-4 needs 8+24+8+(512*2) = 1064 clock cycles whereas Fast Read 4-4-4 would requires 2+6+8+(512*2) = 1040 clock cycles. Hence the theorical bandwidth increase is 2.3%. Consecutive reads for non sequential pages is not a relevant use case so The Quad SPI mode is not worth it. mtd_speedtest seems to confirm these figures. Signed-off-by:
Cyrille Pitchen <cyrille.pitchen@atmel.com> Fixes: 548cd3ab ("mtd: spi-nor: Add quad I/O support for Micron SPI NOR") Signed-off-by:
-
Sascha Hauer authored
The Spansion s25fl116k is a 16MBit NOR Flash supporting dual and quad read operations. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Thomas Petazzoni authored
This commit is needed to properly support the 8-bits ECC configuration with 4KB pages. When pages larger than 2 KB are used on platforms using the PXA3xx NAND controller, the reading/programming operations need to be split in chunks of 2 KBs or less because the controller FIFO is limited to about 2 KB (i.e a bit more than 2 KB to accommodate OOB data). Due to this requirement, the data layout on NAND is a bit strange, with ECC interleaved with data, at the end of each chunk. When a 4-bits ECC configuration is used with 4 KB pages, the physical data layout on the NAND looks like this: | 2048 data | 32 spare | 30 ECC | 2048 data | 32 spare | 30 ECC | So the data chunks have an equal size, 2080 bytes for each chunk, which the driver supports properly. When a 8-bits ECC configuration is used with 4KB pages, the physical data layout on the NAND looks like this: | 1024 data | 30 ECC | 1024 data | 30 ECC | 1024 data | 30 ECC | 1024 data | 30 ECC | 64 spare | 30 ECC | So, the spare area is stored in its own chunk, which has a different size than the other chunks. Since OOB is not used by UBIFS, the initial implementation of the driver has chosen to not support reading this additional "spare" chunk of data. Unfortunately, Marvell has chosen to store the BBT signature in the OOB area. Therefore, if the driver doesn't read this spare area, Linux has no way of finding the BBT. It thinks there is no BBT, and rewrites one, which U-Boot does not recognize, causing compatibility problems between the bootloader and the kernel in terms of NAND usage. To fix this, this commit implements the support for reading a partial last chunk. This support is currently only useful for the case of 8 bits ECC with 4 KB pages, but it will be useful in the future to enable other configurations such as 12 bits and 16 bits ECC with 4 KB pages, or 8 bits ECC with 8 KB pages, etc. All those configurations have a "last" chunk that doesn't have the same size as the other chunks. In order to implement reading of the last chunk, this commit: - Adds a number of new fields to the pxa3xx_nand_info to describe how many full chunks and how many chunks we have, the size of full chunks and partial chunks, both in terms of data area and spare area. - Fills in the step_chunk_size and step_spare_size variables to describe how much data and spare should be read/written for the current read/program step. - Reworks the state machine to accommodate doing the additional read or program step when a last partial chunk is used. This commit has been tested on a Marvell Armada 398 DB board, with a 4KB page NAND, tested in both 4 bits ECC and 8 bits ECC configurations. Robert Jarzmik has tested on some PXA platforms. Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by:
-
Linus Walleij authored
As of commit 876fe76d "mtd: maps: physmap: Add reference counter to set_vpp()" the comment in the header file is incorrect and misleading. Fix it up. Cc: Russell King <linux@arm.linux.org.uk> Cc: Paul Parsons <lost.distance@yahoo.com> Fixes: 876fe76d ("mtd: maps: physmap: Add reference counter to set_vpp()") Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Simon Arlott authored
Move the NOR flash layout to a separate function to allow the NAND flash layout to be supported. Signed-off-by:
Simon Arlott <simon@fire.lp0.eu> Signed-off-by:
-
Simon Arlott authored
Strings read from flash could be missing null termination characters, or not contain valid integers. Null terminate the strings and check for errors when converting them to integers. Also validate that the addresses are at least BCM963XX_EXTENDED_SIZE because this will be subtracted from them. Signed-off-by:
-
Simon Arlott authored
Extract image tag reading and CRC check to a separate function. Signed-off-by:
-
Simon Arlott authored
Read nvram directly from flash instead of using the in-memory copy that mach-bcm63xx has, to remove the dependency on mach-bcm63xx and allow the parser to work on bmips too. Rename remaining BCM63XX defines to BCM963XX as these are properties of the flash layout on the board. BCM963XX_DEFAULT_PSI_SIZE changes from SZ_64K to 64 because it will be multiplied by SZ_1K later on. Signed-off-by:
-
Romain Izard authored
As the SAMA5D2 controller supports the 32-bit ECC strength, accept it as a valid setting when required by the device tree or the NAND parameter page. Then configure the controller to use this new setting. For the binding: Acked-by:
Romain Izard <romain.izard.pro@gmail.com> Tested-by:
Wenyou Yang <wenyou.yang@atmel.com> Reviewed-by:
-
Romain Izard authored
Starting with the SAMA5D2, there is a new revision of the Atmel PMECC controller that can correct 32 bits in each sector. This controller is not 100% compatible with the previous revision that corrected a maximum of 24 bits by sector, as some register addresses overlap. Using information from the device tree, we can configure the driver to work with both versions. For the binding: Acked-by:
-
