The S28 flash family uses 2-bit ECC by default with each ECC block being
16 bytes. Under this scheme multi-pass programming to an ECC block is
not allowed. Set the writesize to make sure multi-pass programming is
not attempted on the flash.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20201201102711.8727-4-p.yadav@ti.com
The Cypress Semper flash is an xSPI compliant octal DTR flash. Add
support for using it in octal DTR mode.
The flash by default boots in a hybrid sector mode. But the sector map
table on the part I had was programmed incorrectly and the SMPT values
on the flash don't match the public datasheet. Specifically, in some
places erase type 3 was used instead of 4. In addition, the region sizes
were incorrect in some places. So, for testing I set CFR3N[3] to enable
uniform sector sizes. Since the uniform sector mode bit is a
non-volatile bit, this series does not change it to avoid making any
permanent changes to the flash configuration. The correct data to
implement a fixup is not available right now and will be done in a
follow-up patch if needed.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
[vigneshr@ti.com: Drop unnecessary sleep in Octal DTR switch sequence]
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20201005153138.6437-15-p.yadav@ti.com
Both w25q64 and s25fl064k nor flash support QUAD and DUAL read
command, hence update the same in flash_info table.
This is tested on Broadcom Stingray SoC (bcm958742t).
s25fl064k and w25q64 share the same JEDEC ID. The search alg will
return the first hit, so s25fl064k even for the winbond parts. We
should differentiate between these flashes, but it's not in the
scope of this patch. Related discussion at:
Link: https://lore.kernel.org/patchwork/patch/628090/
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Link: https://lore.kernel.org/r/20200529071655.739-1-rayagonda.kokatanur@broadcom.com
[tudor.ambarus@microchip.com: Update commit message and indicate that
s25fl064k and w25q64 share the same JEDEC ID]
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
The s70fl01gs is a dual die stack of two s25fl512s die with dedicated chip
select pins to each. Tested with the device and confirmed that is working
as two s25fl512s devices. The current device ID in the flash_info table
matches with s70fs01gs which does not work with current MTD (s70fs01gs
does not support RDSR(05h) which is critical for erase/write).
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@cypress.com>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20200626051650.495-1-Takahiro.Kuwano@cypress.com
The Cypress cy15b104q and cy15v104q are 4Mbit serial SPI F-RAM devices.
Add support for them to the spi-nor driver.
The actual Device ID of this chip is 7f 7f 7f 7f 7f 7f c2 2c 04. That is
six times the continuation code 7f followed by c2 for Ramtron.
Unfortunately the chip sends the Device ID in reversed order, so the
continuation code is not at the beginning, but instead at the end. Even
more unfortunate is that when reading further the chip sends more 7f
codes which means we are not even able to count the continuation codes.
We can only hope that this reversed Device ID will never match any other
devices ID.
Collisions are improbable as of now, the solution from above is good
enough. In case of future collisions one can introduce an INFO9 macro,
with the downsize that struct flash_info would grow and we have lots of
flashes. A more elegant solution would be to introduce dedicated
flash ID tables for each bank in JESP106BA.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
[tudor.ambarus@microchip.com: amend commit description with possible
future solutions in case collisions occur.]
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
s25fs256s was identified as s25fl256s. Differentiate between them by
the Family ID using the INFO6 macro.
Fixes: b199489d37 ("mtd: spi-nor: add the framework for SPI NOR")
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Add support for Cypress s25fs128s1 flash. Previously the flash is
decoded as s25fl129p1 by mistake.
Add it in the flash info list to correctly decode. The flash also
needs a fixup for s25fs-s family. Further capability of the flash will
be parsed from bfpt.
The flash has been tested under SPI/DUAL/QUAD mode on hisi-sfc-v3xx
controller, all the write/read/erase works well.
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Spansion S25FS-S family has an issue in the Basic Flash Parameter Table
(BFPT): Dword-11 bits 7:4 specify a page size of 512 bytes. Actually
this is configurable in the vendor unique register (CR3V) and even the
factory default setting is to "wrap at 256 bytes", so blindly relying
on BFPT breaks the page writes on these chips. Add the post-BFPT fixup
which restores the default page size of 256 bytes -- to properly read
CR3V this early is quite intrusive and should better be done as a new
feature; Alexander Sverdlin had the patch doing that:
https://patchwork.ozlabs.org/project/linux-mtd/patch/20200227123657.26030-1-alexander.sverdlin@nokia.com/
Fixes: dfd2b74530 ("mtd: spi-nor: add Spansion S25FS512S ID")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Tested-by: Kuldeep Singh <kuldeep.singh@nxp.com>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
The s25fl256s0 supports dual and quad read like s25fl256s1.
Enable it by adding SPI_NOR_DUAL_READ and SPI_NOR_QUAD_READ
flags to the flash_info entry. Tested with the device and
confirmed that is working.
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@cypress.com>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
The SPI NOR controllers drivers must not be able to use structures that
are meant just for the SPI NOR core.
struct spi_nor_flash_parameter is filled at run-time with info gathered
from flash_info, manufacturer and sfdp data. struct spi_nor_flash_parameter
should be opaque to the SPI NOR controller drivers, make sure it is.
spi_nor_option_flags, spi_nor_read_command, spi_nor_pp_command,
spi_nor_read_command_index and spi_nor_pp_command_index are defined for the
core use, make sure they are opaque to the SPI NOR controller drivers.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Create a SPI NOR manufacturer driver for Spansion chips, and move the
Spansion definitions outside of core.c.
Signed-off-by: Boris Brezillon <bbrezillon@kernel.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Pratyush Yadav