- 24 5月, 2016 6 次提交
-
-
由 Heiko Schocher 提交于
Set free_count to zero before walking through ai->erase list in wl_init(). Found in U-Boot as U-Boot has no workqueue/threads, it immediately calls erase_worker(), which increase for each erased block free_count. Without this patch, free_count gets after this initialized to zero in wl_init(), so the free_count variable always has the maybe wrong value 0 in U-Boot. Signed-off-by: NHeiko Schocher <hs@denx.de> Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Dan Carpenter 提交于
My static checker complains that "val" is uninitialized when kstrtoint() fails. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Dan Carpenter 提交于
My static checker says that "err" can be uninitialized if "vol->reserved_pebs" is <= 0. I don't think that can happen but returning a literal is cleaner anyway. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 z00189512 提交于
Signed-off-by: Nz00189512 <abc.zhangliang@huawei.com> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Richard Weinberger 提交于
Drop this paranoia check from the old days. If our MTD driver or the flash is so bad that we even cannot trust it to write data we have bigger problems. If one really does not trust the flash and wants write-verify she can enable UBI io checks using debugfs. Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Ezequiel Garcia 提交于
On serious situations, UBI may detect serious device corruption, and switch to read-only mode to protect the data and allow debugging. This commit exposes this ro-mode on sysfs, so it can be obtained by userspace tools. Signed-off-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
- 05 4月, 2016 1 次提交
-
-
由 Kirill A. Shutemov 提交于
PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time ago with promise that one day it will be possible to implement page cache with bigger chunks than PAGE_SIZE. This promise never materialized. And unlikely will. We have many places where PAGE_CACHE_SIZE assumed to be equal to PAGE_SIZE. And it's constant source of confusion on whether PAGE_CACHE_* or PAGE_* constant should be used in a particular case, especially on the border between fs and mm. Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much breakage to be doable. Let's stop pretending that pages in page cache are special. They are not. The changes are pretty straight-forward: - <foo> << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>; - <foo> >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>; - PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN}; - page_cache_get() -> get_page(); - page_cache_release() -> put_page(); This patch contains automated changes generated with coccinelle using script below. For some reason, coccinelle doesn't patch header files. I've called spatch for them manually. The only adjustment after coccinelle is revert of changes to PAGE_CAHCE_ALIGN definition: we are going to drop it later. There are few places in the code where coccinelle didn't reach. I'll fix them manually in a separate patch. Comments and documentation also will be addressed with the separate patch. virtual patch @@ expression E; @@ - E << (PAGE_CACHE_SHIFT - PAGE_SHIFT) + E @@ expression E; @@ - E >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) + E @@ @@ - PAGE_CACHE_SHIFT + PAGE_SHIFT @@ @@ - PAGE_CACHE_SIZE + PAGE_SIZE @@ @@ - PAGE_CACHE_MASK + PAGE_MASK @@ expression E; @@ - PAGE_CACHE_ALIGN(E) + PAGE_ALIGN(E) @@ expression E; @@ - page_cache_get(E) + get_page(E) @@ expression E; @@ - page_cache_release(E) + put_page(E) Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by: NMichal Hocko <mhocko@suse.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 03 4月, 2016 1 次提交
-
-
由 Ezequiel García 提交于
Since commit 807f16d4 ("mtd: core: set some defaults when dev.parent is set"), it's now legal for drivers to call nand_scan and nand_scan_ident without setting mtd.owner. Drop the check and while at it remove the BUG() abuse. Fixes: 807f16d4 ("mtd: core: set some defaults when dev.parent is set") Signed-off-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar> Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com> [Brian: editorial note - while commit 807f16d4 wasn't explicitly broken, some follow-up commits in the v4.4 release broke a few drivers, since they would hit this BUG() if they used nand_scan() and were built as modules] Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
- 21 3月, 2016 1 次提交
-
-
由 Joe Perches 提交于
Using logging functions instead of macros can reduce overall object size. $ size drivers/mtd/ubi/built-in.o* text data bss dec hex filename 271620 163364 73696 508680 7c308 drivers/mtd/ubi/built-in.o.allyesconfig.new 287638 165380 73504 526522 808ba drivers/mtd/ubi/built-in.o.allyesconfig.old 87728 3780 504 92012 1676c drivers/mtd/ubi/built-in.o.defconfig.new 97084 3780 504 101368 18bf8 drivers/mtd/ubi/built-in.o.defconfig.old Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
- 12 3月, 2016 1 次提交
-
-
由 Brian Norris 提交于
The 'getchip' parameter is gone as of commit 9f3e0429 ("mtd: nand: don't select chip in nand_chip's block_bad op"), so kill the doc with it. Reported-by: Nkbuild test robot <fengguang.wu@intel.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com> Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
- 11 3月, 2016 2 次提交
-
-
由 Archit Taneja 提交于
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: NAndy Gross <agross@codeaurora.org> Signed-off-by: NStephen Boyd <sboyd@codeaurora.org> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Archit Taneja 提交于
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: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
- 08 3月, 2016 19 次提交
-
-
由 Brian Norris 提交于
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: NBrian Norris <computersforpeace@gmail.com> Reviewed-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar> Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
-
由 Brian Norris 提交于
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: NBrian Norris <computersforpeace@gmail.com> Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
-
由 Brian Norris 提交于
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: NBrian Norris <computersforpeace@gmail.com> Reviewed-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar> Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
-
由 Brian Norris 提交于
It's a little easier to read and make sure there are no collisions (IMO). Signed-off-by: NBrian Norris <computersforpeace@gmail.com> Reviewed-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar> Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
-
由 Brian Norris 提交于
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: NBrian Norris <computersforpeace@gmail.com> Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
-
由 Brian Norris 提交于
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: NBrian Norris <computersforpeace@gmail.com> Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
-
由 Brian Norris 提交于
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: NBrian Norris <computersforpeace@gmail.com> Reviewed-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar> Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
-
由 Brian Norris 提交于
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: NBrian Norris <computersforpeace@gmail.com> Cc: Stas Sergeev <stsp@users.sourceforge.net> Reviewed-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar> Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
-
由 Boris BREZILLON 提交于
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: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Boris BREZILLON 提交于
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: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Boris BREZILLON 提交于
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: NBoris Brezillon <boris.brezillon@free-electrons.com> Suggested-by: NPriit Laes <plaes@plaes.org> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Boris BREZILLON 提交于
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: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Brian Norris 提交于
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: NRichard Weinberger <richard@nod.at> Signed-off-by: NBrian Norris <computersforpeace@gmail.com> Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: NRichard Weinberger <richard@nod.at> Reviewed-by: NHarvey Hunt <harvey.hunt@imgtec.com>
-
由 Brian Norris 提交于
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: Nkbuild test robot <fengguang.wu@intel.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Alexander Stein 提交于
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: NAlexander Stein <alexander.stein@systec-electronic.com> Reviewed-by: NRichard Weinberger <richard@nod.at> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Brian Norris 提交于
With this removal, we don't need to 'get' the second DMA resource either, as it's also unused. Signed-off-by: NBrian Norris <computersforpeace@gmail.com> Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Yao Yuan 提交于
LS1043a and LS2080A in the Layerscape family also support Freescale Quad SPI, make Quad SPI selectable for these hardwares. Signed-off-by: NYuan Yao <yao.yuan@nxp.com> Acked-by: NHan xu <han.xu@nxp.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Yao Yuan 提交于
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: NYuan Yao <yao.yuan@nxp.com> Acked-by: NHan xu <han.xu@freescale.com> Acked-by: NHan xu <han.xu@nxp.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Yao Yuan 提交于
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: NYuan Yao <yao.yuan@nxp.com> Acked-by: NHan xu <han.xu@freescale.com> Acked-by: NHan xu <han.xu@nxp.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
- 06 3月, 2016 1 次提交
-
-
由 Richard Weinberger 提交于
ubi_start_leb_change() allocates too few bytes. ubi_more_leb_change_data() will write up to req->upd_bytes + ubi->min_io_size bytes. Cc: stable@vger.kernel.org Signed-off-by: NRichard Weinberger <richard@nod.at> Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
- 05 3月, 2016 4 次提交
-
-
由 Ezequiel García 提交于
Micron n25q128axx support subsector (4K) erase so let's update the flags. Tested on n25q128a13. Signed-off-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Robert Jarzmik 提交于
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: NRobert Jarzmik <robert.jarzmik@free.fr> Acked-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Jorge Ramirez-Ortiz 提交于
Offending Commit: 6e941192 "mtd: nand: return consistent error codes in ecc.correct() implementations" The new error code was not being handled properly in double bit error detection. Signed-off-by: NJorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Tested-by: NFranklin S Cooper Jr <fcooper@ti.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Boris BREZILLON 提交于
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: NBoris Brezillon <boris.brezillon@free-electrons.com> Fixes: 4be4e03e ("mtd: nand: sunxi: add randomizer support") Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
- 01 3月, 2016 1 次提交
-
-
由 Florian Fainelli 提交于
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: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
- 25 2月, 2016 1 次提交
-
-
由 Aaro Koskinen 提交于
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: NAaro Koskinen <aaro.koskinen@iki.fi> Acked-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
- 16 2月, 2016 1 次提交
-
-
由 Bjorn Helgaas 提交于
Most arches have an asm/gpio.h that merely includes linux/gpio.h. The others select ARCH_HAVE_CUSTOM_GPIO_H, and when that's selected, linux/gpio.h includes asm/gpio.h. Therefore, code should include linux/gpio.h instead of including asm/gpio.h directly. Remove includes of asm/gpio.h, adding an include of linux/gpio.h when necessary. This is a follow-on to 7563bbf8 ("gpiolib/arches: Centralise bolierplate asm/gpio.h"). Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NThomas Gleixner <tglx@linutronix.de> Acked-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 13 2月, 2016 1 次提交
-
-
由 Cyrille Pitchen 提交于
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: NCyrille Pitchen <cyrille.pitchen@atmel.com> Fixes: 548cd3ab ("mtd: spi-nor: Add quad I/O support for Micron SPI NOR") Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-