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.pdfSigned-off-by: NJonas Gorski <jogo@openwrt.org>
Reviewed-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBrian 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: NAlexis Ballier <aballier@gentoo.org>
[Brian: seems like this does NOT require the usual SST_WRITE hacks]
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Add Micron (n25q064a) 8MB flash to the list of supported chips.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NJagan Teki <jteki@openedev.com>
[Brian: fixup context]
Signed-off-by: NBrian 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 70f3ce05 ("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: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Spansion S25FL204K is a 4-Mbit 3.0V Serial Flash Memory
with Uniform 4 kB Sectors.
Signed-off-by: NAntony Pavlov <antonynpavlov@gmail.com>
Acked-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBrian 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: NBrian Norris <computersforpeace@gmail.com>

Micron n25q064 flash supports 4 KiB erase sectors.
Signed-off-by: NAlexey Firago <alexey_firago@mentor.com>
Signed-off-by: NBrian 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: NRafał 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: NBrian Norris <computersforpeace@gmail.com>

It's an 8 MiB flash with 4 KiB erase sectors.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Add Macronix (mx25u6435f) 8MB flash to the list of supported chips.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Add Winbond (w25q64dw) 8MB flash to the list of supported chips.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NLuka Perkov <luka@openwrt.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Add support for EON en25s64 SPI flash.
Signed-off-by: NShengzhou Liu <Shengzhou.Liu@freescale.com>
Signed-off-by: NBrian 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: NBrian Norris <computersforpeace@gmail.com>
Tested-by: NVIET NGA DAO <vndao@altera.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.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: NBean Huo <beanhuo@micron.com>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This will allow spi-nor users to plainly use JEDEC to detect flash chip.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBrian 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: NBrian Norris <computersforpeace@gmail.com>
Acked-by: NHuang 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: NHuang Shijie <shijie.huang@intel.com>
Signed-off-by: NBrian 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: NHuang Shijie <shijie.huang@intel.com>
Signed-off-by: NBrian 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: NHuang Shijie <shijie.huang@intel.com>
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Signed-off-by: NKnut Wohlrab <knut.wohlrab@de.bosch.com>
Signed-off-by: NAlison Chaiken <alison_chaiken@mentor.com>
Reviewed-by: NJagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Signed-off-by: NBrian 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: NBrian Norris <computersforpeace@gmail.com>
Acked-by: NHuang Shijie <shijie.huang@intel.com>
Reviewed-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>

Add sst25wf080 to the spi-nor device id table.
Signed-off-by: NHarini Katakam <harinik@xilinx.com>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Tested with this particular FRAM chip
Signed-off-by: NRostislav Lisovy <lisovy@merica.cz>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBrian 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: NChunhe 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: NMarek Vasut <marex@denx.de>
Signed-off-by: NBrian 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: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NMarek 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: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NMarek 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: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NMarek Vasut <marex@denx.de>
Acked-by: NHuang 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: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NMarek Vasut <marex@denx.de>
Cc: Graham Moore <grmoore@altera.com>
Cc: Huang Shijie <shijie8@gmail.com>
Signed-off-by: NBrian 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: NHuang Shijie <b32955@freescale.com>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBrian 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: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NBrian 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: 03e296f6 ("mtd: m25p80: use the SPI nor framework")
Cc: <stable@vger.kernel.org> # 3.16.x: 32f1b7c8: mtd: move support for struct flash_platform_data into m25p80
Cc: <stable@vger.kernel.org> # 3.16.x: 90e55b38: mtd: m25p80: get rid of spi_get_device_id
Cc: <stable@vger.kernel.org> # 3.16.x: 70f3ce05: 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: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NBrian 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: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBrian 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: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBrian 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: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBrian 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: NRafał Miłecki <zajec5@gmail.com>
Acked-by: NHuang Shijie <shijie8@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Acked-by: NHuang Shijie <shijie8@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>