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>
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>
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>
Flash lock/unlock is a flash-specific operations. Factor out a callback
for it to more readily support other vendors.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by: VIET NGA DAO <vndao@altera.com>
This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes.
For Micron SPI NOR flash, enabling or disabling quad I/O protocol can be
done By two methods, which are to use EVCR (Enhanced Volatile
Configuration Register) and the ENTER QUAD I/O MODE command. There is no
difference between these two methods. Unfortunately, for some Micron SPI
NOR flashes, there no ENTER Quad I/O command (35h), such as n25q064. But
for all current Micron SPI NOR, if it support quad I/O mode, using EVCR
definitely be supported. It is a recommended method to enable Quad I/O
mode by EVCR, Quad I/O protocol bit 7. When EVCR bit 7 is reset to 0,
the SPI NOR flash will operate in quad I/O mode.
This patch has been tested on N25Q512A and MT25TL256BAA1ESF. Micron SPI
NOR of spi_nor_ids[] table all support this method.
Signed-off-by: Bean Huo <beanhuo@micron.com>
Acked-by: Marek Vasut <marex@denx.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
This will allow spi-nor users to plainly use JEDEC to detect flash chip.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
write_enable() was being duplicated to both m25p80.c and fsl-quadspi.c.
But this should be handled within the spi-nor abstraction layer.
At the same time, let's add write_disable() after erasing, so we don't
leave the flash in a write-enabled state afterward.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Huang Shijie <shijie.huang@intel.com>
We need to store the six bytes ID for s25fl128s, since it shares the same
five bytes with s25fl129p1.
This patch adds a macro INFO6 which is used for the six bytes ID flash, and adds
a new item for the s25fl128s.
Signed-off-by: Huang Shijie <shijie.huang@intel.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
The "id" array contains all the information about the JEDEC and the
manufacturer ID info. This patch removes the jedec_id/ext_id from
flash_info.
Signed-off-by: Huang Shijie <shijie.huang@intel.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
This patch adds the id/id_len fields for flash_info{}, and rewrite the
INFO to fill them. And at last, we read out 6 bytes in the spi_nor_read_id(),
and we use these new fields to parse out the correct flash_info.
Signed-off-by: Huang Shijie <shijie.huang@intel.com>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
There are a few small issues with the timeout loop in
spi_nor_wait_till_ready():
* The first operation should not be a reschedule; we should check the
status register at least once to see if we're complete!
* We should check the status register one last time after declaring the
deadline has passed, to prevent a premature timeout error (this is
theoretically possible if we sleep for a long time after the previous
status register check).
* Add an error message, so it's obvious if we ever hit a timeout.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Huang Shijie <shijie.huang@intel.com>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Add sst25wf080 to the spi-nor device id table.
Signed-off-by: Harini Katakam <harinik@xilinx.com>
Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Marek Vasut <marex@denx.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested with this particular FRAM chip
Signed-off-by: Rostislav Lisovy <lisovy@merica.cz>
Acked-by: Marek Vasut <marex@denx.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Because n25q032 is the Micron SPI chip, move it to Micron
devices list group. In order that know which Micron SPI
chips have been support at a glance.
Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Huang Shijie <shijie8@gmail.com>
Acked-by: Marek Vasut <marex@denx.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
We don't need to expose a 'wait-till-ready' interface to drivers. Status
register polling should be handled by the core spi-nor.c library, and as
of now, I see no need to provide a special driver-specific hook for it.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
We shouldn't have *every* function checking if a previous write is
complete; this should be done synchronously after each write/erase.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
The error label was unused here. It looks like we're missing at least
one case that should be doing 'goto write_err'.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Huang Shijie <shijie8@gmail.com>
These functions were near-carbon-copies due to a small per-flash quirk.
Let's add a new spi_nor::flags bitfield to support these types of
quirks.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Cc: Graham Moore <grmoore@altera.com>
Cc: Huang Shijie <shijie8@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
For the DDR Quad read, the dummy cycles maybe 3 or 6 which is less then 8.
The dummy cycles is actually 8 for SPI fast/dual/quad read.
This patch makes preparations for the DDR quad read, it fixes the wrong dummy
value for both the spi-nor.c and m25p80.c.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Acked-by: Marek Vasut <marex@denx.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
There is currently no useful way to override the default
implementation of this operation. The returned struct spi_device_id
must have a pointer to struct flash_info in its private data, but this
structure is defined inside spi-nor.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
m25p80's device ID table is now spi_nor_ids, defined in spi-nor. The
MODULE_DEVICE_TABLE() macro doesn't work with extern definitions, but
its use was also removed at the same time. Now if m25p80 is built as
a module it doesn't get the necessary aliases to be loaded
automatically.
A clean solution to this will involve defining the list of device
IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
API, but this is quite a large change.
As a quick fix suitable for stable, copy the device IDs back into
m25p80.
Fixes: 03e296f613 ("mtd: m25p80: use the SPI nor framework")
Cc: <stable@vger.kernel.org> # 3.16.x: 32f1b7c835: mtd: move support for struct flash_platform_data into m25p80
Cc: <stable@vger.kernel.org> # 3.16.x: 90e55b3812: mtd: m25p80: get rid of spi_get_device_id
Cc: <stable@vger.kernel.org> # 3.16.x: 70f3ce0510: mtd: spi-nor: make spi_nor_scan() take a chip type name, not spi_device_id
Cc: <stable@vger.kernel.org> # 3.16.x
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Drivers currently call spi_nor_match_id() and then spi_nor_scan().
This adds a dependency on struct spi_device_id which we want to
avoid. Make spi_nor_scan() do it for them.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
This "type" seems to be an extra hint for m25p80 about the flash. Some
archs register flash_platform_data with "name" set to "m25p80" and then
with a real flash name set in "type". It seems to be a trick specific
to the m25p80 so let's move it out of spi-nor.
Btw switch to the spi_nor_match_id instead of iterating spi_nor_ids.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Current situation with 4K sectors is quite messy. First of all, some
MTD "users" don't work with such small size. An example may be UBIFS
which requires 15 KiB erase blocks as a minimum. In theory spi-nor
should provide multiple erase regions and MTD "users" should use the
one they need. Unforunately that is not implemented.
In the result our flashes database in spi-nor is hackish. For some
flashes we pretend they don't support 4K sectors just because some
distribution uses UBIFS on it. This ofc leads to conflicts, like
Samsung using w25q128 with 4K sectors vs. OpenWrt requiring it to
pretend it's 64 KiB blocks only.
My idea (plan?) for fixing this situation:
1) Use real hw info (this requires a way for disabling 4K for now)
2) Provide detailed info about erase regions
3) Make UBIFS work with devices that support 4K sectors
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
It's a one-liner doing no magic and its name may be confusing because
it does not have to use JEDEC (e.g. when using alternative read_id).
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Acked-by: Huang Shijie <shijie8@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
This commit adds the support in the spi-nor driver of the Micron
M25PX80 flash, a 8 Mbit SPI flash from Micron.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Some new Micron flash chips require reading the flag status register to
determine when operations have completed.
Furthermore, chips with multi-die stacks of the 65nm 256Mb QSPI also
require reading the status register before reading the flag status
register.
This patch adds support for the flag status register in the n25q512ax3
and n25q00 Micron QSPI flash chips.
Signed-off-by: Graham Moore <grmoore@altera.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Spansion s25sl032p supports Dual and Quad SPI transfers, hence set the
SPI_NOR_DUAL_READ and SPI_NOR_QUAD_READ flags.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
serial_flash_cmds.h defines our opcodes a little differently. Let's
borrow its naming, since it's borrowed from the SFDP standard, and it's
more extensible.
This prepares us for merging serial_flash_cmds.h and spi-nor.h opcode
listing.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Huang Shijie <b32955@freescale.com>
Qualify these with a better namespace, and prepare them for use in more
drivers.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Huang Shijie <b32955@freescale.com>
Add the copyright information for spi-nor.c and spi-nor.h.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Add the spi_nor_match_id() to find the proper spi_device_id with the
NOR flash's name in the spi_nor_ids table.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Acked-by: Marek Vasut <marex@denx.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
This patch cloned most of the m25p80.c. In theory, it adds a new spi-nor layer.
Before this patch, the layer is like:
MTD
------------------------
m25p80
------------------------
spi bus driver
------------------------
SPI NOR chip
After this patch, the layer is like:
MTD
------------------------
spi-nor
------------------------
m25p80
------------------------
spi bus driver
------------------------
SPI NOR chip
With the spi-nor controller driver(Freescale Quadspi), it looks like:
MTD
------------------------
spi-nor
------------------------
fsl-quadspi
------------------------
SPI NOR chip
New APIs:
spi_nor_scan: used to scan a spi-nor flash.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Acked-by: Marek Vasut <marex@denx.de>
[Brian: rebased to include additional m25p_ids[] entry]
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
