Add Micron (n25q00a) 1Gbit NOR Flash in the list of supported
devices.
This part is different from n25q00 in Memory Type.
Memory Type for n25q00 - BAh
Memory Type for n25q00a - BBh
Signed-off-by: P L Sai Krishna <lakshmis@xilinx.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
In stm_unlock(), the test to determine whether we've fully unlocked the
flash checks for the lock length to be equal to the flash size. That is
a typo/think-o -- the condition actually means the flash is completely
*locked.* We should be using the inverse condition -- that the lock
length is 0 (i.e., no protection).
The result of this bug is that we never actually turn off the Status
Register Write Disable bit, even if the flash is completely unlocked.
Now we can.
Fixes: 47b8edbf0d ("mtd: spi-nor: disallow further writes to SR if WP# is low")
Reported-by: Giorgio <giorgio.nicole@arcor.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
mtdblock and ubi do not handle the situation when read returns less data
than requested. Loop in spi-nor until buffer is filled or an error is
returned.
Signed-off-by: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Michal Suchanek <hramrach@gmail.com>
Tested-by: Michal Suchanek <hramrach@gmail.com>
The spi-nor write loop assumes that what is passed to the hardware
driver write() is what gets written.
When write() writes less than page size at once data is dropped on the
floor. Check the amount of data writen and exit if it does not match
requested amount.
Signed-off-by: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Michal Suchanek <hramrach@gmail.com>
Tested-by: Michal Suchanek <hramrach@gmail.com>
Do not pass retlen to hardware driver read/write functions. Update it in
spi-nor generic driver instead.
Signed-off-by: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Michal Suchanek <hramrach@gmail.com>
Tested-by: Michal Suchanek <hramrach@gmail.com>
SPI NOR hardware drivers now return useful value from their write
functions so check them.
Signed-off-by: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Michal Suchanek <hramrach@gmail.com>
Tested-by: Michal Suchanek <hramrach@gmail.com>
Add checking of SPI transfer errors and return them from read/write
functions. Also return the amount of data transferred.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Add checking of SPI transfer errors and return them from read/write
functions. Also return the amount of data transferred.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Return amount of data read/written or error as read(2)/write(2) does.
Signed-off-by: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Change the return value of spi-nor device read and write methods to
allow returning amount of data transferred and errors as
read(2)/write(2) does.
Also, start handling positive returns in spi_nor_read(), since we want
to convert drivers to start returning the read-length both via *retlen
and the return code. (We don't need to do the same transition process
for spi_nor_write(), since ->write() didn't used to have a return code
at all.)
Signed-off-by: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Michal Suchanek <hramrach@gmail.com>
Tested-by: Michal Suchanek <hramrach@gmail.com>
Also note the GigaDevice JEDEC ID.
No write-protect support yet, since this flash uses a different status
register layout.
Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Marek Vasut <marex@denx.de>
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: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
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 <computersforpeace@gmail.com>
Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
We can't determine this purely by manufacturer type (see commit
67b9bcd369 ("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 <computersforpeace@gmail.com>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
It's a little easier to read and make sure there are no collisions
(IMO).
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
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 <computersforpeace@gmail.com>
Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
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 <computersforpeace@gmail.com>
Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
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 <computersforpeace@gmail.com>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Fixup a piece leftover by commit 32321e950d ("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: Brian Norris <computersforpeace@gmail.com>
Cc: Stas Sergeev <stsp@users.sourceforge.net>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
LS1043a and LS2080A in the Layerscape family also support Freescale Quad
SPI, make Quad SPI selectable for these hardwares.
Signed-off-by: Yuan Yao <yao.yuan@nxp.com>
Acked-by: Han xu <han.xu@nxp.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
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: Yuan Yao <yao.yuan@nxp.com>
Acked-by: Han xu <han.xu@freescale.com>
Acked-by: Han xu <han.xu@nxp.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
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: Yuan Yao <yao.yuan@nxp.com>
Acked-by: Han xu <han.xu@freescale.com>
Acked-by: Han xu <han.xu@nxp.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Micron n25q128axx support subsector (4K) erase so let's update the flags.
Tested on n25q128a13.
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
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: 548cd3ab54 ("mtd: spi-nor: Add quad I/O support for Micron SPI NOR")
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
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: Brian Norris <computersforpeace@gmail.com>
Not every arch has io memory.
So, unbreak the build by fixing the dependencies.
Signed-off-by: Richard Weinberger <richard@nod.at>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
WARNING: drivers/mtd/spi-nor/mtk-quadspi.o(.text+0x77e): Section mismatch in reference from the function mtk_nor_drv_probe() to the function .init.text:mtk_nor_init()
The function mtk_nor_drv_probe() references
the function __init mtk_nor_init().
This is often because mtk_nor_drv_probe lacks a __init
annotation or the annotation of mtk_nor_init is wrong.
Drop the bogus __init from mtk_nor_init() to kill this warning.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
On Micron and Numonyx devices, the status register write command
(WRSR), raises a work-in-progress bit (WIP) on the status register.
The datasheets for these devices specify that while the status
register write is in progress, the status register WIP bit can still
be read to check the end of the operation.
This commit adds a wait_till_ready call on lock/unlock operations,
which is required for Micron and Numonyx but should be harmless for
others. This is needed to prevent applications from issuing erase or
program operations before the unlock operation is completed.
Reported-by: Stas Sergeev <stsp@list.ru>
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
stm_is_locked_sr() takes the status register (SR) value as the last
parameter, not the second.
Reported-by: Bayi Cheng <bayi.cheng@mediatek.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Bayi Cheng <bayi.cheng@mediatek.com>
Spansion and Winbond have occasionally used the same manufacturer ID,
and they don't support the same features. Particularly, writing SR=0
seems to break read access for Spansion's s25fl064k. Unfortunately, we
don't currently have a way to differentiate these Spansion and Winbond
parts, so rather than regressing support for these Spansion flash, let's
drop the new Winbond lock/unlock support for now. We can try to address
Winbond support during the next release cycle.
Original discussion:
http://patchwork.ozlabs.org/patch/549173/http://patchwork.ozlabs.org/patch/553683/
Fixes: 357ca38d47 ("mtd: spi-nor: support lock/unlock/is_locked for Winbond")
Fixes: c6fc2171b2 ("mtd: spi-nor: disable protection for Winbond flash at startup")
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reported-by: Felix Fietkau <nbd@openwrt.org>
Cc: Felix Fietkau <nbd@openwrt.org>
Move write data register before excute command to avoid
missing first byte write to nor flash
Signed-off-by: Bayi Cheng <bayi.cheng@mediatek.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
We should better check the return value from read_sr() and
propagate it in the case of error.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
The documenting comment of mtd_erase in mtdcore.c states:
Device drivers are supposed to call instr->callback() whenever
the operation completes, even if it completes with a failure.
Currently the callback isn't called in case of failure. Fix this.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
As of commit 807f16d4db ("mtd: core: set some defaults when
dev.parent is set"), the MTD core will set this for us.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Bayi Cheng <bayi.cheng@mediatek.com>
according datasheet both chips can erase 4kByte sectors individually
Signed-off-by: Andreas Fenkart <andreas.fenkart@dev.digitalstrom.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Some spi-nor drivers perform sector erase by duplicating their
write_reg() command. Let's not require that the driver fill this out,
and provide a default instead.
Tested on m25p80.c and Medatek's MT8173 SPI NOR flash driver.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
It is theoretically possible to probe this driver without a matching
device tree, so let's guard against this.
Also, use the of_device_get_match_data() helper to make this a bit
simpler.
Coverity complained about this one.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Han xu <han.xu@freescale.com>
We can just alias to the MTD of_node.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Now that the SPI-NOR/MTD framework pass the 'flash_node' through to the
partition parsing code, we don't have to do it ourselves.
Also convert to mtd_device_register(), since we don't need the 2nd and
3rd parameters anymore.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Used semantic patch with 'make coccicheck MODE=patch COCCI=script.cocci':
---8<----
virtual patch
@@
struct spi_nor b;
struct spi_nor *c;
expression d;
@@
(
-(b).flash_node = (d)
+spi_nor_set_flash_node(&b, d)
|
-(c)->flash_node = (d)
+spi_nor_set_flash_node(c, d)
)
---8<----
And a manual conversion for the one use of spi_nor_get_flash_node().
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
We should pass along our flash DT node to the MTD layer, so it can set
up ofpart for us.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Change the READ/WRITE to FSL_READ/FSL_WRITE to resolve any possible
namespace collisions with READ/WRITE macros (e.g., from <linux/fs.h>).
Problems have been seen, for example, on mips:
>> drivers/mtd/spi-nor/fsl-quadspi.c:186:5: error: 'LUT_0' undeclared (first use in this function)
((LUT_##ins) << INSTR0_SHIFT))
^
>> drivers/mtd/spi-nor/fsl-quadspi.c:188:30: note: in expansion of macro 'LUT0'
On SPARC:
drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_init_lut':
drivers/mtd/spi-nor/fsl-quadspi.c:369:1: error: 'LUT_0' undeclared (first use in this function)
drivers/mtd/spi-nor/fsl-quadspi.c:418:1: error: pasting "LUT_" and "(" does not give a valid preprocessing token
drivers/mtd/spi-nor/fsl-quadspi.c:418:2: error: implicit declaration of function 'LUT_'
And surely on others.
Fixes: d26a22d067 ("mtd: fsl-quadspi: allow building for other ARCHes with COMPILE_TEST")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Han Xu <b45815@freescale.com>
[Brian: rewrote commit description]
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Building for x86 results in the following build errors:
drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_init_lut':
>> drivers/mtd/spi-nor/fsl-quadspi.c:355:21: error: 'SZ_16M' undeclared (first use in this function)
if (q->nor_size <= SZ_16M) {
^
drivers/mtd/spi-nor/fsl-quadspi.c:355:21: note: each undeclared identifier is reported only once for each function it appears in
drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_read':
>> drivers/mtd/spi-nor/fsl-quadspi.c:208:27: error: 'SZ_4M' undeclared (first use in this function)
#define QUADSPI_MIN_IOMAP SZ_4M
^
>> drivers/mtd/spi-nor/fsl-quadspi.c:845:25: note: in expansion of macro 'QUADSPI_MIN_IOMAP'
q->memmap_len = len > QUADSPI_MIN_IOMAP ? len : QUADSPI_MIN_IOMAP;
Explicitly include <linux/sizes.h> to fix the problem.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
This driver doesn't actually need ARCH_MXC to compile. Relax the
constraints.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Han xu <han.xu@freescale.com>
Seen when compile-testing on non-32-bit arch:
CC drivers/mtd/spi-nor/fsl-quadspi.o
drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_read':
drivers/mtd/spi-nor/fsl-quadspi.c:873:2: warning: format '%d' expects argument of type 'int', but argument 6 has type 'size_t' [-Wformat=]
dev_dbg(q->dev, "cmd [%x],read from 0x%p, len:%d\n",
^
Also drop the '0x' prefixing to the '%p' formatter, since %p already
knows how to format pointers appropriately.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Han xu <han.xu@freescale.com>
Many other flash share the same features as ST Micro. I've tested some
Winbond flash, so add them.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
This enables ioctl(MEMISLOCKED). Status can now be reported in the
mtdinfo or flash_lock utilities found in mtd-utils.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
This code was a bit sloppy, would produce a lot of copy-and-paste, and
did not always provide a sensible interface:
* It didn't validate the length for LOCK and the offset for UNLOCK, so
we were essentially discarding half of the user-supplied data and
assuming what they wanted to lock/unlock
* It didn't do very good error checking
* It didn't make use of the fact that this operation works on
power-of-two dimensions
So, rewrite this to do proper bit arithmetic rather than a bunch of
hard-coded condition tables. Now we have:
* More comments on how this was derived
* Notes on what is (and isn't) supported
* A more exendible function, so we could add support for other
protection ranges
* More accurate locking - e.g., suppose the top quadrant is locked (75%
to 100%); then in the following cases, case (a) will succeed but (b)
will not (return -EINVAL):
(a) user requests lock 3rd quadrant (50% to 75%)
(b) user requests lock 3rd quadrant, minus a few blocks (e.g., 50%
to 73%)
Case (b) *should* fail, since we'd have to lock blocks that weren't
requested. But the old implementation didn't know the difference and
would lock the entire second half (50% to 100%)
This refactoring work will also help enable the addition of
mtd_is_locked() support and potentially the support of bottom boot
protection (TB=1).
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
The N25Q032A is identical to the N25Q032 except it has a different
supply voltage range. Therefore, it has a new JEDEC ID.
Signed-off-by: Aurelien Chanot <chanot.a@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
This patch fixes timeout issues seen on large NOR flash (e.g., 16MB
w25q128fw) when using ioctl(MEMERASE) with offset=0 and length=16M. The
input parameters matter because spi_nor_erase() uses a different code
path for full-chip erase, where we use the SPINOR_OP_CHIP_ERASE (0xc7)
opcode.
Fix: use a different timeout for full-chip erase than for other
commands.
While most operations can be expected to perform relatively similarly
across a variety of NOR flash types and sizes (and therefore might as
well use a similar timeout to keep things simple), full-chip erase is
unique, because the time it typically takes to complete:
(1) is much larger than most operations and
(2) scales with the size of the flash.
Let's base our timeout on the original comments stuck here -- that a 2MB
flash requires max 40s to erase.
Small survey of a few flash datasheets I have lying around:
Chip Size (MB) Max chip erase (seconds)
---- -------- ------------------------
w25q32fw 4 50
w25q64cv 8 30
w25q64fw 8 100
w25q128fw 16 200
s25fl128s 16 ~256
s25fl256s 32 ~512
From this data, it seems plenty sufficient to say we need to wait for
40 seconds for each 2MB of flash.
After this change, it might make some sense to decrease the timeout for
everything else, as even the most extreme operations (single block
erase?) shouldn't take more than a handful of seconds. But for safety,
let's leave it as-is. It's only an error case, after all, so we don't
exactly need to optimize it.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
It is a 512KiB flash with 4 KiB erase sectors.
Signed-off-by: Yuan Yao <yao.yuan@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
s25fl016k can be found on Embedded Artists' LPC4357 Developer's Kit
where is used in quad mode by the LPC4357 SPIFI controller.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
The 'write_enable' argument is unused and unneeded, so remove it from
the API.
Signed-off-by: Jagan Teki <jteki@openedev.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Han Xu <han.xu@freescale.com>
[Brian: fixed for nxp-spifi.c]
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Use existing write_sr() call instead of decoding and
calling nor->write_reg separately.
Signed-off-by: Jagan Teki <jteki@openedev.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
The problem this patch is trying to address is such, that SPI NOR flash
devices attached to a dedicated SPI NOR controller cannot read their
properties from the associated struct device_node.
A couple of facts first:
1) Each SPI NOR flash has a struct spi_nor associated with it.
2) Each SPI NOR flash has certain device properties associated
with it, for example the OF property 'm25p,fast-read' is a
good pick. These properties are used by the SPI NOR core to
select which opcodes are sent to such SPI NOR flash. These
properties are coming from spi_nor .dev->of_node .
The problem is, that for SPI NOR controllers, the struct spi_nor .dev
element points to the struct device of the SPI NOR controller, not the
SPI NOR flash. Therefore, the associated dev->of_node also is the
one of the controller and therefore the SPI NOR core code is trying to
parse the SPI NOR controller's properties, not the properties of the
SPI NOR flash.
Note: The m25p80 driver is not affected, because the controller and
the flash are the same device, so the associated device_node
of the controller and the flash are the same.
This patch adjusts the SPI NOR core such that the device_node is not
picked from spi_nor .dev directly, but from a new separate spi_nor
.flash_node element. This let's the SPI NOR controller drivers set up
a different spi_nor .flash_node element for each SPI NOR flash.
This patch also fixes the controller drivers to be compatible with
this modification and correctly set the spi_nor .flash_node element.
This patch is inspired by 5844feeaa4
mtd: nand: add common DT init code
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
We don't really need the flash information from the device tree here.
Let's stick with autodetection here instead.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Han Xu <han.xu@freescale.com>
Tested-by: Han Xu <han.xu@freescale.com>
This reflects the proper layering, so let's do it.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by: Joachim Eastwood <manabian@gmail.com>
Layering suggests that the SPI NOR layer (not the hardware driver)
should be initializing the MTD layer.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by: Joachim Eastwood <manabian@gmail.com>
This chip can be found on Hitex LPC4350 Evaluation Board.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
According to the datasheet[1], both S25FL129P0 (256kB sectors) and
S25FL129P1 (64kB sectors) support dual read, quad read, dual i/o read
and quad i/o read.
I have verified dual read to be working for S25FL129P1 on a dual
capable spi controller. Quad as well as S25FL129P0 is untested, lacking
hardware to verify.
[1] http://www.spansion.com/Support/Datasheets/S25FL129P_00.pdf
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
It is a 256KiB flash with 4 KiB erase sectors
and 64KiB overlay blocks.
This is the one available on Hardkernel's Odroid U3 shield.
Signed-off-by: Alexis Ballier <aballier@gentoo.org>
[Brian: seems like this does NOT require the usual SST_WRITE hacks]
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Add Micron (n25q064a) 8MB flash to the list of supported chips.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>
[Brian: fixup context]
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Using struct spi_device_id for storing list of flash devices comes from
early SPI NOR framework days. Thanks to the commit 70f3ce0510 ("mtd:
spi-nor: make spi_nor_scan() take a chip type name, not spi_device_id")
we can stop using spi_device_id and just switch to our own struct.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
The current "We only connect the NOR to this controller now." text
is not very clear, so explain it better by saying that generic SPI
is not supported by SPI_FSL_QUADSPI and only SPI NOR is.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Add SPI-NOR driver for the SPI Flash Interface (SPIFI)
controller that is found on newer NXP MCU devices.
The controller supports serial SPI Flash devices with 1-, 2-
and 4-bit width in either SPI mode 0 or 3. The controller
can operate in either command or memory mode. In memory mode
the Flash is exposed as normal memory and can be directly
accessed by the CPU.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Erase function will use cmd 0x20 (SPINOR_OP_BE_4K) if kenrel enable option
CONFIG_MTD_SPI_NOR_USE_4K_SECTORS.
This command is not in fsl-quadspi driver LUT. So driver continue report
fsl-quadspi 21e0000.qspi: Unsupported cmd 0x20.
This patch fix this issue.
Signed-off-by: Frank Li <Frank.Li@freescale.com>
Acked-by: Han Xu <Han.xu@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
The uboot may run the QuadSpi controler with command:
#sf probe
So we should reset the module in the probe.
This patch also clear the pending interrupts which arised by the uboot
code.
Signed-off-by: Huang Shijie <shijie8@gmail.com>
Signed-off-by: Frank Li <Frank.Li@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
QSPI1 cannot wake up CCM from WAIT mode on SX ARD board, add pmqos to
let PM NOT enter WAIT mode when accessing QSPI1, refer to TKT245618.
Signed-off-by: Frank Li <Frank.Li@freescale.com>
Signed-off-by: Han Xu <Han.xu@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
We found there is a low probability(5%) QSPI access timeout issue,
usually it happened on kernel boot stage, the first time kernel tried to
access QSPI chip. The READ_ID command was sent but not executed,
consequently the probe function failed.
The root cause is that the divider is not glitchless in i.MX6SX chip.
If qspi clock enabled then change clock frequency by call clk_set_rate,
there will be glitch at low possiblity rate and pass to qspi controller.
The controler will be hang by this glitch.
Based on the new clock flag(CLK_SET_RATE_GATE) and new framework, we
need to change the approach of seting clock rate.
1. Disable clock.
2. call clk_set_rate.
3. Enable clock again.
Signed-off-by: Han Xu <han.xu@freescale.com>
Signed-off-by: Frank Li <Frank.Li@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Add i.mx6ul chip support
Signed-off-by: Frank Li <Frank.Li@freescale.com>
Acked-by: Han xu <han.xu@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Support i.mx7d.
quadspi in i.mx7d increase rxfifo.
require fill at least 16byte to trigger data transfer.
Signed-off-by: Frank Li <Frank.Li@freescale.com>
Signed-off-by: Han Xu <han.xu@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
add several quirk to distinguish different version of qspi module.
Signed-off-by: Han Xu <han.xu@freescale.com>
Signed-off-by: Frank Li <Frank.Li@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
QSPI may failed to map enough memory (256MB) for AHB read in
previous implementation, especially in 3G/1G memory layout kernel.
Dynamically map memory to avoid such issue.
This implementation generally map QUADSPI_MAX_IOMAP (default 4MB) memory
for AHB read, it should be enough for common scenarios, and the side
effect (0.6% performance drop) is minor.
Previous implementation
root@imx6qdlsolo:~# dd if=/dev/mtd0 of=/dev/null bs=1K count=32K
32768+0 records in
32768+0 records out
33554432 bytes (34 MB) copied, 2.16006 s, 15.5 MB/s
root@imx6qdlsolo:~# dd if=/dev/mtd0 of=/dev/null bs=32M count=1
1+0 records in
1+0 records out
33554432 bytes (34 MB) copied, 1.43149 s, 23.4 MB/s
After applied the patch
root@imx6qdlsolo:~# dd if=/dev/mtd0 of=/dev/null bs=1K count=32K
32768+0 records in
32768+0 records out
33554432 bytes (34 MB) copied, 2.1743 s, 15.4 MB/s
root@imx6qdlsolo:~# dd if=/dev/mtd0 of=/dev/null bs=32M count=1
1+0 records in
1+0 records out
33554432 bytes (34 MB) copied, 1.43158 s, 23.4 MB/s
Signed-off-by: Han Xu <han.xu@freescale.com>
Signed-off-by: Frank Li <Frank.Li@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
When we added the "jedec,spi-nor" compatible string for use in this
driver, we added it as a modalias option. The modalias can be derived in
different ways for platform devices vs. device tree (of_*) matching. But
for device tree matching (the primary target of this identifier string),
the modalias is determined from the first entry in the 'compatible'
property. IOW, the following properties would bind to this driver:
// Option (a), modalias = "spi-nor"
compatible = "jedec,spi-nor";
// Option (b), modalias = "spi-nor"
compatible = "idontknowwhatimdoing,spi-nor";
But the following would not:
// Option (c), modalias = "shinynewdevice"
compatible = "myvendor,shinynewdevice", "jedec,spi-nor";
So, we'd like to match (a) and (c) (even when we don't have an explicit
entry for "shinynewdevice"), and we'd rather not allow (b).
To do this, we
(1) always (for devices without specific platform data) pass the
modalias to the spi-nor library;
(2) rework the spi-nor library to not reject "bad" names, and
instead just fall back to autodetection; and
(3) add the .of_match_table to properly catch all "jedec,spi-nor".
This allows (a) and (c) without warnings, and rejects (b).
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
QUADSPI_MCR_CLR_TXF_MASK is the correct mask for clearing the TX FIFO.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Add supports for simultaneous access to multiple chips. Need to lock
the mutex before any quad spi operations and unlock the mutex after
operations complete.
Signed-off-by: Han Xu <b45815@freescale.com>
[Brian: reworked err path in fsl_qspi_prep()]
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Few recently added entries are missing SECT_4K flag despite of these
flashes supporting 4 KiB erase sectors and 0x20 erase command.
Also add a comment to help avoiding such mistakes in the future.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Cc: Knut Wohlrab <knut.wohlrab@de.bosch.com>
Cc: Huang Shijie <shijie.huang@intel.com>
Cc: Shengzhou Liu <shengzhou.liu@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
of_device_id is always used as const.
(See driver.of_match_table and open firmware functions)
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Add Macronix (mx25u6435f) 8MB flash to the list of supported chips.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Add Winbond (w25q64dw) 8MB flash to the list of supported chips.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Add support for EON en25s64 SPI flash.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
return type of wait_for_completion_timeout is unsigned long not int, this
patch uses the return value of wait_for_completion_timeout in the condition
directly rather than adding a additional appropriately typed variable.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Acked-by: Han Xu <han.xu@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
