SF: Migrate to Linux SPI NOR framework
Subsystems (11)
Vignesh R
maintainercover SF: Migrate to Linux SPI NOR framework
U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
This patch series syncs SPI NOR framework from Linux v4.19. It also adds spi-mem support on top.
So, we gain 4byte addressing support and SFDP support. This makes migrating to U-Boot MTD framework easier.
Tested with few Spansion, micron and macronix flashes with TI's dra7xx, k2g, am43xx EVMs. I dont have access to flashes from other vendors. So, I would greatly appreciate testing on other platforms. Complete series with dependencies here[1]
For clean build on some platforms, depends on CONFIG_SPI_FLASH migration to defconfigs [2]
[1] https://github.com/r-vignesh/u-boot.git branch: spi-nor-mig-patch-v1
[2] https://patchwork.ozlabs.org/patch/1007485/
Patch 12-15 are compile tested.
Change log:
Since RFC v2:
Fix issues reported by Simon Goldschmidt wrt 4 use of byte addressing opcode Fix issues in compiling SFDP code
Re organize file names and Makefile to simply spi-nor-tiny inclusion Remove SPI_FLASH_BAR and SF_DUAL_FLASH as these are no longer used RFC v2: https://patchwork.ozlabs.org/cover/1007589/
Since RFC v1:
Add lightweight SPI flash stack for boards with SPL size constraints Provide non DM version of spi-mem
Fix build issues on different platforms as reported by travis-ci on v1
RFC v1: https://patchwork.ozlabs.org/cover/1004689/
Vignesh R (16):
spi: spi-mem: Allow use of spi_mem_exec_op for all SPI modes
spi-mem: Claim SPI bus before spi mem access
spi: Add non DM version of SPI_MEM
sh: bitops: add hweight*() macros
mtd: spi: Port SPI NOR framework from Linux
mtd: spi: Switch to new SPI NOR framework
mtd: spi: Remove unused files
mtd: spi: Add lightweight SPI flash stack for SPL
sf_mtd: Simply mtd operations
configs: Get rid of SPI_FLASH_BAR
configs: Remove SF_DUAL_FLASH
axm_defconfig: Enable simple malloc in SPL
taurus_defconfig: Enable simple malloc in SPL
da850_am18xxevm: Enable tiny printf
turris_omnia_defconfig: Enable tiny printf
MAINTAINERS: Add an entry for SPI NOR
MAINTAINERS | 8 + arch/arm/mach-omap2/am33xx/Kconfig | 1 - arch/sh/include/asm/bitops.h | 4 + common/spl/Kconfig | 21 +- configs/alt_defconfig | 1 - configs/am57xx_evm_defconfig | 1 - configs/am57xx_hs_evm_defconfig | 1 - configs/ap121_defconfig | 1 - configs/ap143_defconfig | 1 - configs/avnet_ultra96_rev1_defconfig | 1 - configs/axm_defconfig | 1 + configs/axs101_defconfig | 1 - configs/axs103_defconfig | 1 - configs/bg0900_defconfig | 1 - configs/blanche_defconfig | 1 - configs/cl-som-am57x_defconfig | 1 - configs/clearfog_defconfig | 1 - configs/cm_t43_defconfig | 1 - configs/da850_am18xxevm_defconfig | 1 + configs/db-88f6820-amc_defconfig | 1 - configs/display5_defconfig | 1 - configs/display5_factory_defconfig | 1 - configs/dra7xx_evm_defconfig | 1 - configs/dra7xx_hs_evm_defconfig | 1 - configs/ds109_defconfig | 1 - configs/ds414_defconfig | 1 - configs/evb-rv1108_defconfig | 1 - configs/gose_defconfig | 1 - configs/helios4_defconfig | 1 - configs/k2g_evm_defconfig | 1 - configs/k2g_hs_evm_defconfig | 1 - configs/koelsch_defconfig | 1 - configs/lager_defconfig | 1 - configs/maxbcm_defconfig | 1 - configs/mt7629_rfb_defconfig | 1 - configs/mx6sxsabreauto_defconfig | 1 - configs/mx6sxsabresd_defconfig | 1 - configs/mx6ul_14x14_evk_defconfig | 1 - configs/mx6ul_9x9_evk_defconfig | 1 - configs/mx6ull_14x14_evk_defconfig | 1 - configs/mx6ull_14x14_evk_plugin_defconfig | 1 - configs/mx7dsabresd_qspi_defconfig | 1 - configs/porter_defconfig | 1 - configs/r8a77970_eagle_defconfig | 1 - configs/silk_defconfig | 1 - configs/socfpga_arria5_defconfig | 1 - configs/socfpga_cyclone5_defconfig | 1 - configs/socfpga_is1_defconfig | 1 - configs/socfpga_sockit_defconfig | 1 - configs/socfpga_socrates_defconfig | 1 - configs/socfpga_sr1500_defconfig | 1 - configs/socfpga_stratix10_defconfig | 1 - configs/stout_defconfig | 1 - configs/taurus_defconfig | 1 + configs/topic_miami_defconfig | 1 - configs/topic_miamilite_defconfig | 2 - configs/topic_miamiplus_defconfig | 2 - configs/turris_omnia_defconfig | 2 +- configs/xilinx_versal_virt_defconfig | 1 - configs/xilinx_zynqmp_mini_qspi_defconfig | 2 - configs/xilinx_zynqmp_zc1232_revA_defconfig | 2 - configs/xilinx_zynqmp_zc1254_revA_defconfig | 2 - configs/xilinx_zynqmp_zc1275_revA_defconfig | 2 - configs/xilinx_zynqmp_zc1275_revB_defconfig | 2 - .../xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 - .../xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 - .../xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 1 - configs/xilinx_zynqmp_zcu100_revC_defconfig | 1 - configs/xilinx_zynqmp_zcu102_rev1_0_defconfig | 1 - configs/xilinx_zynqmp_zcu102_revA_defconfig | 1 - configs/xilinx_zynqmp_zcu102_revB_defconfig | 1 - configs/xilinx_zynqmp_zcu104_revA_defconfig | 2 - configs/xilinx_zynqmp_zcu104_revC_defconfig | 2 - configs/xilinx_zynqmp_zcu106_revA_defconfig | 2 - configs/xilinx_zynqmp_zcu111_revA_defconfig | 1 - configs/zynq_cc108_defconfig | 1 - configs/zynq_cse_qspi_defconfig | 1 - configs/zynq_dlc20_rev1_0_defconfig | 1 - configs/zynq_microzed_defconfig | 1 - configs/zynq_minized_defconfig | 1 - configs/zynq_z_turn_defconfig | 1 - configs/zynq_zc702_defconfig | 1 - configs/zynq_zc706_defconfig | 1 - configs/zynq_zc770_xm010_defconfig | 1 - configs/zynq_zc770_xm013_defconfig | 1 - configs/zynq_zed_defconfig | 1 - configs/zynq_zybo_defconfig | 1 - configs/zynq_zybo_z7_defconfig | 1 - doc/SPI/README.dual-flash | 92 - doc/SPI/README.ti_qspi_dra_test | 1 - drivers/mtd/spi/Kconfig | 22 +- drivers/mtd/spi/Makefile | 12 +- drivers/mtd/spi/sandbox.c | 36 +- drivers/mtd/spi/sf_dataflash.c | 11 +- drivers/mtd/spi/sf_internal.h | 230 +- drivers/mtd/spi/sf_mtd.c | 52 +- drivers/mtd/spi/sf_probe.c | 38 +- drivers/mtd/spi/spi-nor-core.c | 2334 +++++++++++++++++ drivers/mtd/spi/spi-nor-ids.c | 294 +++ drivers/mtd/spi/spi-nor-tiny.c | 810 ++++++ drivers/mtd/spi/spi_flash.c | 1337 ---------- drivers/mtd/spi/spi_flash_ids.c | 211 -- drivers/spi/Kconfig | 4 +- drivers/spi/Makefile | 1 + drivers/spi/spi-mem-nodm.c | 89 + drivers/spi/spi-mem.c | 15 +- drivers/spi/stm32_qspi.c | 4 +- include/configs/T102xQDS.h | 1 - include/configs/T102xRDB.h | 1 - include/configs/T104xRDB.h | 1 - include/configs/T208xQDS.h | 1 - include/configs/T208xRDB.h | 1 - include/configs/gw_ventana.h | 1 - include/configs/km/kmp204x-common.h | 1 - include/configs/ls1021aiot.h | 1 - include/configs/socfpga_stratix10_socdk.h | 1 - include/linux/mtd/cfi.h | 32 + include/linux/mtd/spi-nor.h | 421 +++ include/spi_flash.h | 105 +- 119 files changed, 4179 insertions(+), 2110 deletions(-) delete mode 100644 doc/SPI/README.dual-flash create mode 100644 drivers/mtd/spi/spi-nor-core.c create mode 100644 drivers/mtd/spi/spi-nor-ids.c create mode 100644 drivers/mtd/spi/spi-nor-tiny.c delete mode 100644 drivers/mtd/spi/spi_flash.c delete mode 100644 drivers/mtd/spi/spi_flash_ids.c create mode 100644 drivers/spi/spi-mem-nodm.c create mode 100644 include/linux/mtd/cfi.h create mode 100644 include/linux/mtd/spi-nor.h
Signature · 1 line
2.19.2
Vignesh R
maintainerPATCH 1/16 spi: spi-mem: Allow use of spi_mem_exec_op for all SPI modes
SPI controllers support all types of SPI modes including dual/quad bus widths. Therefore remove constraint wrt SPI mode from spi-mem layer.
--- drivers/spi/spi-mem.c | 9 --------- 1 file changed, 9 deletions(-)
drivers/spi/spi-mem.c +0 -9
@@ -323,15 +323,6 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct spi_mem_op *op)return -EIO ;#else -/* U-Boot does not support parallel SPI data lanes */ -if ((op->cmd.buswidth !=1 ) || - (op->addr.nbytes && op->addr.buswidth !=1 ) || - (op->dummy.nbytes && op->dummy.buswidth !=1 ) || - (op->data.nbytes && op->data.buswidth !=1 )) { -printf ("Dual/Quad raw SPI transfers not supported\n" ); -return -ENOTSUPP ; - } -if (op->data.nbytes) {if (op->data.dir ==SPI_MEM_DATA_IN ) rx_buf = op->data.buf.in;
Signature · 1 line
2.19.2
Vignesh R
maintainerPATCH 2/16 spi-mem: Claim SPI bus before spi mem access
In reply to Vignesh RIt is necessary to call spi_claim_bus() before starting any SPI transactions and this restriction would also apply when calling spi-mem operationss. Therefore claim and release bus before requesting transfer via exec_op.
--- drivers/spi/spi-mem.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/spi/spi-mem.c +6 -0
@@ -231,7 +231,13 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct spi_mem_op *op)mutex_lock (&ctlr->bus_lock_mutex);mutex_lock (&ctlr->io_mutex);#endif + ret =spi_claim_bus (slave); +if (ret <0 ) +return ret; + ret = ops->mem_ops->exec_op (slave, op); + +spi_release_bus (slave);#ifndef __UBOOT__mutex_unlock (&ctlr->io_mutex);mutex_unlock (&ctlr->bus_lock_mutex);
Signature · 1 line
2.19.2
Vignesh R
maintainerPATCH 3/16 spi: Add non DM version of SPI_MEM
In reply to Vignesh RAdd non DM version of SPI_MEM to support easy migration to new SPI NOR framework. This can be removed once DM_SPI conversion is complete.
--- drivers/spi/Kconfig | 4 +- drivers/spi/Makefile | 1 + drivers/spi/spi-mem-nodm.c | 89 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 92 insertions(+), 2 deletions(-) create mode 100644 drivers/spi/spi-mem-nodm.c
drivers/spi/Kconfig +2 -2
@@ -16,8 +16,6 @@ config DM_SPI typically use driver-private data instead of extending the spi_slave structure. -if DM_SPI - config SPI_MEM bool "SPI memory extension" help
@@ -25,6 +23,8 @@ config SPI_MEM This extension is meant to simplify interaction with SPI memories by providing an high-level interface to send memory-like commands. +if DM_SPI + config ALTERA_SPI bool "Altera SPI driver" help
drivers/spi/Makefile +1 -0
@@ -11,6 +11,7 @@ obj-$(CONFIG_SOFT_SPI) += soft_spi.o obj-$(CONFIG_SPI_MEM) += spi-mem.o else obj-y += spi.o +obj-$(CONFIG_SPI_MEM) += spi-mem-nodm.o obj-$(CONFIG_SOFT_SPI) += soft_spi_legacy.o endif
drivers/spi/spi-mem-nodm.c new file +89 -0
89 lines not on this page · raw message
Signature · 1 line
2.19.2
PATCH 3/16 spi: Add non DM version of SPI_MEM
Quoted 3 lines · Vignesh R
Add non DM version of
SPI_MEMto support easy migration to new SPI NOR framework. This can be removed onceDM_SPIconversion is complete.
Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?
PATCH 3/16 spi: Add non DM version of SPI_MEM
Hi Jagan,
Quoted 7 lines · On Thu, 13 Dec 2018 01:55:08 +0530 Jagan Teki <[email protected]>…
Quoted 3 lines · Vignesh R
Add non DM version of
SPI_MEMto support easy migration to new SPI NOR framework. This can be removed onceDM_SPIconversion is complete.Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?
Looks like we're having the same discussion over and over. Vignesh is dropping spi_flash.c which AFAICT was not depending on DM_SPI, so, if we want to keep everyone happy while getting rid of some legacy code, that's the only solution. DM conversion is a nice goal, but it's kind of orthogonal to what Vignesh is working on. If DM_SPI conversion happens before the spi-nor stuff is merged (which I doubt) then this patch can simply be dropped.
PATCH 3/16 spi: Add non DM version of SPI_MEM
Quoted 14 lines · Boris Brezillon
Hi Jagan,
Quoted 7 lines · On Thu, 13 Dec 2018 01:55:08 +0530 Jagan Teki <[email protected]>…
Quoted 3 lines · Vignesh R
Add non DM version of
SPI_MEMto support easy migration to new SPI NOR framework. This can be removed onceDM_SPIconversion is complete.Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?
Quoted 7 lines
Looks like we're having the same discussion over and over. Vignesh is dropping
spi_flash.cwhich AFAICT was not depending onDM_SPI, so, if we want to keep everyone happy while getting rid of some legacy code, that's the only solution. DM conversion is a nice goal, but it's kind of orthogonal to what Vignesh is working on. IfDM_SPIconversion happens before the spi-nor stuff is merged (which I doubt) then this patch can simply be dropped.
spi_flash.c is a core code not a specific driver it belongs. spi-mem is new feature driver how come new driver will support legacy non-dm do we have legacy use for that(ie what I'm asking about usecase)
PATCH 3/16 spi: Add non DM version of SPI_MEM
Quoted 24 lines · On Thu, 13 Dec 2018 02:15:16 +0530 Jagan Teki <[email protected]>…
Quoted 14 lines · Boris Brezillon
Hi Jagan,
Quoted 7 lines · On Thu, 13 Dec 2018 01:55:08 +0530 Jagan Teki <[email protected]>…
Quoted 3 lines · Vignesh R
Add non DM version of
SPI_MEMto support easy migration to new SPI NOR framework. This can be removed onceDM_SPIconversion is complete.Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?
Quoted 7 lines
Looks like we're having the same discussion over and over. Vignesh is dropping
spi_flash.cwhich AFAICT was not depending onDM_SPI, so, if we want to keep everyone happy while getting rid of some legacy code, that's the only solution. DM conversion is a nice goal, but it's kind of orthogonal to what Vignesh is working on. IfDM_SPIconversion happens before the spi-nor stuff is merged (which I doubt) then this patch can simply be dropped.
Quoted 3 lines
spi_flash.cis a core code not a specific driver it belongs. spi-mem is new feature driver how come new driver will support legacy non-dm do we have legacy use for that(ie what I'm asking about usecase)
I recommend that you read the spi-mem code carefully. spi-mem is not driver specific, it's a thin layer on top of spi and driver *can* (but are not forced to) provide optimized methods to execute spi-mem operations. When that's not the case, the implementation falls back to regular spi transfers. AFAIK, both DM and non-DM drivers support regular spi transfers, right? So why should we depend on DM_SPI? And more importantly, if we do that, that means we can't get rid of spi_flash.c since some users might still have non-DM SPI drivers, which in turn means we keep more legacy code for no good reasons.
You want non-DM SPI controller drivers to go away, then remove them, instead of blocking other changes using this excuse.
PATCH 3/16 spi: Add non DM version of SPI_MEM
Quoted 34 lines · On Wed 12 Dec, 2018, 10:02 PM Boris Brezillon <[email protected]…
Quoted 9 lines · On Thu, 13 Dec 2018 02:15:16 +0530 Jagan Teki <[email protected]>…
Quoted 7 lines · Boris Brezillon
Hi Jagan,
Quoted 1 line · On Thu, 13 Dec 2018 01:55:08 +0530 Jagan Teki <[email protected]>…
On Wed, Dec 12, 2018 at 11:08 PM Vignesh R <[email protected]>
Quoted 2 lines · wrote:
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Add non DM version of
SPI_MEMto support easy migration to new SPINOR
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
framework. This can be removed once
DM_SPIconversion iscomplete.
Quoted 12 lines
Quoted 11 lines
Quoted 3 lines
Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?
Looks like we're having the same discussion over and over. Vignesh is dropping
spi_flash.cwhich AFAICT was not depending onDM_SPI, so, if we want to keep everyone happy while getting rid of some legacy code, that's the only solution. DM conversion is a nice goal, but it's kind of orthogonal to what Vignesh is working on. IfDM_SPIconversion happens before the spi-nor stuff is merged (which I doubt) then this patch can simply be dropped.Quoted 3 lines
spi_flash.cis a core code not a specific driver it belongs. spi-mem is new feature driver how come new driver will support legacy non-dm do we have legacy use for that(ie what I'm asking about usecase)
Quoted 10 lines
I recommend that you read the spi-mem code carefully. spi-mem is not driver specific, it's a thin layer on top of spi and driver *can* (but are not forced to) provide optimized methods to execute spi-mem operations. When that's not the case, the implementation falls back to regular spi transfers. AFAIK, both DM and non-DM drivers support regular spi transfers, right? So why should we depend on
DM_SPI? And more importantly, if we do that, that means we can't get rid ofspi_flash.csince some users might still have non-DM SPI drivers, which in turn means we keep more legacy code for no good reasons.
I understand spi-mem is core file, but new code too.
Quoted 3 lines
You want non-DM SPI controller drivers to go away, then remove them, instead of blocking other changes using this excuse.
Please understand uboot development flow, legacy driver can be removed if possible once migration expire and NEW drivers or code must be dm driven.
Quoted 1 line
PATCH 3/16 spi: Add non DM version of SPI_MEM
Quoted 48 lines · On Wed, 12 Dec 2018 22:07:44 +0100 Jagan Teki <[email protected]>…
Quoted 34 lines · On Wed 12 Dec, 2018, 10:02 PM Boris Brezillon <[email protected]…
Quoted 9 lines · On Thu, 13 Dec 2018 02:15:16 +0530 Jagan Teki <[email protected]>…
Quoted 7 lines · Boris Brezillon
Hi Jagan,
Quoted 1 line · On Thu, 13 Dec 2018 01:55:08 +0530 Jagan Teki <[email protected]>…
On Wed, Dec 12, 2018 at 11:08 PM Vignesh R <[email protected]>
Quoted 2 lines · wrote:
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Add non DM version of
SPI_MEMto support easy migration to new SPINOR
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
framework. This can be removed once
DM_SPIconversion iscomplete.
Quoted 12 lines
Quoted 11 lines
Quoted 3 lines
Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?
Looks like we're having the same discussion over and over. Vignesh is dropping
spi_flash.cwhich AFAICT was not depending onDM_SPI, so, if we want to keep everyone happy while getting rid of some legacy code, that's the only solution. DM conversion is a nice goal, but it's kind of orthogonal to what Vignesh is working on. IfDM_SPIconversion happens before the spi-nor stuff is merged (which I doubt) then this patch can simply be dropped.Quoted 3 lines
spi_flash.cis a core code not a specific driver it belongs. spi-mem is new feature driver how come new driver will support legacy non-dm do we have legacy use for that(ie what I'm asking about usecase)Quoted 10 lines
I recommend that you read the spi-mem code carefully. spi-mem is not driver specific, it's a thin layer on top of spi and driver *can* (but are not forced to) provide optimized methods to execute spi-mem operations. When that's not the case, the implementation falls back to regular spi transfers. AFAIK, both DM and non-DM drivers support regular spi transfers, right? So why should we depend on
DM_SPI? And more importantly, if we do that, that means we can't get rid ofspi_flash.csince some users might still have non-DM SPI drivers, which in turn means we keep more legacy code for no good reasons.
Quoted 1 line
I understand spi-mem is core file, but new code too.
Sorry, I don't get it.
Quoted 8 lines
Quoted 5 lines
You want non-DM SPI controller drivers to go away, then remove them, instead of blocking other changes using this excuse.
Please understand uboot development flow, legacy driver can be removed if possible once migration expire and NEW drivers or code must be dm driven.
Sorry, but I think you're the one misunderstanding what we are trying to do here. Vignesh changes have simply no impact on the DM SPI conversion you're aiming at. All Vignesh does is provide a dummy wrapper for non-DM drivers, which would probably have been implemented by Miquel if you had not been so insistent on your precious DM_SPI conversion. That was not really a problem for spi-nand, as we were adding support for a new feature. This is not the case here. SPI NORs are already partially supported by the u-boot spi flash layer, and we need to keep things in a working state for those that were using it and didn't have their SPI controller drivers converted to the DM. This leaves us 2 options:
1/ keep the sf_flash code as is and add a new spi-nor code base 2/ replace spi_flash code by the spi-nor layer imported from Linux
Vignesh chose option #2 which has the benefit of avoiding code duplication. Given the discussion we're having right now, I'm wondering if it wouldn't be easier to go for option #1 in order to avoid those endless discussions...
PATCH 3/16 spi: Add non DM version of SPI_MEM
Quoted 65 lines · Boris Brezillon
Quoted 48 lines · On Wed, 12 Dec 2018 22:07:44 +0100 Jagan Teki <[email protected]>…
Quoted 34 lines · On Wed 12 Dec, 2018, 10:02 PM Boris Brezillon <[email protected]…
Quoted 9 lines · On Thu, 13 Dec 2018 02:15:16 +0530 Jagan Teki <[email protected]>…
Quoted 7 lines · Boris Brezillon
Hi Jagan,
Quoted 1 line · On Thu, 13 Dec 2018 01:55:08 +0530 Jagan Teki <[email protected]>…
On Wed, Dec 12, 2018 at 11:08 PM Vignesh R <[email protected]>
Quoted 2 lines · wrote:
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Add non DM version of
SPI_MEMto support easy migration to new SPINOR
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
framework. This can be removed once
DM_SPIconversion iscomplete.
Quoted 12 lines
Quoted 11 lines
Quoted 3 lines
Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?
Looks like we're having the same discussion over and over. Vignesh is dropping
spi_flash.cwhich AFAICT was not depending onDM_SPI, so, if we want to keep everyone happy while getting rid of some legacy code, that's the only solution. DM conversion is a nice goal, but it's kind of orthogonal to what Vignesh is working on. IfDM_SPIconversion happens before the spi-nor stuff is merged (which I doubt) then this patch can simply be dropped.Quoted 3 lines
spi_flash.cis a core code not a specific driver it belongs. spi-mem is new feature driver how come new driver will support legacy non-dm do we have legacy use for that(ie what I'm asking about usecase)Quoted 10 lines
I recommend that you read the spi-mem code carefully. spi-mem is not driver specific, it's a thin layer on top of spi and driver *can* (but are not forced to) provide optimized methods to execute spi-mem operations. When that's not the case, the implementation falls back to regular spi transfers. AFAIK, both DM and non-DM drivers support regular spi transfers, right? So why should we depend on
DM_SPI? And more importantly, if we do that, that means we can't get rid ofspi_flash.csince some users might still have non-DM SPI drivers, which in turn means we keep more legacy code for no good reasons.Quoted 1 line
I understand spi-mem is core file, but new code too.
Sorry, I don't get it.
Quoted 8 lines
Quoted 5 lines
You want non-DM SPI controller drivers to go away, then remove them, instead of blocking other changes using this excuse.
Please understand uboot development flow, legacy driver can be removed if possible once migration expire and NEW drivers or code must be dm driven.
Quoted 6 lines
Sorry, but I think you're the one misunderstanding what we are trying to do here. Vignesh changes have simply no impact on the DM SPI conversion you're aiming at. All Vignesh does is provide a dummy wrapper for non-DM drivers, which would probably have been implemented by Miquel if you had not been so insistent on your precious
DM_SPIconversion. That was not really a problem for spi-nand, as we were
I'm sure, I'm in right direction.
This is what I asked in the first mail,
"Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?"
and I have the answer on this thread about the use case.
I do really understand your intention about the real question.
- Any code or generic code will add in U-Boot should be driver-model driven, are you agree this point?
Yes- thanks.
No - we need to have separate discussion.
Any code that related to spi, or spi-flash should be driver-model driven, ie what my AIM as a Maintainer (ie only reason for my spi-nor changes resist for long time to fit).
PATCH 3/16 spi: Add non DM version of SPI_MEM
Quoted 89 lines · Jagan Teki
Quoted 65 lines · Boris Brezillon
Quoted 48 lines · On Wed, 12 Dec 2018 22:07:44 +0100 Jagan Teki <[email protected]>…
Quoted 34 lines · On Wed 12 Dec, 2018, 10:02 PM Boris Brezillon <[email protected]…
Quoted 9 lines · On Thu, 13 Dec 2018 02:15:16 +0530 Jagan Teki <[email protected]>…
Quoted 7 lines · Boris Brezillon
Hi Jagan,
Quoted 1 line · On Thu, 13 Dec 2018 01:55:08 +0530 Jagan Teki <[email protected]>…
On Wed, Dec 12, 2018 at 11:08 PM Vignesh R <[email protected]>
Quoted 2 lines · wrote:
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Add non DM version of
SPI_MEMto support easy migration to new SPINOR
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
framework. This can be removed once
DM_SPIconversion iscomplete.
Quoted 12 lines
Quoted 11 lines
Quoted 3 lines
Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?
Looks like we're having the same discussion over and over. Vignesh is dropping
spi_flash.cwhich AFAICT was not depending onDM_SPI, so, if we want to keep everyone happy while getting rid of some legacy code, that's the only solution. DM conversion is a nice goal, but it's kind of orthogonal to what Vignesh is working on. IfDM_SPIconversion happens before the spi-nor stuff is merged (which I doubt) then this patch can simply be dropped.Quoted 3 lines
spi_flash.cis a core code not a specific driver it belongs. spi-mem is new feature driver how come new driver will support legacy non-dm do we have legacy use for that(ie what I'm asking about usecase)Quoted 10 lines
I recommend that you read the spi-mem code carefully. spi-mem is not driver specific, it's a thin layer on top of spi and driver *can* (but are not forced to) provide optimized methods to execute spi-mem operations. When that's not the case, the implementation falls back to regular spi transfers. AFAIK, both DM and non-DM drivers support regular spi transfers, right? So why should we depend on
DM_SPI? And more importantly, if we do that, that means we can't get rid ofspi_flash.csince some users might still have non-DM SPI drivers, which in turn means we keep more legacy code for no good reasons.Quoted 1 line
I understand spi-mem is core file, but new code too.
Sorry, I don't get it.
Quoted 8 lines
Quoted 5 lines
You want non-DM SPI controller drivers to go away, then remove them, instead of blocking other changes using this excuse.
Please understand uboot development flow, legacy driver can be removed if possible once migration expire and NEW drivers or code must be dm driven.
Quoted 6 lines
Sorry, but I think you're the one misunderstanding what we are trying to do here. Vignesh changes have simply no impact on the DM SPI conversion you're aiming at. All Vignesh does is provide a dummy wrapper for non-DM drivers, which would probably have been implemented by Miquel if you had not been so insistent on your precious
DM_SPIconversion. That was not really a problem for spi-nand, as we wereI'm sure, I'm in right direction.
This is what I asked in the first mail,
"Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?"
and I have the answer on this thread about the use case.
I do really understand your intention about the real question.
- Any code or generic code will add in U-Boot should be driver-model driven, are you agree this point?
Yes- thanks.
No - we need to have separate discussion.
Quoted 3 lines
Any code that related to spi, or spi-flash should be driver-model driven, ie what my AIM as a Maintainer (ie only reason for my spi-nor changes resist for long time to fit).
And since we have both been "stuck" for so very long and a clear commitment from a few people to follow through on the "and DM it after" part, I'm OK with bending the rules.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181212/d41e7ec4/attachment.sig>
PATCH 3/16 spi: Add non DM version of SPI_MEM
In reply to Jagan TekiQuoted 6 lines · On Thu, 13 Dec 2018 04:40:30 +0530 Jagan Teki <[email protected]>…
I do really understand your intention about the real question.
- Any code or generic code will add in U-Boot should be driver-model driven, are you agree this point?
Yes- thanks.
No - we need to have separate discussion.
Depends on what you mean by driver-model driven. Yes, applying the DM sometimes makes sense, but blindly trying to push it everywhere just for the sake of being "DM compliant" is a huge mistake IMO. One example of the thing you suggested which didn't make sense at all: force MTD users to manipulate udevice objects instead of mtd_info ones.
Quoted 4 lines
Any code that related to spi, or spi-flash should be driver-model driven, ie what my AIM as a Maintainer (ie only reason for my spi-nor changes resist for long time to fit).
You seem to use the term "driver-model" a lot without clearly explaining what you have in mind. The driver-model should be used where it makes sense, but some of your suggestions don't make any sense to me. Like the proposal to add a SPI NOR uclass while we already have an MTD uclass which works just fine for all kind of flash devices.
Oh, and this strict rule that says "don't provide wrappers to handle non-DM compliant cases" is just wrong. As I said, none of these dummy wrappers prevent you from enforcing DM_SPI conversion, and it allows us to support existing HW while getting rid of the old code base. Plus, I suggested to declare the spi-nor driver as an MTD uclass so it's not like we're completely ignoring your comments :P.
PATCH 3/16 spi: Add non DM version of SPI_MEM
Quoted 11 lines · Boris Brezillon
Quoted 6 lines · On Thu, 13 Dec 2018 04:40:30 +0530 Jagan Teki <[email protected]>…
I do really understand your intention about the real question.
- Any code or generic code will add in U-Boot should be driver-model driven, are you agree this point?
Yes- thanks.
No - we need to have separate discussion.
Quoted 5 lines
Depends on what you mean by driver-model driven. Yes, applying the DM sometimes makes sense, but blindly trying to push it everywhere just for the sake of being "DM compliant" is a huge mistake IMO. One example of the thing you suggested which didn't make sense at all: force MTD users to manipulate udevice objects instead of
mtd_infoones.
(+ Simon)
ie How we proceed when DM is introduced in U-Boot. May be you can ask Simon or Other DM fellow developers if my statement doesn't make sense to you. ie whole reason of spi-nor changes last for year.
Quoted 11 lines
Quoted 5 lines
Any code that related to spi, or spi-flash should be driver-model driven, ie what my AIM as a Maintainer (ie only reason for my spi-nor changes resist for long time to fit).
You seem to use the term "driver-model" a lot without clearly explaining what you have in mind. The driver-model should be used where it makes sense, but some of your suggestions don't make any sense to me. Like the proposal to add a SPI NOR uclass while we already have an MTD uclass which works just fine for all kind of flash devices.
You better read the thread carefully. read what I'm saying on the thread[1]
" So, if no driver should be part of spi-nor and all can be handle spi-mem even-though they have controller specific features, yes we can skip SPI_NOR_UCLASS otherwise we need spi-nor uclass that can be child uclass of MTD"
Did it state insisting SPI-NOR uclass, I was clearly giving if condition here.
PATCH 3/16 spi: Add non DM version of SPI_MEM
Hi,
Quoted 20 lines · Jagan Teki
Quoted 11 lines · Boris Brezillon
Quoted 6 lines · On Thu, 13 Dec 2018 04:40:30 +0530 Jagan Teki <[email protected]>…
I do really understand your intention about the real question.
- Any code or generic code will add in U-Boot should be driver-model driven, are you agree this point?
Yes- thanks.
No - we need to have separate discussion.Quoted 5 lines
Depends on what you mean by driver-model driven. Yes, applying the DM sometimes makes sense, but blindly trying to push it everywhere just for the sake of being "DM compliant" is a huge mistake IMO. One example of the thing you suggested which didn't make sense at all: force MTD users to manipulate udevice objects instead of
mtd_infoones.
Quoted 4 lines
(+ Simon)
ie How we proceed when DM is introduced in U-Boot. May be you can ask Simon or Other DM fellow developers if my statement doesn't make sense to you. ie whole reason of spi-nor changes last for year.
I generally prefer to use DM fully. I am not sure what an mtd_info is if it isn't a device.
Quoted 15 lines
Quoted 7 lines
Quoted 6 lines
Any code that related to spi, or spi-flash should be driver-model driven, ie what my AIM as a Maintainer (ie only reason for my spi-nor changes resist for long time to fit).
Quoted 5 lines
You seem to use the term "driver-model" a lot without clearly explaining what you have in mind. The driver-model should be used where it makes sense, but some of your suggestions don't make any sense to me. Like the proposal to add a SPI NOR uclass while we already have an MTD uclass which works just fine for all kind of flash devices.
You better read the thread carefully. read what I'm saying on the thread[1]
Quoted 8 lines
" So, if no driver should be part of spi-nor and all can be handle spi-mem even-though they have controller specific features, yes we can skip
SPI_NOR_UCLASSotherwise we need spi-nor uclass that can be child uclass of MTD"Did it state insisting SPI-NOR uclass, I was clearly giving if condition here.
Regards,
Simon
Vignesh R
maintainerPATCH 3/16 spi: Add non DM version of SPI_MEM
In reply to Boris BrezillonQuoted 76 lines · Boris Brezillon
Quoted 48 lines · On Wed, 12 Dec 2018 22:07:44 +0100 Jagan Teki <[email protected]>…
Quoted 34 lines · On Wed 12 Dec, 2018, 10:02 PM Boris Brezillon <[email protected]…
Quoted 9 lines · On Thu, 13 Dec 2018 02:15:16 +0530 Jagan Teki <[email protected]>…
Quoted 7 lines · Boris Brezillon
Hi Jagan,
Quoted 1 line · On Thu, 13 Dec 2018 01:55:08 +0530 Jagan Teki <[email protected]>…
On Wed, Dec 12, 2018 at 11:08 PM Vignesh R <[email protected]>
Quoted 2 lines · wrote:
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Add non DM version of
SPI_MEMto support easy migration to new SPINOR
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
framework. This can be removed once
DM_SPIconversion iscomplete.
Quoted 12 lines
Quoted 11 lines
Quoted 3 lines
Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?
Looks like we're having the same discussion over and over. Vignesh is dropping
spi_flash.cwhich AFAICT was not depending onDM_SPI, so, if we want to keep everyone happy while getting rid of some legacy code, that's the only solution. DM conversion is a nice goal, but it's kind of orthogonal to what Vignesh is working on. IfDM_SPIconversion happens before the spi-nor stuff is merged (which I doubt) then this patch can simply be dropped.Quoted 3 lines
spi_flash.cis a core code not a specific driver it belongs. spi-mem is new feature driver how come new driver will support legacy non-dm do we have legacy use for that(ie what I'm asking about usecase)Quoted 10 lines
I recommend that you read the spi-mem code carefully. spi-mem is not driver specific, it's a thin layer on top of spi and driver *can* (but are not forced to) provide optimized methods to execute spi-mem operations. When that's not the case, the implementation falls back to regular spi transfers. AFAIK, both DM and non-DM drivers support regular spi transfers, right? So why should we depend on
DM_SPI? And more importantly, if we do that, that means we can't get rid ofspi_flash.csince some users might still have non-DM SPI drivers, which in turn means we keep more legacy code for no good reasons.Quoted 1 line
I understand spi-mem is core file, but new code too.
Sorry, I don't get it.
Quoted 8 lines
Quoted 5 lines
You want non-DM SPI controller drivers to go away, then remove them, instead of blocking other changes using this excuse.
Please understand uboot development flow, legacy driver can be removed if possible once migration expire and NEW drivers or code must be dm driven.
Sorry, but I think you're the one misunderstanding what we are trying to do here. Vignesh changes have simply no impact on the DM SPI conversion you're aiming at. All Vignesh does is provide a dummy wrapper for non-DM drivers, which would probably have been implemented by Miquel if you had not been so insistent on your precious
DM_SPIconversion. That was not really a problem for spi-nand, as we were adding support for a new feature. This is not the case here. SPI NORs are already partially supported by the u-boot spi flash layer, and we need to keep things in a working state for those that were using it and didn't have their SPI controller drivers converted to the DM. This leaves us 2 options:
Quoted 8 lines
1/ keep the
sf_flashcode as is and add a new spi-nor code base 2/ replacespi_flashcode by the spi-nor layer imported from LinuxVignesh chose option #2 which has the benefit of avoiding code duplication. Given the discussion we're having right now, I'm wondering if it wouldn't be easier to go for option #1 in order to avoid those endless discussions...
Boris, thanks for chiming in! This is exactly what I had in mind.
To add, I did start with #1 by simply adding support for 4 byte addressing. But, then released I need spi-mem to communicate this protocol info to SPI drivers, then found Quad Enable detection logic to be incomplete and so on.. Finally released I would end up with code exactly similar to Linux SPI-NOR(with addition of SFDP logic). Therefore switched to #2 ;)
Signature · 2 lines
Regards Vignesh
Miquel Raynal
maintainerPATCH 3/16 spi: Add non DM version of SPI_MEM
Hi Vignesh,
Vignesh R <[email protected]> wrote on Thu, 13 Dec 2018 15:08:32 +0530:
Quoted 86 lines · Boris Brezillon
Quoted 76 lines
Quoted 48 lines · On Wed, 12 Dec 2018 22:07:44 +0100 Jagan Teki <[email protected]>…
Quoted 34 lines · On Wed 12 Dec, 2018, 10:02 PM Boris Brezillon <[email protected]…
Quoted 9 lines · On Thu, 13 Dec 2018 02:15:16 +0530 Jagan Teki <[email protected]>…
Quoted 7 lines · Boris Brezillon
Hi Jagan,
Quoted 1 line · On Thu, 13 Dec 2018 01:55:08 +0530 Jagan Teki <[email protected]>…
On Wed, Dec 12, 2018 at 11:08 PM Vignesh R <[email protected]>
Quoted 2 lines · wrote:
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Add non DM version of
SPI_MEMto support easy migration to new SPINOR
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
framework. This can be removed once
DM_SPIconversion iscomplete.
Quoted 12 lines
Quoted 11 lines
Quoted 3 lines
Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?
Looks like we're having the same discussion over and over. Vignesh is dropping
spi_flash.cwhich AFAICT was not depending onDM_SPI, so, if we want to keep everyone happy while getting rid of some legacy code, that's the only solution. DM conversion is a nice goal, but it's kind of orthogonal to what Vignesh is working on. IfDM_SPIconversion happens before the spi-nor stuff is merged (which I doubt) then this patch can simply be dropped.Quoted 3 lines
spi_flash.cis a core code not a specific driver it belongs. spi-mem is new feature driver how come new driver will support legacy non-dm do we have legacy use for that(ie what I'm asking about usecase)Quoted 10 lines
I recommend that you read the spi-mem code carefully. spi-mem is not driver specific, it's a thin layer on top of spi and driver *can* (but are not forced to) provide optimized methods to execute spi-mem operations. When that's not the case, the implementation falls back to regular spi transfers. AFAIK, both DM and non-DM drivers support regular spi transfers, right? So why should we depend on
DM_SPI? And more importantly, if we do that, that means we can't get rid ofspi_flash.csince some users might still have non-DM SPI drivers, which in turn means we keep more legacy code for no good reasons.Quoted 1 line
I understand spi-mem is core file, but new code too.
Sorry, I don't get it.
Quoted 8 lines
Quoted 5 lines
You want non-DM SPI controller drivers to go away, then remove them, instead of blocking other changes using this excuse.
Please understand uboot development flow, legacy driver can be removed if possible once migration expire and NEW drivers or code must be dm driven.
Sorry, but I think you're the one misunderstanding what we are trying to do here. Vignesh changes have simply no impact on the DM SPI conversion you're aiming at. All Vignesh does is provide a dummy wrapper for non-DM drivers, which would probably have been implemented by Miquel if you had not been so insistent on your precious
DM_SPIconversion. That was not really a problem for spi-nand, as we were adding support for a new feature. This is not the case here. SPI NORs are already partially supported by the u-boot spi flash layer, and we need to keep things in a working state for those that were using it and didn't have their SPI controller drivers converted to the DM. This leaves us 2 options:Quoted 8 lines
1/ keep the
sf_flashcode as is and add a new spi-nor code base 2/ replacespi_flashcode by the spi-nor layer imported from LinuxVignesh chose option #2 which has the benefit of avoiding code duplication. Given the discussion we're having right now, I'm wondering if it wouldn't be easier to go for option #1 in order to avoid those endless discussions...
Quoted 10 lines
Boris, thanks for chiming in! This is exactly what I had in mind.
To add, I did start with #1 by simply adding support for 4 byte addressing. But, then released I need spi-mem to communicate this protocol info to SPI drivers, then found Quad Enable detection logic to be incomplete and so on.. Finally released I would end up with code exactly similar to Linux SPI-NOR(with addition of SFDP logic). Therefore switched to #2 ;)
I also share (strongly) the same point of view: #2 is the best way IMHO.
Thanks,
Miquèl
Vignesh R
maintainerPATCH 3/16 spi: Add non DM version of SPI_MEM
In reply to Jagan TekiQuoted 8 lines · Jagan Teki
Quoted 3 lines · Vignesh R
Add non DM version of
SPI_MEMto support easy migration to new SPI NOR framework. This can be removed onceDM_SPIconversion is complete.Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?
As said by others, AFAICS, DM_SPI migration is not going to be complete anytime soon. There are many boards and configs that don't enable DM_SPI. I propose you add a patch to print _warning during build_ for boards that don't have DM_SPI enabled (like DM_MMC and DM_USB) targeting v2019.07 or v2019.04 as deadline for removal. At the deadline you can remove spi-mem-nodm.c along with all other non DM code in SPI core.
Else, I need to reintroduce code that uses wrappers in sf.c which means two separate code paths/logics in spi-nor-core.c that adds to SPL code size
I don't think it makes sense to block new development for majority of folks who are already migrated to DM_SPI. If we end up completing DM_SPI migration before merging this series, this patch can be dropped w/o any side effects.
Signature · 2 lines
Regards Vignesh
PATCH 3/16 spi: Add non DM version of SPI_MEM
Quoted 13 lines · Vignesh R
Quoted 8 lines · Jagan Teki
Quoted 3 lines · Vignesh R
Add non DM version of
SPI_MEMto support easy migration to new SPI NOR framework. This can be removed onceDM_SPIconversion is complete.Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?
Quoted 6 lines
As said by others, AFAICS,
DM_SPImigration is not going to be complete anytime soon. There are many boards and configs that don't enableDM_SPI. I propose you add a patch to print_warningduringbuild_for boards that don't haveDM_SPIenabled (likeDM_MMCandDM_USB) targeting v2019.07 or v2019.04 as deadline for removal. At the deadline you can removespi-mem-nodm.calong with all other non DM code in SPI core.
I don't understand why DM_SPI migration came to this topic? It's a separate thread/issue.
Do you think any development opensource project will agree to push the code which may remove it in future? ie what my point here.
Vignesh R
maintainerPATCH 3/16 spi: Add non DM version of SPI_MEM
Hi,
Quoted 21 lines · Jagan Teki
Quoted 13 lines · Vignesh R
Quoted 8 lines · Jagan Teki
Quoted 3 lines · Vignesh R
Add non DM version of
SPI_MEMto support easy migration to new SPI NOR framework. This can be removed onceDM_SPIconversion is complete.Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?
Quoted 6 lines
As said by others, AFAICS,
DM_SPImigration is not going to be complete anytime soon. There are many boards and configs that don't enableDM_SPI. I propose you add a patch to print_warningduringbuild_for boards that don't haveDM_SPIenabled (likeDM_MMCandDM_USB) targeting v2019.07 or v2019.04 as deadline for removal. At the deadline you can removespi-mem-nodm.calong with all other non DM code in SPI core.
Quoted 3 lines
I don't understand why
DM_SPImigration came to this topic? It's a separate thread/issue.
I respectfully disagree. If DM_SPI migration was complete then SPI_MEM would be available for use by all subsystem. This patch wouldn't have been needed.
Quoted 3 lines
Do you think any development opensource project will agree to push the code which may remove it in future? ie what my point here.
Do you agree some code needs to be added to spi-nor layer so as not to break non DM_SPI converted boards but make use spi-mem APIs in spi-nor? If yes, then that code is spi-mem-nodm.c. I can rename it as spi_mem_emulation.c or something, but that does not change the fact.
Else, are you proposing to do following in spi-nor-core like in rfc v1[1]?
#if defined(CONFIG_DM_SPI) && defined(CONFIG_SPI_MEM) /* call spi_mem_*_ops() */
#else
/* call SPI ops like spi_xfer() etc
#endif
I am not seeing any solution here. Please have a look at spi-mem.c and spi-nor.c interaction. What do you propose as a solution to use spi-mem APIs but not break non DM_SPI drivers?
[1]https://patchwork.ozlabs.org/patch/1004836/
Signature · 2 lines
Regards Vignesh
PATCH 3/16 spi: Add non DM version of SPI_MEM
Quoted 25 lines · Vignesh R
Hi,
Quoted 21 lines · Jagan Teki
Quoted 19 lines · Vignesh R
Quoted 8 lines · Jagan Teki
Quoted 3 lines · Vignesh R
Add non DM version of
SPI_MEMto support easy migration to new SPI NOR framework. This can be removed onceDM_SPIconversion is complete.Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?
As said by others, AFAICS,
DM_SPImigration is not going to be complete anytime soon. There are many boards and configs that don't enableDM_SPI. I propose you add a patch to print_warningduringbuild_for boards that don't haveDM_SPIenabled (likeDM_MMCandDM_USB) targeting v2019.07 or v2019.04 as deadline for removal. At the deadline you can removespi-mem-nodm.calong with all other non DM code in SPI core.
Quoted 8 lines
Quoted 3 lines
I don't understand why
DM_SPImigration came to this topic? It's a separate thread/issue.I respectfully disagree. If
DM_SPImigration was complete thenSPI_MEMwould be available for use by all subsystem. This patch wouldn't have been needed.
I have given my comment if spi-mem handle only DM.
Okay, lets move your approach of having spi-mem-nondm.c
PATCH 3/16 spi: Add non DM version of SPI_MEM
In reply to Vignesh RQuoted 130 lines · Vignesh R
Add non DM version of
SPI_MEMto support easy migration to new SPI NOR framework. This can be removed onceDM_SPIconversion is complete.Signed-off-by Vignesh R <[email protected]>--- drivers/spi/Kconfig | 4 +- drivers/spi/Makefile | 1 + drivers/spi/spi-mem-nodm.c | 89 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 92 insertions(+), 2 deletions(-) create mode 100644 drivers/spi/spi-mem-nodm.cdrivers/spi/Kconfig +2
-2@@ -16,8 +16,6 @@ config DM_SPI typically use driver-private data instead of extending the spi_slave structure. -if DM_SPI - config SPI_MEM bool "SPI memory extension" help@@ -25,6 +23,8 @@ config SPI_MEM This extension is meant to simplify interaction with SPI memories by providing an high-level interface to send memory-like commands. +if DM_SPI + config ALTERA_SPI bool "Altera SPI driver" helpdrivers/spi/Makefile +1
-0@@ -11,6 +11,7 @@ obj-$(CONFIG_SOFT_SPI) += soft_spi.o obj-$(CONFIG_SPI_MEM) += spi-mem.o else obj-y += spi.o +obj-$(CONFIG_SPI_MEM) += spi-mem-nodm.o obj-$(CONFIG_SOFT_SPI) += soft_spi_legacy.o endifdrivers/spi/spi-mem-nodm.c new file +78
-0@@ -0,0 +1,89 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* +* Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ +*/ + +#include <spi.h> +#include <spi-mem.h> + +int spi_mem_exec_op (struct spi_slave *slave, +const struct spi_mem_op *op) +{ +unsigned int pos =0 ; +const u8 *tx_buf =NULL ; +u8 *rx_buf =NULL ; +u8 *op_buf; +int op_len; +u32 flag; +int ret; +int i; + +if (op->data.nbytes) { +if (op->data.dir ==SPI_MEM_DATA_IN ) + rx_buf = op->data.buf.in; +else + tx_buf = op->data.buf.out; + } + + op_len =sizeof (op->cmd.opcode) + op->addr.nbytes + op->dummy.nbytes; + op_buf =calloc (1 , op_len); + + ret =spi_claim_bus (slave); +if (ret <0 ) +return ret; + + op_buf[pos++] = op->cmd.opcode; + +if (op->addr.nbytes) { +for (i =0 ; i < op->addr.nbytes; i++) + op_buf[pos + i] = op->addr.val >> + (8 * (op->addr.nbytes - i -1 )); + + pos += op->addr.nbytes; + } + +if (op->dummy.nbytes) +memset (op_buf + pos,0xff , op->dummy.nbytes); + +/* 1st transfer: opcode + address + dummy cycles */ + flag =SPI_XFER_BEGIN ; +/* Make sure to set END bit if no tx or rx data messages follow */ +if (!tx_buf && !rx_buf) + flag |=SPI_XFER_END ; + + ret =spi_xfer (slave, op_len *8 , op_buf,NULL , flag); +if (ret) +return ret; + +/* 2nd transfer: rx or tx data path */ +if (tx_buf || rx_buf) { + ret =spi_xfer (slave, op->data.nbytes *8 , tx_buf, + rx_buf,SPI_XFER_END ); +if (ret) +return ret; + } + +spi_release_bus (slave); + +for (i =0 ; i < pos; i++) +debug ("%02x " , op_buf[i]); +debug ("| [%dB %s] " , + tx_buf || rx_buf ? op->data.nbytes :0 , + tx_buf || rx_buf ? (tx_buf ?"out" :"in" ) :"-" ); +for (i =0 ; i < op->data.nbytes; i++) +debug ("%02x " , tx_buf ? tx_buf[i] : rx_buf[i]); +debug ("[ret %d]\n" , ret); + +free (op_buf); +
drivers/spi/spi-mem-nodm.c line 88
Quoted 10 lines
drivers/spi/spi-mem-nodm.c new file +10
-0+if (ret <0 ) +return ret; + +return 0 ; +} + +int spi_mem_adjust_op_size (struct spi_slave *slave, +struct spi_mem_op *op) +{ +return 0 ;
Does it not return data size of SPI mem, or not need for non-dm?
Vignesh R
maintainerPATCH 3/16 spi: Add non DM version of SPI_MEM
Quoted 13 lines · Jagan Teki
Quoted 12 lines · Vignesh R
Add non DM version of
SPI_MEMto support easy migration to new SPI NOR framework. This can be removed onceDM_SPIconversion is complete.Signed-off-by Vignesh R <[email protected]>--- drivers/spi/Kconfig | 4 +- drivers/spi/Makefile | 1 + drivers/spi/spi-mem-nodm.c | 89 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 92 insertions(+), 2 deletions(-) create mode 100644 drivers/spi/spi-mem-nodm.c
[...]
Quoted 7 lines
drivers/spi/spi-mem-nodm.c line 88
Quoted 4 lines
drivers/spi/spi-mem-nodm.c new file +4
-0+int spi_mem_adjust_op_size (struct spi_slave *slave, +struct spi_mem_op *op) +{ +return 0 ;Does it not return data size of SPI mem, or not need for non-dm?
/**
* spi_mem_adjust_op_size() - Adjust the data size of a SPI mem operation to
* match controller limitations
* @slave: the SPI device
* @op: the operation to adjust
*
* Some controllers have FIFO limitations and must split a data transfer
* operation into multiple ones, others require a specific alignment for
* optimized accesses. This function allows SPI mem drivers to split a single
* operation into multiple sub-operations when required.
*
* Return: a negative error code if the controller can't properly adjust @op,
* 0 otherwise. Note that @op->data.nbytes will be updated if @op
* can't be handled in a single step.
*/
I will modify the function to take care of spi->max_write_size and spi->max_read_size in DM and non-DM case (instead of spi-nor-core.c).
Signature · 2 lines
Regards Vignesh
Vignesh R
maintainerPATCH 4/16 sh: bitops: add hweight*() macros
In reply to Vignesh RAdd hweight*() macros required for moving to new SF layer
--- arch/sh/include/asm/bitops.h | 4 ++++ 1 file changed, 4 insertions(+)
arch/sh/include/asm/bitops.h +4 -0
@@ -153,6 +153,10 @@ static inline int ffs (int x) }#define PLATFORM_FFS +#define hweight32 (x) generic_hweight32(x) +#define hweight16 (x) generic_hweight16(x) +#define hweight8 (x) generic_hweight8(x) +#endif /* __KERNEL__ */ #endif /* __ASM_SH_BITOPS_H */
Signature · 1 line
2.19.2
Vignesh R
maintainerPATCH 5/16 mtd: spi: Port SPI NOR framework from Linux
In reply to Vignesh RCurrent U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top. in order to gain 4 byte addressing support, SFDP support and a way to support SPI controllers with MMIO flash interface.
--- drivers/mtd/spi/spi-nor-core.c | 2647 ++++++++++++++++++++++++++++++++ include/linux/mtd/cfi.h | 32 + include/linux/mtd/spi-nor.h | 421 +++++ 3 files changed, 3100 insertions(+) create mode 100644 drivers/mtd/spi/spi-nor-core.c create mode 100644 include/linux/mtd/cfi.h create mode 100644 include/linux/mtd/spi-nor.h
drivers/mtd/spi/spi-nor-core.c new file +2647 -0
@@ -0,0 +1,2647 @@ +// SPDX-License-Identifier: GPL-2.0 +/* +* Based on m25p80.c, by Mike Lavender (mike at steroidmicros.com), with +* influence from lart.c (Abraham Van Der Merwe) and mtd_dataflash.c +* +* Copyright (C) 2005, Intec Automation Inc. +* Copyright (C) 2014, Freescale Semiconductor, Inc. +* +* Synced from Linux v4.19 +*/ + +#include <common.h> +#include <linux/err.h> +#include <linux/errno.h> +#include <linux/log2.h> +#include <linux/math64.h> +#include <linux/sizes.h> + +#include <linux/mtd/mtd.h> +#include <linux/mtd/spi-nor.h> +#include <spi-mem.h> +#include <spi.h> + +/* Define max times to check status register before we give up. */ + +/* +* For everything but full-chip erase; probably could be much smaller, but kept +* around for safety for now +*/ + +#define HZ CONFIG_SYS_HZ + +#define DEFAULT_READY_WAIT_JIFFIES (40UL * HZ) + +#define SPI_NOR_MAX_ID_LEN 6 +#define SPI_NOR_MAX_ADDR_WIDTH 4 + +struct flash_info { +char *name; + +/* +* This array stores the ID bytes. +* The first three bytes are the JEDIC ID. +* JEDEC ID zero means "no ID" (mostly older chips). +*/ +u8 id[SPI_NOR_MAX_ID_LEN ]; +u8 id_len; + +/* The size listed here is what works with SPINOR_OP_SE, which isn't +* necessarily called a "sector" by the vendor. +*/ +unsigned int sector_size; +u16 n_sectors; + +u16 page_size; +u16 addr_width; + +u16 flags; +#define SECT_4K BIT(0)/* SPINOR_OP_BE_4K works uniformly */ +#define SPI_NOR_NO_ERASE BIT(1)/* No erase command needed */ +#define SST_WRITE BIT(2)/* use SST byte programming */ +#define SPI_NOR_NO_FR BIT(3)/* Can't do fastread */ +#define SECT_4K_PMC BIT(4)/* SPINOR_OP_BE_4K_PMC works uniformly */ +#define SPI_NOR_DUAL_READ BIT(5)/* Flash supports Dual Read */ +#define SPI_NOR_QUAD_READ BIT(6)/* Flash supports Quad Read */ +#define USE_FSR BIT(7)/* use flag status register */ +#define SPI_NOR_HAS_LOCK BIT(8)/* Flash supports lock/unlock via SR */ +#define SPI_NOR_HAS_TB BIT(9)/* +* Flash SR has Top/Bottom (TB) protect +* bit. Must be used with +* SPI_NOR_HAS_LOCK. +*/ +#define SPI_S3AN BIT(10)/* +* Xilinx Spartan 3AN In-System Flash +* (MFR cannot be used for probing +* because it has the same value as +* ATMEL flashes) +*/ +#define SPI_NOR_4B_OPCODES BIT(11)/* +* Use dedicated 4byte address op codes +* to support memory size above 128Mib. +*/ +#define NO_CHIP_ERASE BIT(12)/* Chip does not support chip erase */ +#define SPI_NOR_SKIP_SFDP BIT(13)/* Skip parsing of SFDP tables */ +#define USE_CLSR BIT(14)/* use CLSR command */ + +int (*quad_enable)(struct spi_nor *nor); +}; + +#define JEDEC_MFR (info) ((info)->id[0]) + +static int spi_nor_read_write_reg (struct spi_nor *nor,struct spi_mem_op + *op,void *buf) +{ +if (op->data.dir ==SPI_MEM_DATA_IN ) + op->data.buf.in = buf; +else + op->data.buf.out = buf; +return spi_mem_exec_op (nor->spi, op); +} + +static int spi_nor_read_reg (struct spi_nor *nor,u8 code,u8 *val,int len) +{ +struct spi_mem_op op =SPI_MEM_OP (SPI_MEM_OP_CMD (code,1 ), +SPI_MEM_OP_NO_ADDR , +SPI_MEM_OP_NO_DUMMY , +SPI_MEM_OP_DATA_IN (len,NULL ,1 )); +int ret; + + ret =spi_nor_read_write_reg (nor, &op, val); +if (ret <0 ) +dev_dbg (&flash->spimem->spi->dev,"error %d reading %x\n" , ret, + code); + +return ret; +} + +static int spi_nor_write_reg (struct spi_nor *nor,u8 opcode,u8 *buf,int len) +{ +struct spi_mem_op op =SPI_MEM_OP (SPI_MEM_OP_CMD (opcode,1 ), +SPI_MEM_OP_NO_ADDR , +SPI_MEM_OP_NO_DUMMY , +SPI_MEM_OP_DATA_OUT (len,NULL ,1 )); + +return spi_nor_read_write_reg (nor, &op, buf); +} + +static ssize_t spi_nor_read_data (struct spi_nor *nor,loff_t from,size_t len, +u_char *buf) +{ +struct spi_mem_op op = +SPI_MEM_OP (SPI_MEM_OP_CMD (nor->read_opcode,1 ), +SPI_MEM_OP_ADDR (nor->addr_width, from,1 ), +SPI_MEM_OP_DUMMY (nor->read_dummy,1 ), +SPI_MEM_OP_DATA_IN (len, buf,1 )); +size_t remaining = len; +int ret; + +/* get transfer protocols. */ + op.cmd.buswidth =spi_nor_get_protocol_inst_nbits (nor->read_proto); + op.addr.buswidth =spi_nor_get_protocol_addr_nbits (nor->read_proto); + op.dummy.buswidth = op.addr.buswidth; + op.data.buswidth =spi_nor_get_protocol_data_nbits (nor->read_proto); + +/* convert the dummy cycles to the number of bytes */ + op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) /8 ; + +while (remaining) { + op.data.nbytes = remaining <UINT_MAX ? remaining :UINT_MAX ; + ret =spi_mem_adjust_op_size (nor->spi, &op); +if (ret) +return ret; + + ret =spi_mem_exec_op (nor->spi, &op); +if (ret) +return ret; + + op.addr.val += op.data.nbytes; + remaining -= op.data.nbytes; + op.data.buf.in += op.data.nbytes; + } + +return len; +} + +static ssize_t spi_nor_write_data (struct spi_nor *nor,loff_t to,size_t len, +const u_char *buf) +{ +struct spi_mem_op op = +SPI_MEM_OP (SPI_MEM_OP_CMD (nor->program_opcode,1 ), +SPI_MEM_OP_ADDR (nor->addr_width, to,1 ), +SPI_MEM_OP_NO_DUMMY , +SPI_MEM_OP_DATA_OUT (len, buf,1 )); +size_t remaining = len; +int ret; + +/* get transfer protocols. */ + op.cmd.buswidth =spi_nor_get_protocol_inst_nbits (nor->write_proto); + op.addr.buswidth =spi_nor_get_protocol_addr_nbits (nor->write_proto); + op.data.buswidth =spi_nor_get_protocol_data_nbits (nor->write_proto); + +if (nor->program_opcode ==SPINOR_OP_AAI_WP && nor->sst_write_second) + op.addr.nbytes =0 ; + +while (remaining) { + op.data.nbytes = remaining <UINT_MAX ? remaining :UINT_MAX ; + ret =spi_mem_adjust_op_size (nor->spi, &op); +if (ret) +return ret; + + ret =spi_mem_exec_op (nor->spi, &op); +if (ret) +return ret; + + op.addr.val += op.data.nbytes; + remaining -= op.data.nbytes; + op.data.buf.out += op.data.nbytes; + } + +return len; +} + +/* +* Read the status register, returning its value in the location +* Return the status register value. +* Returns negative if error occurred. +*/ +static int read_sr (struct spi_nor *nor) +{ +int ret; +u8 val; + + ret = nor->read_reg (nor,SPINOR_OP_RDSR , &val,1 ); +if (ret <0 ) { +pr_debug ("error %d reading SR\n" , (int )ret); +return ret; + } + +return val; +} + +/* +* Read the flag status register, returning its value in the location +* Return the status register value. +* Returns negative if error occurred. +*/ +static int read_fsr (struct spi_nor *nor) +{ +int ret; +u8 val; + + ret = nor->read_reg (nor,SPINOR_OP_RDFSR , &val,1 ); +if (ret <0 ) { +pr_debug ("error %d reading FSR\n" , ret); +return ret; + } + +return val; +} + +/* +* Read configuration register, returning its value in the +* location. Return the configuration register value. +* Returns negative if error occurred. +*/ +#if defined(CONFIG_SPI_FLASH_SPANSION ) || defined(CONFIG_SPI_FLASH_WINBOND ) +static int read_cr (struct spi_nor *nor) +{ +int ret; +u8 val; + + ret = nor->read_reg (nor,SPINOR_OP_RDCR , &val,1 ); +if (ret <0 ) { +dev_dbg (nor->dev,"error %d reading CR\n" , ret); +return ret; + } + +return val; +} +#endif + +/* +* Write status register 1 byte +* Returns negative if error occurred. +*/ +static inline int write_sr (struct spi_nor *nor,u8 val) +{ + nor->cmd_buf[0 ] = val; +return nor->write_reg (nor,SPINOR_OP_WRSR , nor->cmd_buf,1 ); +} + +/* +* Set write enable latch with Write Enable command. +* Returns negative if error occurred. +*/ +static inline int write_enable (struct spi_nor *nor) +{ +return nor->write_reg (nor,SPINOR_OP_WREN ,NULL ,0 ); +} + +/* +* Send write disable instruction to the chip. +*/ +static inline int write_disable (struct spi_nor *nor) +{ +return nor->write_reg (nor,SPINOR_OP_WRDI ,NULL ,0 ); +} + +static inline struct spi_nor *mtd_to_spi_nor (struct mtd_info *mtd) +{ +return mtd->priv; +} + +static u8 spi_nor_convert_opcode (u8 opcode,const u8 table[][2 ],size_t size) +{ +size_t i; + +for (i =0 ; i < size; i++) +if (table[i][0 ] == opcode) +return table[i][1 ]; + +/* No conversion found, keep input op code. */ +return opcode; +} + +static inline u8 spi_nor_convert_3to4_read (u8 opcode) +{ +static const u8 spi_nor_3to4_read[][2 ] = { + {SPINOR_OP_READ ,SPINOR_OP_READ_4B }, + {SPINOR_OP_READ_FAST ,SPINOR_OP_READ_FAST_4B }, + {SPINOR_OP_READ_1_1_2 ,SPINOR_OP_READ_1_1_2_4B }, + {SPINOR_OP_READ_1_2_2 ,SPINOR_OP_READ_1_2_2_4B }, + {SPINOR_OP_READ_1_1_4 ,SPINOR_OP_READ_1_1_4_4B }, + {SPINOR_OP_READ_1_4_4 ,SPINOR_OP_READ_1_4_4_4B }, + }; + +return spi_nor_convert_opcode (opcode, spi_nor_3to4_read, +ARRAY_SIZE (spi_nor_3to4_read)); +} + +static inline u8 spi_nor_convert_3to4_program (u8 opcode) +{ +static const u8 spi_nor_3to4_program[][2 ] = { + {SPINOR_OP_PP ,SPINOR_OP_PP_4B }, + {SPINOR_OP_PP_1_1_4 ,SPINOR_OP_PP_1_1_4_4B }, + {SPINOR_OP_PP_1_4_4 ,SPINOR_OP_PP_1_4_4_4B }, + }; + +return spi_nor_convert_opcode (opcode, spi_nor_3to4_program, +ARRAY_SIZE (spi_nor_3to4_program)); +} + +static inline u8 spi_nor_convert_3to4_erase (u8 opcode) +{ +static const u8 spi_nor_3to4_erase[][2 ] = { + {SPINOR_OP_BE_4K ,SPINOR_OP_BE_4K_4B }, + {SPINOR_OP_BE_32K ,SPINOR_OP_BE_32K_4B }, + {SPINOR_OP_SE ,SPINOR_OP_SE_4B }, + }; + +return spi_nor_convert_opcode (opcode, spi_nor_3to4_erase, +ARRAY_SIZE (spi_nor_3to4_erase)); +} + +static void spi_nor_set_4byte_opcodes (struct spi_nor *nor, +const struct flash_info *info) +{ +/* Do some manufacturer fixups first */ +switch (JEDEC_MFR (info)) { +case SNOR_MFR_SPANSION : +/* No small sector erase for 4-byte command set */ + nor->erase_opcode =SPINOR_OP_SE ; + nor->mtd.erasesize = info->sector_size; +break ; + +default : +break ; + } + + nor->read_opcode =spi_nor_convert_3to4_read (nor->read_opcode); + nor->program_opcode =spi_nor_convert_3to4_program (nor->program_opcode); + nor->erase_opcode =spi_nor_convert_3to4_erase (nor->erase_opcode); +} + +/* Enable/disable 4-byte addressing mode. */ +static inline int set_4byte (struct spi_nor *nor,const struct flash_info *info, +int enable) +{ +int status; +bool need_wren = false; +u8 cmd; + +switch (JEDEC_MFR (info)) { +case SNOR_MFR_ST : +case SNOR_MFR_MICRON : +/* Some Micron need WREN command; all will accept it */ + need_wren = true; +case SNOR_MFR_MACRONIX : +case SNOR_MFR_WINBOND : +if (need_wren) +write_enable (nor); + + cmd = enable ?SPINOR_OP_EN4B :SPINOR_OP_EX4B ; + status = nor->write_reg (nor, cmd,NULL ,0 ); +if (need_wren) +write_disable (nor); + +if (!status && !enable && +JEDEC_MFR (info) ==SNOR_MFR_WINBOND ) { +/* +* On Winbond W25Q256FV, leaving 4byte mode causes +* the Extended Address Register to be set to 1, so all +* 3-byte-address reads come from the second 16M. +* We must clear the register to enable normal behavior. +*/ +write_enable (nor); + nor->cmd_buf[0 ] =0 ; + nor->write_reg (nor,SPINOR_OP_WREAR , nor->cmd_buf,1 ); +write_disable (nor); + } + +return status; +default : +/* Spansion style */ + nor->cmd_buf[0 ] = enable <<7 ; +return nor->write_reg (nor,SPINOR_OP_BRWR , nor->cmd_buf,1 ); + } +} + +static int spi_nor_sr_ready (struct spi_nor *nor) +{ +int sr =read_sr (nor); + +if (sr <0 ) +return sr; + +#ifndef CONFIG_SPL_BUILD +if (nor->flags &SNOR_F_USE_CLSR && sr & (SR_E_ERR |SR_P_ERR )) { +if (sr &SR_E_ERR ) +dev_dbg (nor->dev,"Erase Error occurred\n" ); +else +dev_dbg (nor->dev,"Programming Error occurred\n" ); + + nor->write_reg (nor,SPINOR_OP_CLSR ,NULL ,0 ); +return -EIO ; + } +#endif + +return !(sr &SR_WIP ); +} + +static int spi_nor_fsr_ready (struct spi_nor *nor) +{ +int fsr =read_fsr (nor); + +if (fsr <0 ) +return fsr; +#ifndef CONFIG_SPL_BUILD +if (fsr & (FSR_E_ERR |FSR_P_ERR )) { +if (fsr &FSR_E_ERR ) +dev_dbg (nor->dev,"Erase operation failed.\n" ); +else +dev_dbg (nor->dev,"Program operation failed.\n" ); + +if (fsr &FSR_PT_ERR ) +dev_dbg (nor->dev, +"Attempted to modify a protected sector.\n" ); + + nor->write_reg (nor,SPINOR_OP_CLFSR ,NULL ,0 ); +return -EIO ; + } +#endif +return fsr &FSR_READY ; +} + +static int spi_nor_ready (struct spi_nor *nor) +{ +int sr, fsr; + + sr =spi_nor_sr_ready (nor); +if (sr <0 ) +return sr; + fsr = nor->flags &SNOR_F_USE_FSR ?spi_nor_fsr_ready (nor) :1 ; +if (fsr <0 ) +return fsr; +return sr && fsr; +} + +/* +* Service routine to read status register until ready, or timeout occurs. +* Returns non-zero if error. +*/ +static int spi_nor_wait_till_ready_with_timeout (struct spi_nor *nor, +unsigned long timeout) +{ +unsigned long timebase; +int ret; + + timebase =get_timer (0 ); + +while (get_timer (timebase) < timeout) { + ret =spi_nor_ready (nor); +if (ret <0 ) +return ret; +if (ret) +return 0 ; + } + +dev_err (nor->dev,"flash operation timed out\n" ); + +return -ETIMEDOUT ; +} + +static int spi_nor_wait_till_ready (struct spi_nor *nor) +{ +return spi_nor_wait_till_ready_with_timeout (nor, +DEFAULT_READY_WAIT_JIFFIES ); +} + +/* +* Initiate the erasure of a single sector +*/ +static int spi_nor_erase_sector (struct spi_nor *nor,u32 addr) +{ +u8 buf[SPI_NOR_MAX_ADDR_WIDTH ]; +int i; + +if (nor->erase) +return nor->erase (nor, addr); + +/* +* Default implementation, if driver doesn't have a specialized HW +* control +*/ +for (i = nor->addr_width -1 ; i >=0 ; i--) { + buf[i] = addr &0xff ; + addr >>=8 ; + } + +return nor->write_reg (nor, nor->erase_opcode, buf, nor->addr_width); +} + +/* +* Erase an address range on the nor chip. The address range may extend +* one or more erase sectors. Return an error is there is a problem erasing. +*/ +static int spi_nor_erase (struct mtd_info *mtd,struct erase_info *instr) +{ +struct spi_nor *nor =mtd_to_spi_nor (mtd); +u32 addr, len, rem; +int ret; + +dev_dbg (nor->dev,"at 0x%llx, len %lld\n" , (long long )instr->addr, + (long long )instr->len); + +div_u64_rem (instr->len, mtd->erasesize, &rem); +if (rem) +return -EINVAL ; + + addr = instr->addr; + len = instr->len; + +while (len) { +write_enable (nor); + + ret =spi_nor_erase_sector (nor, addr); +if (ret) + goto erase_err; + + addr += mtd->erasesize; + len -= mtd->erasesize; + + ret =spi_nor_wait_till_ready (nor); +if (ret) + goto erase_err; + } + +write_disable (nor); + +erase_err: +return ret; +} + +#if defined(CONFIG_SPI_FLASH_STMICRO ) || defined(CONFIG_SPI_FLASH_SST ) +/* Write status register and ensure bits in mask match written values */ +static int write_sr_and_check (struct spi_nor *nor,u8 status_new,u8 mask) +{ +int ret; + +write_enable (nor); + ret =write_sr (nor, status_new); +if (ret) +return ret; + + ret =spi_nor_wait_till_ready (nor); +if (ret) +return ret; + + ret =read_sr (nor); +if (ret <0 ) +return ret; + +return ((ret & mask) != (status_new & mask)) ? -EIO :0 ; +} + +static void stm_get_locked_range (struct spi_nor *nor,u8 sr,loff_t *ofs, +uint64_t *len) +{ +struct mtd_info *mtd = &nor->mtd; +u8 mask =SR_BP2 |SR_BP1 |SR_BP0 ; +int shift =ffs (mask) -1 ; +int pow; + +if (!(sr & mask)) { +/* No protection */ + *ofs =0 ; + *len =0 ; + }else { + pow = ((sr & mask) ^ mask) >> shift; + *len = mtd->size >> pow; +if (nor->flags &SNOR_F_HAS_SR_TB && sr &SR_TB ) + *ofs =0 ; +else + *ofs = mtd->size - *len; + } +} + +/* +* Return 1 if the entire region is locked (if @locked is true) or unlocked (if +* @locked is false); 0 otherwise +*/ +static int stm_check_lock_status_sr (struct spi_nor *nor,loff_t ofs,u64 len, +u8 sr,bool locked) +{ +loff_t lock_offs; +uint64_t lock_len; + +if (!len) +return 1 ; + +stm_get_locked_range (nor, sr, &lock_offs, &lock_len); + +if (locked) +/* Requested range is a sub-range of locked range */ +return (ofs + len <= lock_offs + lock_len) && (ofs >= lock_offs); +else +/* Requested range does not overlap with locked range */ +return (ofs >= lock_offs + lock_len) || (ofs + len <= lock_offs); +} + +static int stm_is_locked_sr (struct spi_nor *nor,loff_t ofs,uint64_t len, +u8 sr) +{ +return stm_check_lock_status_sr (nor, ofs, len, sr, true); +} + +static int stm_is_unlocked_sr (struct spi_nor *nor,loff_t ofs,uint64_t len, +u8 sr) +{ +return stm_check_lock_status_sr (nor, ofs, len, sr, false); +} + +/* +* Lock a region of the flash. Compatible with ST Micro and similar flash. +* Supports the block protection bits BP{0,1,2} in the status register +* (SR). Does not support these features found in newer SR bitfields: +* - SEC: sector/block protect - only handle SEC=0 (block protect) +* - CMP: complement protect - only support CMP=0 (range is not complemented) +* +* Support for the following is provided conditionally for some flash: +* - TB: top/bottom protect +* +* Sample table portion for 8MB flash (Winbond w25q64fw): +* +* SEC | TB | BP2 | BP1 | BP0 | Prot Length | Protected Portion +* -------------------------------------------------------------------------- +* X | X | 0 | 0 | 0 | NONE | NONE +* 0 | 0 | 0 | 0 | 1 | 128 KB | Upper 1/64 +* 0 | 0 | 0 | 1 | 0 | 256 KB | Upper 1/32 +* 0 | 0 | 0 | 1 | 1 | 512 KB | Upper 1/16 +* 0 | 0 | 1 | 0 | 0 | 1 MB | Upper 1/8 +* 0 | 0 | 1 | 0 | 1 | 2 MB | Upper 1/4 +* 0 | 0 | 1 | 1 | 0 | 4 MB | Upper 1/2 +* X | X | 1 | 1 | 1 | 8 MB | ALL +* ------|-------|-------|-------|-------|---------------|------------------- +* 0 | 1 | 0 | 0 | 1 | 128 KB | Lower 1/64 +* 0 | 1 | 0 | 1 | 0 | 256 KB | Lower 1/32 +* 0 | 1 | 0 | 1 | 1 | 512 KB | Lower 1/16 +* 0 | 1 | 1 | 0 | 0 | 1 MB | Lower 1/8 +* 0 | 1 | 1 | 0 | 1 | 2 MB | Lower 1/4 +* 0 | 1 | 1 | 1 | 0 | 4 MB | Lower 1/2 +* +* Returns negative on errors, 0 on success. +*/ +static int stm_lock (struct spi_nor *nor,loff_t ofs,uint64_t len) +{ +struct mtd_info *mtd = &nor->mtd; +int status_old, status_new; +u8 mask =SR_BP2 |SR_BP1 |SR_BP0 ; +u8 shift =ffs (mask) -1 , pow, val; +loff_t lock_len; +bool can_be_top = true, can_be_bottom = nor->flags &SNOR_F_HAS_SR_TB ; +bool use_top; + + status_old =read_sr (nor); +if (status_old <0 ) +return status_old; + +/* If nothing in our range is unlocked, we don't need to do anything */ +if (stm_is_locked_sr (nor, ofs, len, status_old)) +return 0 ; + +/* If anything below us is unlocked, we can't use 'bottom' protection */ +if (!stm_is_locked_sr (nor,0 , ofs, status_old)) + can_be_bottom = false; + +/* If anything above us is unlocked, we can't use 'top' protection */ +if (!stm_is_locked_sr (nor, ofs + len, mtd->size - (ofs + len), + status_old)) + can_be_top = false; + +if (!can_be_bottom && !can_be_top) +return -EINVAL ; + +/* Prefer top, if both are valid */ + use_top = can_be_top; + +/* lock_len: length of region that should end up locked */ +if (use_top) + lock_len = mtd->size - ofs; +else + lock_len = ofs + len; + +/* +* Need smallest pow such that: +* +* 1 / (2^pow) <= (len / size) +* +* so (assuming power-of-2 size) we do: +* +* pow = ceil(log2(size / len)) = log2(size) - floor(log2(len)) +*/ + pow =ilog2 (mtd->size) -ilog2 (lock_len); + val = mask - (pow << shift); +if (val & ~mask) +return -EINVAL ; +/* Don't "lock" with no region! */ +if (!(val & mask)) +return -EINVAL ; + + status_new = (status_old & ~mask & ~SR_TB ) | val; + +/* Disallow further writes if WP pin is asserted */ + status_new |=SR_SRWD ; + +if (!use_top) + status_new |=SR_TB ; + +/* Don't bother if they're the same */ +if (status_new == status_old) +return 0 ; + +/* Only modify protection if it will not unlock other areas */ +if ((status_new & mask) < (status_old & mask)) +return -EINVAL ; + +return write_sr_and_check (nor, status_new, mask); +} + +/* +* Unlock a region of the flash. See stm_lock() for more info +* +* Returns negative on errors, 0 on success. +*/ +static int stm_unlock (struct spi_nor *nor,loff_t ofs,uint64_t len) +{ +struct mtd_info *mtd = &nor->mtd; +int status_old, status_new; +u8 mask =SR_BP2 |SR_BP1 |SR_BP0 ; +u8 shift =ffs (mask) -1 , pow, val; +loff_t lock_len; +bool can_be_top = true, can_be_bottom = nor->flags &SNOR_F_HAS_SR_TB ; +bool use_top; + + status_old =read_sr (nor); +if (status_old <0 ) +return status_old; + +/* If nothing in our range is locked, we don't need to do anything */ +if (stm_is_unlocked_sr (nor, ofs, len, status_old)) +return 0 ; + +/* If anything below us is locked, we can't use 'top' protection */ +if (!stm_is_unlocked_sr (nor,0 , ofs, status_old)) + can_be_top = false; + +/* If anything above us is locked, we can't use 'bottom' protection */ +if (!stm_is_unlocked_sr (nor, ofs + len, mtd->size - (ofs + len), + status_old)) + can_be_bottom = false; + +if (!can_be_bottom && !can_be_top) +return -EINVAL ; + +/* Prefer top, if both are valid */ + use_top = can_be_top; + +/* lock_len: length of region that should remain locked */ +if (use_top) + lock_len = mtd->size - (ofs + len); +else + lock_len = ofs; + +/* +* Need largest pow such that: +* +* 1 / (2^pow) >= (len / size) +* +* so (assuming power-of-2 size) we do: +* +* pow = floor(log2(size / len)) = log2(size) - ceil(log2(len)) +*/ + pow =ilog2 (mtd->size) -order_base_2 (lock_len); +if (lock_len ==0 ) { + val =0 ;/* fully unlocked */ + }else { + val = mask - (pow << shift); +/* Some power-of-two sizes are not supported */ +if (val & ~mask) +return -EINVAL ; + } + + status_new = (status_old & ~mask & ~SR_TB ) | val; + +/* Don't protect status register if we're fully unlocked */ +if (lock_len ==0 ) + status_new &= ~SR_SRWD ; + +if (!use_top) + status_new |=SR_TB ; + +/* Don't bother if they're the same */ +if (status_new == status_old) +return 0 ; + +/* Only modify protection if it will not lock other areas */ +if ((status_new & mask) > (status_old & mask)) +return -EINVAL ; + +return write_sr_and_check (nor, status_new, mask); +} + +/* +* Check if a region of the flash is (completely) locked. See stm_lock() for +* more info. +* +* Returns 1 if entire region is locked, 0 if any portion is unlocked, and +* negative on errors. +*/ +static int stm_is_locked (struct spi_nor *nor,loff_t ofs,uint64_t len) +{ +int status; + + status =read_sr (nor); +if (status <0 ) +return status; + +return stm_is_locked_sr (nor, ofs, len, status); +} +#endif /* CONFIG_SPI_FLASH_STMICRO */ + +static int spi_nor_lock (struct mtd_info *mtd,loff_t ofs,uint64_t len) +{ +struct spi_nor *nor =mtd_to_spi_nor (mtd); +int ret; + + ret = nor->flash_lock (nor, ofs, len); + +return ret; +} + +static int spi_nor_unlock (struct mtd_info *mtd,loff_t ofs,uint64_t len) +{ +struct spi_nor *nor =mtd_to_spi_nor (mtd); +int ret; + + ret = nor->flash_unlock (nor, ofs, len); + +return ret; +} + +static int spi_nor_is_locked (struct mtd_info *mtd,loff_t ofs,uint64_t len) +{ +struct spi_nor *nor =mtd_to_spi_nor (mtd); +int ret; + + ret = nor->flash_is_locked (nor, ofs, len); + +return ret; +} + +/* Used when the "_ext_id" is two bytes at most */ +#define INFO (_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \ + .id = { \ + ((_jedec_id) >> 16) & 0xff, \ + ((_jedec_id) >> 8) & 0xff, \ + (_jedec_id) & 0xff, \ + ((_ext_id) >> 8) & 0xff, \ + (_ext_id) & 0xff, \ + }, \ + .id_len = (!(_jedec_id) ? 0 : (3 + ((_ext_id) ? 2 : 0))), \ + .sector_size = (_sector_size), \ + .n_sectors = (_n_sectors), \ + .page_size = 256, \ + .flags = (_flags), + +#define INFO6 (_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \ + .id = { \ + ((_jedec_id) >> 16) & 0xff, \ + ((_jedec_id) >> 8) & 0xff, \ + (_jedec_id) & 0xff, \ + ((_ext_id) >> 16) & 0xff, \ + ((_ext_id) >> 8) & 0xff, \ + (_ext_id) & 0xff, \ + }, \ + .id_len = 6, \ + .sector_size = (_sector_size), \ + .n_sectors = (_n_sectors), \ + .page_size = 256, \ + .flags = (_flags), + +/* NOTE: double check command sets and memory organization when you add +* more nor chips. This current list focusses on newer chips, which +* have been converging on command sets which including JEDEC ID. +* +* All newly added entries should describe *hardware* and should use SECT_4K +* (or SECT_4K_PMC) if hardware supports erasing 4 KiB sectors. For usage +* scenarios excluding small sectors there is config option that can be +* disabled: CONFIG_MTD_SPI_NOR_USE_4K_SECTORS. +* For historical (and compatibility) reasons (before we got above config) some +* old entries may be missing 4K flag. +*/ +const struct flash_info spi_nor_ids[] = { +#ifdef CONFIG_SPI_FLASH_ATMEL /* ATMEL */ +/* Atmel -- some are (confusingly) marketed as "DataFlash" */ + {"at26df321" ,INFO (0x1f4700 ,0 ,64 *1024 ,64 ,SECT_4K ) }, + {"at25df321a" ,INFO (0x1f4701 ,0 ,64 *1024 ,64 ,SECT_4K ) }, + + {"at45db011d" ,INFO (0x1f2200 ,0 ,64 *1024 ,4 ,SECT_4K ) }, + {"at45db021d" ,INFO (0x1f2300 ,0 ,64 *1024 ,8 ,SECT_4K ) }, + {"at45db041d" ,INFO (0x1f2400 ,0 ,64 *1024 ,8 ,SECT_4K ) }, + {"at45db081d" ,INFO (0x1f2500 ,0 ,64 *1024 ,16 ,SECT_4K ) }, + {"at45db161d" ,INFO (0x1f2600 ,0 ,64 *1024 ,32 ,SECT_4K ) }, + {"at45db321d" ,INFO (0x1f2700 ,0 ,64 *1024 ,64 ,SECT_4K ) }, + {"at45db641d" ,INFO (0x1f2800 ,0 ,64 *1024 ,128 ,SECT_4K ) }, + {"at26df081a" ,INFO (0x1f4501 ,0 ,64 *1024 ,16 ,SECT_4K ) }, +#endif +#ifdef CONFIG_SPI_FLASH_EON /* EON */ +/* EON -- en25xxx */ + {"en25q32b" ,INFO (0x1c3016 ,0 ,64 *1024 ,64 ,0 ) }, + {"en25q64" ,INFO (0x1c3017 ,0 ,64 *1024 ,128 ,SECT_4K ) }, + {"en25qh128" ,INFO (0x1c7018 ,0 ,64 *1024 ,256 ,0 ) }, + {"en25s64" ,INFO (0x1c3817 ,0 ,64 *1024 ,128 ,SECT_4K ) }, +#endif +#ifdef CONFIG_SPI_FLASH_GIGADEVICE /* GIGADEVICE */ +/* GigaDevice */ + { +"gd25q16" ,INFO (0xc84015 ,0 ,64 *1024 ,32 , +SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ | +SPI_NOR_HAS_LOCK |SPI_NOR_HAS_TB ) + }, + { +"gd25q32" ,INFO (0xc84016 ,0 ,64 *1024 ,64 , +SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ | +SPI_NOR_HAS_LOCK |SPI_NOR_HAS_TB ) + }, + { +"gd25lq32" ,INFO (0xc86016 ,0 ,64 *1024 ,64 , +SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ | +SPI_NOR_HAS_LOCK |SPI_NOR_HAS_TB ) + }, + { +"gd25q64" ,INFO (0xc84017 ,0 ,64 *1024 ,128 , +SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ | +SPI_NOR_HAS_LOCK |SPI_NOR_HAS_TB ) + }, +#endif +#ifdef CONFIG_SPI_FLASH_ISSI /* ISSI */ +/* ISSI */ + {"is25lq040b" ,INFO (0x9d4013 ,0 ,64 *1024 ,8 , +SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ ) }, + {"is25lp032" ,INFO (0x9d6016 ,0 ,64 *1024 ,64 ,0 ) }, + {"is25lp064" ,INFO (0x9d6017 ,0 ,64 *1024 ,128 ,0 ) }, + {"is25lp128" ,INFO (0x9d6018 ,0 ,64 *1024 ,256 , +SECT_4K |SPI_NOR_DUAL_READ ) }, + {"is25lp256" ,INFO (0x9d6019 ,0 ,64 *1024 ,512 , +SECT_4K |SPI_NOR_DUAL_READ ) }, + {"is25wp032" ,INFO (0x9d7016 ,0 ,64 *1024 ,64 , +SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ ) }, + {"is25wp064" ,INFO (0x9d7017 ,0 ,64 *1024 ,128 , +SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ ) }, + {"is25wp128" ,INFO (0x9d7018 ,0 ,64 *1024 ,256 , +SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ ) }, +#endif +#ifdef CONFIG_SPI_FLASH_MACRONIX /* MACRONIX */ +/* Macronix */ + {"mx25l2005a" ,INFO (0xc22012 ,0 ,64 *1024 ,4 ,SECT_4K ) }, + {"mx25l4005a" ,INFO (0xc22013 ,0 ,64 *1024 ,8 ,SECT_4K ) }, + {"mx25l8005" ,INFO (0xc22014 ,0 ,64 *1024 ,16 ,0 ) }, + {"mx25l1606e" ,INFO (0xc22015 ,0 ,64 *1024 ,32 ,SECT_4K ) }, + {"mx25l3205d" ,INFO (0xc22016 ,0 ,64 *1024 ,64 ,SECT_4K ) }, + {"mx25l6405d" ,INFO (0xc22017 ,0 ,64 *1024 ,128 ,SECT_4K ) }, + {"mx25u2033e" ,INFO (0xc22532 ,0 ,64 *1024 ,4 ,SECT_4K ) }, + {"mx25u1635e" ,INFO (0xc22535 ,0 ,64 *1024 ,32 ,SECT_4K ) }, + {"mx25u6435f" ,INFO (0xc22537 ,0 ,64 *1024 ,128 ,SECT_4K ) }, + {"mx25l12805d" ,INFO (0xc22018 ,0 ,64 *1024 ,256 ,0 ) }, + {"mx25l12855e" ,INFO (0xc22618 ,0 ,64 *1024 ,256 ,0 ) }, + {"mx25l25635e" ,INFO (0xc22019 ,0 ,64 *1024 ,512 ,SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ ) }, + {"mx25u25635f" ,INFO (0xc22539 ,0 ,64 *1024 ,512 ,SECT_4K |SPI_NOR_4B_OPCODES ) }, + {"mx25l25655e" ,INFO (0xc22619 ,0 ,64 *1024 ,512 ,0 ) }, + {"mx66l51235l" ,INFO (0xc2201a ,0 ,64 *1024 ,1024 ,SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ |SPI_NOR_4B_OPCODES ) }, + {"mx66u51235f" ,INFO (0xc2253a ,0 ,64 *1024 ,1024 ,SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ |SPI_NOR_4B_OPCODES ) }, + {"mx66l1g45g" ,INFO (0xc2201b ,0 ,64 *1024 ,2048 ,SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ ) }, + {"mx25l1633e" ,INFO (0xc22415 ,0 ,64 *1024 ,32 ,SPI_NOR_QUAD_READ |SPI_NOR_4B_OPCODES |SECT_4K ) }, +#endif + +#ifdef CONFIG_SPI_FLASH_STMICRO /* STMICRO */ +/* Micron */ + {"n25q016a" ,INFO (0x20bb15 ,0 ,64 *1024 ,32 ,SECT_4K |SPI_NOR_QUAD_READ ) }, + {"n25q032" ,INFO (0x20ba16 ,0 ,64 *1024 ,64 ,SPI_NOR_QUAD_READ ) }, + {"n25q032a" ,INFO (0x20bb16 ,0 ,64 *1024 ,64 ,SPI_NOR_QUAD_READ ) }, + {"n25q064" ,INFO (0x20ba17 ,0 ,64 *1024 ,128 ,SECT_4K |SPI_NOR_QUAD_READ ) }, + {"n25q064a" ,INFO (0x20bb17 ,0 ,64 *1024 ,128 ,SECT_4K |SPI_NOR_QUAD_READ ) }, + {"n25q128a11" ,INFO (0x20bb18 ,0 ,64 *1024 ,256 ,SECT_4K |SPI_NOR_QUAD_READ ) }, + {"n25q128a13" ,INFO (0x20ba18 ,0 ,64 *1024 ,256 ,SECT_4K |SPI_NOR_QUAD_READ ) }, + {"n25q256a" ,INFO (0x20ba19 ,0 ,64 *1024 ,512 ,SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ ) }, + {"n25q256ax1" ,INFO (0x20bb19 ,0 ,64 *1024 ,512 ,SECT_4K |SPI_NOR_QUAD_READ ) }, + {"n25q512a" ,INFO (0x20bb20 ,0 ,64 *1024 ,1024 ,SECT_4K |USE_FSR |SPI_NOR_QUAD_READ ) }, + {"n25q512ax3" ,INFO (0x20ba20 ,0 ,64 *1024 ,1024 ,SECT_4K |USE_FSR |SPI_NOR_QUAD_READ ) }, + {"n25q00" ,INFO (0x20ba21 ,0 ,64 *1024 ,2048 ,SECT_4K |USE_FSR |SPI_NOR_QUAD_READ |NO_CHIP_ERASE ) }, + {"n25q00a" ,INFO (0x20bb21 ,0 ,64 *1024 ,2048 ,SECT_4K |USE_FSR |SPI_NOR_QUAD_READ |NO_CHIP_ERASE ) }, + {"mt25qu02g" ,INFO (0x20bb22 ,0 ,64 *1024 ,4096 ,SECT_4K |USE_FSR |SPI_NOR_QUAD_READ |NO_CHIP_ERASE ) }, +#endif +#ifdef CONFIG_SPI_FLASH_SPANSION /* SPANSION */ +/* Spansion/Cypress -- single (large) sector size only, at least +* for the chips listed here (without boot sectors). +*/ + {"s25sl032p" ,INFO (0x010215 ,0x4d00 ,64 *1024 ,64 ,SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ ) }, + {"s25sl064p" ,INFO (0x010216 ,0x4d00 ,64 *1024 ,128 ,SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ ) }, + {"s25fl256s0" ,INFO (0x010219 ,0x4d00 ,256 *1024 ,128 ,USE_CLSR ) }, + {"s25fl256s1" ,INFO (0x010219 ,0x4d01 ,64 *1024 ,512 ,SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ |USE_CLSR ) }, + {"s25fl512s" ,INFO6 (0x010220 ,0x4d0081 ,256 *1024 ,256 ,SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ |USE_CLSR ) }, + {"s25fl512s_256k" ,INFO (0x010220 ,0x4d00 ,256 *1024 ,256 ,SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ |USE_CLSR ) }, + {"s25fl512s_64k" ,INFO (0x010220 ,0x4d01 ,64 *1024 ,1024 ,SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ |USE_CLSR ) }, + {"s25fl512s_512k" ,INFO (0x010220 ,0x4f00 ,256 *1024 ,256 ,SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ |USE_CLSR ) }, + {"s25sl12800" ,INFO (0x012018 ,0x0300 ,256 *1024 ,64 ,0 ) }, + {"s25sl12801" ,INFO (0x012018 ,0x0301 ,64 *1024 ,256 ,0 ) }, + {"s25fl128s" ,INFO6 (0x012018 ,0x4d0180 ,64 *1024 ,256 ,SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ |USE_CLSR ) }, + {"s25fl129p0" ,INFO (0x012018 ,0x4d00 ,256 *1024 ,64 ,SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ |USE_CLSR ) }, + {"s25fl129p1" ,INFO (0x012018 ,0x4d01 ,64 *1024 ,256 ,SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ |USE_CLSR ) }, + {"s25sl008a" ,INFO (0x010213 ,0 ,64 *1024 ,16 ,0 ) }, + {"s25sl016a" ,INFO (0x010214 ,0 ,64 *1024 ,32 ,0 ) }, + {"s25sl032a" ,INFO (0x010215 ,0 ,64 *1024 ,64 ,0 ) }, + {"s25sl064a" ,INFO (0x010216 ,0 ,64 *1024 ,128 ,0 ) }, + {"s25fl116k" ,INFO (0x014015 ,0 ,64 *1024 ,32 ,SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ ) }, + {"s25fl164k" ,INFO (0x014017 ,0 ,64 *1024 ,128 ,SECT_4K ) }, + {"s25fl208k" ,INFO (0x014014 ,0 ,64 *1024 ,16 ,SECT_4K |SPI_NOR_DUAL_READ ) }, + {"s25fl128l" ,INFO (0x016018 ,0 ,64 *1024 ,256 ,SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ |SPI_NOR_4B_OPCODES ) }, +#endif +#ifdef CONFIG_SPI_FLASH_SST /* SST */ +/* SST -- large erase sizes are "overlays", "sectors" are 4K */ + {"sst25vf040b" ,INFO (0xbf258d ,0 ,64 *1024 ,8 ,SECT_4K |SST_WRITE ) }, + {"sst25vf080b" ,INFO (0xbf258e ,0 ,64 *1024 ,16 ,SECT_4K |SST_WRITE ) }, + {"sst25vf016b" ,INFO (0xbf2541 ,0 ,64 *1024 ,32 ,SECT_4K |SST_WRITE ) }, + {"sst25vf032b" ,INFO (0xbf254a ,0 ,64 *1024 ,64 ,SECT_4K |SST_WRITE ) }, + {"sst25vf064c" ,INFO (0xbf254b ,0 ,64 *1024 ,128 ,SECT_4K ) }, + {"sst25wf512" ,INFO (0xbf2501 ,0 ,64 *1024 ,1 ,SECT_4K |SST_WRITE ) }, + {"sst25wf010" ,INFO (0xbf2502 ,0 ,64 *1024 ,2 ,SECT_4K |SST_WRITE ) }, + {"sst25wf020" ,INFO (0xbf2503 ,0 ,64 *1024 ,4 ,SECT_4K |SST_WRITE ) }, + {"sst25wf020a" ,INFO (0x621612 ,0 ,64 *1024 ,4 ,SECT_4K ) }, + {"sst25wf040b" ,INFO (0x621613 ,0 ,64 *1024 ,8 ,SECT_4K ) }, + {"sst25wf040" ,INFO (0xbf2504 ,0 ,64 *1024 ,8 ,SECT_4K |SST_WRITE ) }, + {"sst25wf080" ,INFO (0xbf2505 ,0 ,64 *1024 ,16 ,SECT_4K |SST_WRITE ) }, + {"sst26vf064b" ,INFO (0xbf2643 ,0 ,64 *1024 ,128 ,SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ ) }, + {"sst26wf016" ,INFO (0xbf2651 ,0 ,64 *1024 ,32 ,SECT_4K ) }, + {"sst26wf032" ,INFO (0xbf2622 ,0 ,64 *1024 ,64 ,SECT_4K ) }, + {"sst26wf064" ,INFO (0xbf2643 ,0 ,64 *1024 ,128 ,SECT_4K ) }, +#endif +#ifdef CONFIG_SPI_FLASH_STMICRO /* STMICRO */ +/* ST Microelectronics -- newer production may have feature updates */ + {"m25p10" ,INFO (0x202011 ,0 ,32 *1024 ,4 ,0 ) }, + {"m25p20" ,INFO (0x202012 ,0 ,64 *1024 ,4 ,0 ) }, + {"m25p40" ,INFO (0x202013 ,0 ,64 *1024 ,8 ,0 ) }, + {"m25p80" ,INFO (0x202014 ,0 ,64 *1024 ,16 ,0 ) }, + {"m25p16" ,INFO (0x202015 ,0 ,64 *1024 ,32 ,0 ) }, + {"m25p32" ,INFO (0x202016 ,0 ,64 *1024 ,64 ,0 ) }, + {"m25p64" ,INFO (0x202017 ,0 ,64 *1024 ,128 ,0 ) }, + {"m25p128" ,INFO (0x202018 ,0 ,256 *1024 ,64 ,0 ) }, + {"m25pe16" ,INFO (0x208015 ,0 ,64 *1024 ,32 ,SECT_4K ) }, + {"m25px16" ,INFO (0x207115 ,0 ,64 *1024 ,32 ,SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ ) }, + {"m25px64" ,INFO (0x207117 ,0 ,64 *1024 ,128 ,0 ) }, +#endif +#ifdef CONFIG_SPI_FLASH_WINBOND /* WINBOND */ +/* Winbond -- w25x "blocks" are 64K, "sectors" are 4KiB */ + {"w25x05" ,INFO (0xef3010 ,0 ,64 *1024 ,1 ,SECT_4K ) }, + {"w25x10" ,INFO (0xef3011 ,0 ,64 *1024 ,2 ,SECT_4K ) }, + {"w25x20" ,INFO (0xef3012 ,0 ,64 *1024 ,4 ,SECT_4K ) }, + {"w25x40" ,INFO (0xef3013 ,0 ,64 *1024 ,8 ,SECT_4K ) }, + {"w25x80" ,INFO (0xef3014 ,0 ,64 *1024 ,16 ,SECT_4K ) }, + {"w25x16" ,INFO (0xef3015 ,0 ,64 *1024 ,32 ,SECT_4K ) }, + { +"w25q16dw" ,INFO (0xef6015 ,0 ,64 *1024 ,32 , +SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ | +SPI_NOR_HAS_LOCK |SPI_NOR_HAS_TB ) + }, + {"w25x32" ,INFO (0xef3016 ,0 ,64 *1024 ,64 ,SECT_4K ) }, + {"w25q20cl" ,INFO (0xef4012 ,0 ,64 *1024 ,4 ,SECT_4K ) }, + {"w25q20bw" ,INFO (0xef5012 ,0 ,64 *1024 ,4 ,SECT_4K ) }, + {"w25q20ew" ,INFO (0xef6012 ,0 ,64 *1024 ,4 ,SECT_4K ) }, + {"w25q32" ,INFO (0xef4016 ,0 ,64 *1024 ,64 ,SECT_4K ) }, + { +"w25q32dw" ,INFO (0xef6016 ,0 ,64 *1024 ,64 , +SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ | +SPI_NOR_HAS_LOCK |SPI_NOR_HAS_TB ) + }, + { +"w25q32jv" ,INFO (0xef7016 ,0 ,64 *1024 ,64 , +SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ | +SPI_NOR_HAS_LOCK |SPI_NOR_HAS_TB ) + }, + {"w25x64" ,INFO (0xef3017 ,0 ,64 *1024 ,128 ,SECT_4K ) }, + {"w25q64" ,INFO (0xef4017 ,0 ,64 *1024 ,128 ,SECT_4K ) }, + { +"w25q64dw" ,INFO (0xef6017 ,0 ,64 *1024 ,128 , +SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ | +SPI_NOR_HAS_LOCK |SPI_NOR_HAS_TB ) + }, + { +"w25q128fw" ,INFO (0xef6018 ,0 ,64 *1024 ,256 , +SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ | +SPI_NOR_HAS_LOCK |SPI_NOR_HAS_TB ) + }, + {"w25q80" ,INFO (0xef5014 ,0 ,64 *1024 ,16 ,SECT_4K ) }, + {"w25q80bl" ,INFO (0xef4014 ,0 ,64 *1024 ,16 ,SECT_4K ) }, + {"w25q128" ,INFO (0xef4018 ,0 ,64 *1024 ,256 ,SECT_4K ) }, + {"w25q256" ,INFO (0xef4019 ,0 ,64 *1024 ,512 ,SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ ) }, + {"w25m512jv" ,INFO (0xef7119 ,0 ,64 *1024 ,1024 , +SECT_4K |SPI_NOR_QUAD_READ |SPI_NOR_DUAL_READ ) }, +#endif +#ifdef CONFIG_SPI_FLASH_XMC +/* XMC (Wuhan Xinxin Semiconductor Manufacturing Corp.) */ + {"XM25QH64A" ,INFO (0x207017 ,0 ,64 *1024 ,128 ,SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ ) }, + {"XM25QH128A" ,INFO (0x207018 ,0 ,64 *1024 ,256 ,SECT_4K |SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ ) }, +#endif + { }, +}; + +static const struct flash_info *spi_nor_read_id (struct spi_nor *nor) +{ +int tmp; +u8 id[SPI_NOR_MAX_ID_LEN ]; +const struct flash_info *info; + +if (!ARRAY_SIZE (spi_nor_ids)) +return ERR_PTR (-ENODEV ); + + tmp = nor->read_reg (nor,SPINOR_OP_RDID , id,SPI_NOR_MAX_ID_LEN ); +if (tmp <0 ) { +dev_dbg (nor->dev,"error %d reading JEDEC ID\n" , tmp); +return ERR_PTR (tmp); + } + +for (tmp =0 ; tmp <ARRAY_SIZE (spi_nor_ids) -1 ; tmp++) { + info = &spi_nor_ids[tmp]; +if (info->id_len) { +if (!memcmp (info->id, id, info->id_len)) +return &spi_nor_ids[tmp]; + } + } +dev_err (nor->dev,"unrecognized JEDEC id bytes: %02x, %02x, %02x\n" , + id[0 ], id[1 ], id[2 ]); +return ERR_PTR (-ENODEV ); +} + +static int spi_nor_read (struct mtd_info *mtd,loff_t from,size_t len, +size_t *retlen,u_char *buf) +{ +struct spi_nor *nor =mtd_to_spi_nor (mtd); +int ret; + +dev_dbg (nor->dev,"from 0x%08x, len %zd\n" , (u32 )from, len); + +while (len) { +loff_t addr = from; + + ret = nor->read (nor, addr, len, buf); +if (ret ==0 ) { +/* We shouldn't see 0-length reads */ + ret = -EIO ; + goto read_err; + } +if (ret <0 ) + goto read_err; + + *retlen += ret; + buf += ret; + from += ret; + len -= ret; + } + ret =0 ; + +read_err: +return ret; +} + +#ifdef CONFIG_SPI_FLASH_SST +static int sst_write (struct mtd_info *mtd,loff_t to,size_t len, +size_t *retlen,const u_char *buf) +{ +struct spi_nor *nor =mtd_to_spi_nor (mtd); +size_t actual; +int ret; + +dev_dbg (nor->dev,"to 0x%08x, len %zd\n" , (u32 )to, len); + +write_enable (nor); + + nor->sst_write_second = false; + + actual = to %2 ; +/* Start write from odd address. */ +if (actual) { + nor->program_opcode =SPINOR_OP_BP ; + +/* write one byte. */ + ret = nor->write (nor, to,1 , buf); +if (ret <0 ) + goto sst_write_err; + ret =spi_nor_wait_till_ready (nor); +if (ret) + goto sst_write_err; + } + to += actual; + +/* Write out most of the data here. */ +for (; actual < len -1 ; actual +=2 ) { + nor->program_opcode =SPINOR_OP_AAI_WP ; + +/* write two bytes. */ + ret = nor->write (nor, to,2 , buf + actual); +if (ret <0 ) + goto sst_write_err; + ret =spi_nor_wait_till_ready (nor); +if (ret) + goto sst_write_err; + to +=2 ; + nor->sst_write_second = true; + } + nor->sst_write_second = false; + +write_disable (nor); + ret =spi_nor_wait_till_ready (nor); +if (ret) + goto sst_write_err; + +/* Write out trailing byte if it exists. */ +if (actual != len) { +write_enable (nor); + + nor->program_opcode =SPINOR_OP_BP ; + ret = nor->write (nor, to,1 , buf + actual); +if (ret <0 ) + goto sst_write_err; + ret =spi_nor_wait_till_ready (nor); +if (ret) + goto sst_write_err; +write_disable (nor); + actual +=1 ; + } +sst_write_err: + *retlen += actual; +return ret; +} +#endif +/* +* Write an address range to the nor chip. Data must be written in +* FLASH_PAGESIZE chunks. The address range may be any size provided +* it is within the physical boundaries. +*/ +static int spi_nor_write (struct mtd_info *mtd,loff_t to,size_t len, +size_t *retlen,const u_char *buf) +{ +struct spi_nor *nor =mtd_to_spi_nor (mtd); +size_t page_offset, page_remain, i; +ssize_t ret; + +dev_dbg (nor->dev,"to 0x%08x, len %zd\n" , (u32 )to, len); + +for (i =0 ; i < len; ) { +ssize_t written; +loff_t addr = to + i; + +/* +* If page_size is a power of two, the offset can be quickly +* calculated with an AND operation. On the other cases we +* need to do a modulus operation (more expensive). +* Power of two numbers have only one bit set and we can use +* the instruction hweight32 to detect if we need to do a +* modulus (do_div()) or not. +*/ +if (hweight32 (nor->page_size) ==1 ) { + page_offset = addr & (nor->page_size -1 ); + }else { +u64 aux = addr; + + page_offset =do_div (aux, nor->page_size); + } +/* the size of data remaining on the first page */ + page_remain =min_t (size_t, + nor->page_size - page_offset, len - i); + +write_enable (nor); + ret = nor->write (nor, addr, page_remain, buf + i); +if (ret <0 ) + goto write_err; + written = ret; + + ret =spi_nor_wait_till_ready (nor); +if (ret) + goto write_err; + *retlen += written; + i += written; +if (written != page_remain) { +dev_dbg (nor->dev, +"While writing %zu bytes written %zd bytes\n" , + page_remain, written); + ret = -EIO ; + goto write_err; + } + } + +write_err: +return ret; +} + +#ifdef CONFIG_SPI_FLASH_MACRONIX +/** +* macronix_quad_enable() - set QE bit in Status Register. +* @nor: pointer to a 'struct spi_nor' +* +* Set the Quad Enable (QE) bit in the Status Register. +* +* bit 6 of the Status Register is the QE bit for Macronix like QSPI memories. +* +* Return: 0 on success, -errno otherwise. +*/ +static int macronix_quad_enable (struct spi_nor *nor) +{ +int ret, val; + + val =read_sr (nor); +if (val <0 ) +return val; +if (val &SR_QUAD_EN_MX ) +return 0 ; + +write_enable (nor); + +write_sr (nor, val |SR_QUAD_EN_MX ); + + ret =spi_nor_wait_till_ready (nor); +if (ret) +return ret; + + ret =read_sr (nor); +if (!(ret >0 && (ret &SR_QUAD_EN_MX ))) { +dev_err (nor->dev,"Macronix Quad bit not set\n" ); +return -EINVAL ; + } + +return 0 ; +} +#endif + +#if defined(CONFIG_SPI_FLASH_SPANSION ) || defined(CONFIG_SPI_FLASH_WINBOND ) +/* +* Write status Register and configuration register with 2 bytes +* The first byte will be written to the status register, while the +* second byte will be written to the configuration register. +* Return negative if error occurred. +*/ +static int write_sr_cr (struct spi_nor *nor,u8 *sr_cr) +{ +int ret; + +write_enable (nor); + + ret = nor->write_reg (nor,SPINOR_OP_WRSR , sr_cr,2 ); +if (ret <0 ) { +dev_dbg (nor->dev, +"error while writing configuration register\n" ); +return -EINVAL ; + } + + ret =spi_nor_wait_till_ready (nor); +if (ret) { +dev_dbg (nor->dev, +"timeout while writing configuration register\n" ); +return ret; + } + +return 0 ; +} + +/** +* spansion_read_cr_quad_enable() - set QE bit in Configuration Register. +* @nor: pointer to a 'struct spi_nor' +* +* Set the Quad Enable (QE) bit in the Configuration Register. +* This function should be used with QSPI memories supporting the Read +* Configuration Register (35h) instruction. +* +* bit 1 of the Configuration Register is the QE bit for Spansion like QSPI +* memories. +* +* Return: 0 on success, -errno otherwise. +*/ +static int spansion_read_cr_quad_enable (struct spi_nor *nor) +{ +u8 sr_cr[2 ]; +int ret; + +/* Check current Quad Enable bit value. */ + ret =read_cr (nor); +if (ret <0 ) { +dev_dbg (dev,"error while reading configuration register\n" ); +return -EINVAL ; + } + +if (ret &CR_QUAD_EN_SPAN ) +return 0 ; + + sr_cr[1 ] = ret |CR_QUAD_EN_SPAN ; + +/* Keep the current value of the Status Register. */ + ret =read_sr (nor); +if (ret <0 ) { +dev_dbg (dev,"error while reading status register\n" ); +return -EINVAL ; + } + sr_cr[0 ] = ret; + + ret =write_sr_cr (nor, sr_cr); +if (ret) +return ret; + +/* Read back and check it. */ + ret =read_cr (nor); +if (!(ret >0 && (ret &CR_QUAD_EN_SPAN ))) { +dev_dbg (nor->dev,"Spansion Quad bit not set\n" ); +return -EINVAL ; + } + +return 0 ; +} + +#if CONFIG_IS_ENABLED (SPI_FLASH_SFDP_SUPPORT ) +/** +* spansion_no_read_cr_quad_enable() - set QE bit in Configuration Register. +* @nor: pointer to a 'struct spi_nor' +* +* Set the Quad Enable (QE) bit in the Configuration Register. +* This function should be used with QSPI memories not supporting the Read +* Configuration Register (35h) instruction. +* +* bit 1 of the Configuration Register is the QE bit for Spansion like QSPI +* memories. +* +* Return: 0 on success, -errno otherwise. +*/ +static int spansion_no_read_cr_quad_enable (struct spi_nor *nor) +{ +u8 sr_cr[2 ]; +int ret; + +/* Keep the current value of the Status Register. */ + ret =read_sr (nor); +if (ret <0 ) { +dev_dbg (nor->dev,"error while reading status register\n" ); +return -EINVAL ; + } + sr_cr[0 ] = ret; + sr_cr[1 ] =CR_QUAD_EN_SPAN ; + +return write_sr_cr (nor, sr_cr); +} + +#endif /* CONFIG_SPI_FLASH_SFDP_SUPPORT */ +#endif /* CONFIG_SPI_FLASH_SPANSION */ + +struct spi_nor_read_command { +u8 num_mode_clocks; +u8 num_wait_states; +u8 opcode; +enum spi_nor_protocol proto; +}; + +struct spi_nor_pp_command { +u8 opcode; +enum spi_nor_protocol proto; +}; + +enum spi_nor_read_command_index { +SNOR_CMD_READ , +SNOR_CMD_READ_FAST , +SNOR_CMD_READ_1_1_1_DTR , + +/* Dual SPI */ +SNOR_CMD_READ_1_1_2 , +SNOR_CMD_READ_1_2_2 , +SNOR_CMD_READ_2_2_2 , +SNOR_CMD_READ_1_2_2_DTR , + +/* Quad SPI */ +SNOR_CMD_READ_1_1_4 , +SNOR_CMD_READ_1_4_4 , +SNOR_CMD_READ_4_4_4 , +SNOR_CMD_READ_1_4_4_DTR , + +/* Octo SPI */ +SNOR_CMD_READ_1_1_8 , +SNOR_CMD_READ_1_8_8 , +SNOR_CMD_READ_8_8_8 , +SNOR_CMD_READ_1_8_8_DTR , + +SNOR_CMD_READ_MAX +}; + +enum spi_nor_pp_command_index { +SNOR_CMD_PP , + +/* Quad SPI */ +SNOR_CMD_PP_1_1_4 , +SNOR_CMD_PP_1_4_4 , +SNOR_CMD_PP_4_4_4 , + +/* Octo SPI */ +SNOR_CMD_PP_1_1_8 , +SNOR_CMD_PP_1_8_8 , +SNOR_CMD_PP_8_8_8 , + +SNOR_CMD_PP_MAX +}; + +struct spi_nor_flash_parameter { +u64 size; +u32 page_size; + +struct spi_nor_hwcaps hwcaps; +struct spi_nor_read_command reads[SNOR_CMD_READ_MAX ]; +struct spi_nor_pp_command page_programs[SNOR_CMD_PP_MAX ]; + +int (*quad_enable)(struct spi_nor *nor); +}; + +static void +spi_nor_set_read_settings (struct spi_nor_read_command *read, +u8 num_mode_clocks, +u8 num_wait_states, +u8 opcode, +enum spi_nor_protocol proto) +{ + read->num_mode_clocks = num_mode_clocks; + read->num_wait_states = num_wait_states; + read->opcode = opcode; + read->proto = proto; +} + +static void +spi_nor_set_pp_settings (struct spi_nor_pp_command *pp, +u8 opcode, +enum spi_nor_protocol proto) +{ + pp->opcode = opcode; + pp->proto = proto; +} + +#if CONFIG_IS_ENABLED (SPI_FLASH_SFDP_SUPPORT ) +/* +* Serial Flash Discoverable Parameters (SFDP) parsing. +*/ + +/** +* spi_nor_read_sfdp() - read Serial Flash Discoverable Parameters. +* @nor: pointer to a 'struct spi_nor' +* @addr: offset in the SFDP area to start reading data from +* @len: number of bytes to read +* @buf: buffer where the SFDP data are copied into (dma-safe memory) +* +* Whatever the actual numbers of bytes for address and dummy cycles are +* for (Fast) Read commands, the Read SFDP (5Ah) instruction is always +* followed by a 3-byte address and 8 dummy clock cycles. +* +* Return: 0 on success, -errno otherwise. +*/ +static int spi_nor_read_sfdp (struct spi_nor *nor,u32 addr, +size_t len,void *buf) +{ +u8 addr_width, read_opcode, read_dummy; +int ret; + + read_opcode = nor->read_opcode; + addr_width = nor->addr_width; + read_dummy = nor->read_dummy; + + nor->read_opcode =SPINOR_OP_RDSFDP ; + nor->addr_width =3 ; + nor->read_dummy =8 ; + +while (len) { + ret = nor->read (nor, addr, len, (u8 *)buf); +if (!ret || ret > len) { + ret = -EIO ; + goto read_err; + } +if (ret <0 ) + goto read_err; + + buf += ret; + addr += ret; + len -= ret; + } + ret =0 ; + +read_err: + nor->read_opcode = read_opcode; + nor->addr_width = addr_width; + nor->read_dummy = read_dummy; + +return ret; +} + +struct sfdp_parameter_header { +u8 id_lsb; +u8 minor; +u8 major; +u8 length;/* in double words */ +u8 parameter_table_pointer[3 ];/* byte address */ +u8 id_msb; +}; + +#define SFDP_PARAM_HEADER_ID (p) (((p)->id_msb << 8) | (p)->id_lsb) +#define SFDP_PARAM_HEADER_PTP (p) \ + (((p)->parameter_table_pointer[2] << 16) | \ + ((p)->parameter_table_pointer[1] << 8) | \ + ((p)->parameter_table_pointer[0] << 0)) + +#define SFDP_BFPT_ID 0xff00/* Basic Flash Parameter Table */ +#define SFDP_SECTOR_MAP_ID 0xff81/* Sector Map Table */ + +#define SFDP_SIGNATURE 0x50444653U +#define SFDP_JESD216_MAJOR 1 +#define SFDP_JESD216_MINOR 0 +#define SFDP_JESD216A_MINOR 5 +#define SFDP_JESD216B_MINOR 6 + +struct sfdp_header { +u32 signature;/* Ox50444653U <=> "SFDP" */ +u8 minor; +u8 major; +u8 nph;/* 0-base number of parameter headers */ +u8 unused; + +/* Basic Flash Parameter Table. */ +struct sfdp_parameter_header bfpt_header; +}; + +/* Basic Flash Parameter Table */ + +/* +* JESD216 rev B defines a Basic Flash Parameter Table of 16 DWORDs. +* They are indexed from 1 but C arrays are indexed from 0. +*/ +#define BFPT_DWORD (i) ((i) - 1) +#define BFPT_DWORD_MAX 16 + +/* The first version of JESB216 defined only 9 DWORDs. */ +#define BFPT_DWORD_MAX_JESD216 9 + +/* 1st DWORD. */ +#define BFPT_DWORD1_FAST_READ_1_1_2 BIT(16) +#define BFPT_DWORD1_ADDRESS_BYTES_MASK GENMASK(18, 17) +#define BFPT_DWORD1_ADDRESS_BYTES_3_ONLY (0x0UL << 17) +#define BFPT_DWORD1_ADDRESS_BYTES_3_OR_4 (0x1UL << 17) +#define BFPT_DWORD1_ADDRESS_BYTES_4_ONLY (0x2UL << 17) +#define BFPT_DWORD1_DTR BIT(19) +#define BFPT_DWORD1_FAST_READ_1_2_2 BIT(20) +#define BFPT_DWORD1_FAST_READ_1_4_4 BIT(21) +#define BFPT_DWORD1_FAST_READ_1_1_4 BIT(22) + +/* 5th DWORD. */ +#define BFPT_DWORD5_FAST_READ_2_2_2 BIT(0) +#define BFPT_DWORD5_FAST_READ_4_4_4 BIT(4) + +/* 11th DWORD. */ +#define BFPT_DWORD11_PAGE_SIZE_SHIFT 4 +#define BFPT_DWORD11_PAGE_SIZE_MASK GENMASK(7, 4) + +/* 15th DWORD. */ + +/* +* (from JESD216 rev B) +* Quad Enable Requirements (QER): +* - 000b: Device does not have a QE bit. Device detects 1-1-4 and 1-4-4 +* reads based on instruction. DQ3/HOLD# functions are hold during +* instruction phase. +* - 001b: QE is bit 1 of status register 2. It is set via Write Status with +* two data bytes where bit 1 of the second byte is one. +* [...] +* Writing only one byte to the status register has the side-effect of +* clearing status register 2, including the QE bit. The 100b code is +* used if writing one byte to the status register does not modify +* status register 2. +* - 010b: QE is bit 6 of status register 1. It is set via Write Status with +* one data byte where bit 6 is one. +* [...] +* - 011b: QE is bit 7 of status register 2. It is set via Write status +* register 2 instruction 3Eh with one data byte where bit 7 is one. +* [...] +* The status register 2 is read using instruction 3Fh. +* - 100b: QE is bit 1 of status register 2. It is set via Write Status with +* two data bytes where bit 1 of the second byte is one. +* [...] +* In contrast to the 001b code, writing one byte to the status +* register does not modify status register 2. +* - 101b: QE is bit 1 of status register 2. Status register 1 is read using +* Read Status instruction 05h. Status register2 is read using +* instruction 35h. QE is set via Writ Status instruction 01h with +* two data bytes where bit 1 of the second byte is one. +* [...] +*/ +#define BFPT_DWORD15_QER_MASK GENMASK(22, 20) +#define BFPT_DWORD15_QER_NONE (0x0UL << 20)/* Micron */ +#define BFPT_DWORD15_QER_SR2_BIT1_BUGGY (0x1UL << 20) +#define BFPT_DWORD15_QER_SR1_BIT6 (0x2UL << 20)/* Macronix */ +#define BFPT_DWORD15_QER_SR2_BIT7 (0x3UL << 20) +#define BFPT_DWORD15_QER_SR2_BIT1_NO_RD (0x4UL << 20) +#define BFPT_DWORD15_QER_SR2_BIT1 (0x5UL << 20)/* Spansion */ + +struct sfdp_bfpt { +u32 dwords[BFPT_DWORD_MAX ]; +}; + +/* Fast Read settings. */ + +static inline void +spi_nor_set_read_settings_from_bfpt (struct spi_nor_read_command *read, +u16 half, +enum spi_nor_protocol proto) +{ + read->num_mode_clocks = (half >>5 ) &0x07 ; + read->num_wait_states = (half >>0 ) &0x1f ; + read->opcode = (half >>8 ) &0xff ; + read->proto = proto; +} + +struct sfdp_bfpt_read { +/* The Fast Read x-y-z hardware capability in params->hwcaps.mask. */ +u32 hwcaps; + +/* +* The <supported_bit> bit in <supported_dword> BFPT DWORD tells us +* whether the Fast Read x-y-z command is supported. +*/ +u32 supported_dword; +u32 supported_bit; + +/* +* The half-word at offset <setting_shift> in <setting_dword> BFPT DWORD +* encodes the op code, the number of mode clocks and the number of wait +* states to be used by Fast Read x-y-z command. +*/ +u32 settings_dword; +u32 settings_shift; + +/* The SPI protocol for this Fast Read x-y-z command. */ +enum spi_nor_protocol proto; +}; + +static const struct sfdp_bfpt_read sfdp_bfpt_reads[] = { +/* Fast Read 1-1-2 */ + { +SNOR_HWCAPS_READ_1_1_2 , +BFPT_DWORD (1 ),BIT (16 ),/* Supported bit */ +BFPT_DWORD (4 ),0 ,/* Settings */ +SNOR_PROTO_1_1_2 , + }, + +/* Fast Read 1-2-2 */ + { +SNOR_HWCAPS_READ_1_2_2 , +BFPT_DWORD (1 ),BIT (20 ),/* Supported bit */ +BFPT_DWORD (4 ),16 ,/* Settings */ +SNOR_PROTO_1_2_2 , + }, + +/* Fast Read 2-2-2 */ + { +SNOR_HWCAPS_READ_2_2_2 , +BFPT_DWORD (5 ),BIT (0 ),/* Supported bit */ +BFPT_DWORD (6 ),16 ,/* Settings */ +SNOR_PROTO_2_2_2 , + }, + +/* Fast Read 1-1-4 */ + { +SNOR_HWCAPS_READ_1_1_4 , +BFPT_DWORD (1 ),BIT (22 ),/* Supported bit */ +BFPT_DWORD (3 ),16 ,/* Settings */ +SNOR_PROTO_1_1_4 , + }, + +/* Fast Read 1-4-4 */ + { +SNOR_HWCAPS_READ_1_4_4 , +BFPT_DWORD (1 ),BIT (21 ),/* Supported bit */ +BFPT_DWORD (3 ),0 ,/* Settings */ +SNOR_PROTO_1_4_4 , + }, + +/* Fast Read 4-4-4 */ + { +SNOR_HWCAPS_READ_4_4_4 , +BFPT_DWORD (5 ),BIT (4 ),/* Supported bit */ +BFPT_DWORD (7 ),16 ,/* Settings */ +SNOR_PROTO_4_4_4 , + }, +}; + +struct sfdp_bfpt_erase { +/* +* The half-word at offset <shift> in DWORD <dwoard> encodes the +* op code and erase sector size to be used by Sector Erase commands. +*/ +u32 dword; +u32 shift; +}; + +static const struct sfdp_bfpt_erase sfdp_bfpt_erases[] = { +/* Erase Type 1 in DWORD8 bits[15:0] */ + {BFPT_DWORD (8 ),0 }, + +/* Erase Type 2 in DWORD8 bits[31:16] */ + {BFPT_DWORD (8 ),16 }, + +/* Erase Type 3 in DWORD9 bits[15:0] */ + {BFPT_DWORD (9 ),0 }, + +/* Erase Type 4 in DWORD9 bits[31:16] */ + {BFPT_DWORD (9 ),16 }, +}; + +static int spi_nor_hwcaps2cmd (u32 hwcaps,const int table[][2 ],size_t size) +{ +size_t i; + +for (i =0 ; i < size; i++) +if (table[i][0 ] == (int )hwcaps) +return table[i][1 ]; + +return -EINVAL ; +} + +static int spi_nor_hwcaps_read2cmd (u32 hwcaps) +{ +static const int hwcaps_read2cmd[][2 ] = { + {SNOR_HWCAPS_READ ,SNOR_CMD_READ }, + {SNOR_HWCAPS_READ_FAST ,SNOR_CMD_READ_FAST }, + {SNOR_HWCAPS_READ_1_1_1_DTR ,SNOR_CMD_READ_1_1_1_DTR }, + {SNOR_HWCAPS_READ_1_1_2 ,SNOR_CMD_READ_1_1_2 }, + {SNOR_HWCAPS_READ_1_2_2 ,SNOR_CMD_READ_1_2_2 }, + {SNOR_HWCAPS_READ_2_2_2 ,SNOR_CMD_READ_2_2_2 }, + {SNOR_HWCAPS_READ_1_2_2_DTR ,SNOR_CMD_READ_1_2_2_DTR }, + {SNOR_HWCAPS_READ_1_1_4 ,SNOR_CMD_READ_1_1_4 }, + {SNOR_HWCAPS_READ_1_4_4 ,SNOR_CMD_READ_1_4_4 }, + {SNOR_HWCAPS_READ_4_4_4 ,SNOR_CMD_READ_4_4_4 }, + {SNOR_HWCAPS_READ_1_4_4_DTR ,SNOR_CMD_READ_1_4_4_DTR }, + {SNOR_HWCAPS_READ_1_1_8 ,SNOR_CMD_READ_1_1_8 }, + {SNOR_HWCAPS_READ_1_8_8 ,SNOR_CMD_READ_1_8_8 }, + {SNOR_HWCAPS_READ_8_8_8 ,SNOR_CMD_READ_8_8_8 }, + {SNOR_HWCAPS_READ_1_8_8_DTR ,SNOR_CMD_READ_1_8_8_DTR }, + }; + +return spi_nor_hwcaps2cmd (hwcaps, hwcaps_read2cmd, +ARRAY_SIZE (hwcaps_read2cmd)); +} + +/** +* spi_nor_parse_bfpt() - read and parse the Basic Flash Parameter Table. +* @nor: pointer to a 'struct spi_nor' +* @bfpt_header: pointer to the 'struct sfdp_parameter_header' describing +* the Basic Flash Parameter Table length and version +* @params: pointer to the 'struct spi_nor_flash_parameter' to be +* filled +* +* The Basic Flash Parameter Table is the main and only mandatory table as +* defined by the SFDP (JESD216) specification. +* It provides us with the total size (memory density) of the data array and +* the number of address bytes for Fast Read, Page Program and Sector Erase +* commands. +* For Fast READ commands, it also gives the number of mode clock cycles and +* wait states (regrouped in the number of dummy clock cycles) for each +* supported instruction op code. +* For Page Program, the page size is now available since JESD216 rev A, however +* the supported instruction op codes are still not provided. +* For Sector Erase commands, this table stores the supported instruction op +* codes and the associated sector sizes. +* Finally, the Quad Enable Requirements (QER) are also available since JESD216 +* rev A. The QER bits encode the manufacturer dependent procedure to be +* executed to set the Quad Enable (QE) bit in some internal register of the +* Quad SPI memory. Indeed the QE bit, when it exists, must be set before +* sending any Quad SPI command to the memory. Actually, setting the QE bit +* tells the memory to reassign its WP# and HOLD#/RESET# pins to functions IO2 +* and IO3 hence enabling 4 (Quad) I/O lines. +* +* Return: 0 on success, -errno otherwise. +*/ +static int spi_nor_parse_bfpt (struct spi_nor *nor, +const struct sfdp_parameter_header *bfpt_header, +struct spi_nor_flash_parameter *params) +{ +struct mtd_info *mtd = &nor->mtd; +struct sfdp_bfpt bfpt; +size_t len; +int i, cmd, err; +u32 addr; +u16 half; + +/* JESD216 Basic Flash Parameter Table length is at least 9 DWORDs. */ +if (bfpt_header->length <BFPT_DWORD_MAX_JESD216 ) +return -EINVAL ; + +/* Read the Basic Flash Parameter Table. */ + len =min_t (size_t,sizeof (bfpt), + bfpt_header->length *sizeof (u32)); + addr =SFDP_PARAM_HEADER_PTP (bfpt_header); +memset (&bfpt,0 ,sizeof (bfpt)); + err =spi_nor_read_sfdp (nor, addr, len, &bfpt); +if (err <0 ) +return err; + +/* Fix endianness of the BFPT DWORDs. */ +for (i =0 ; i <BFPT_DWORD_MAX ; i++) + bfpt.dwords[i] =le32_to_cpu (bfpt.dwords[i]); + +/* Number of address bytes. */ +switch (bfpt.dwords[BFPT_DWORD (1 )] &BFPT_DWORD1_ADDRESS_BYTES_MASK ) { +case BFPT_DWORD1_ADDRESS_BYTES_3_ONLY : + nor->addr_width =3 ; +break ; + +case BFPT_DWORD1_ADDRESS_BYTES_4_ONLY : + nor->addr_width =4 ; +break ; + +default : +break ; + } + +/* Flash Memory Density (in bits). */ + params->size = bfpt.dwords[BFPT_DWORD (2 )]; +if (params->size &BIT (31 )) { + params->size &= ~BIT (31 ); + +/* +* Prevent overflows on params->size. Anyway, a NOR of 2^64 +* bits is unlikely to exist so this error probably means +* the BFPT we are reading is corrupted/wrong. +*/ +if (params->size >63 ) +return -EINVAL ; + + params->size =1ULL << params->size; + }else { + params->size++; + } + params->size >>=3 ;/* Convert to bytes. */ + +/* Fast Read settings. */ +for (i =0 ; i <ARRAY_SIZE (sfdp_bfpt_reads); i++) { +const struct sfdp_bfpt_read *rd = &sfdp_bfpt_reads[i]; +struct spi_nor_read_command *read; + +if (!(bfpt.dwords[rd->supported_dword] & rd->supported_bit)) { + params->hwcaps.mask &= ~rd->hwcaps; +continue ; + } + + params->hwcaps.mask |= rd->hwcaps; + cmd =spi_nor_hwcaps_read2cmd (rd->hwcaps); + read = ¶ms->reads[cmd]; + half = bfpt.dwords[rd->settings_dword] >> rd->settings_shift; +spi_nor_set_read_settings_from_bfpt (read, half, rd->proto); + } + +/* Sector Erase settings. */ +for (i =0 ; i <ARRAY_SIZE (sfdp_bfpt_erases); i++) { +const struct sfdp_bfpt_erase *er = &sfdp_bfpt_erases[i]; +u32 erasesize; +u8 opcode; + + half = bfpt.dwords[er->dword] >> er->shift; + erasesize = half &0xff ; + +/* erasesize == 0 means this Erase Type is not supported. */ +if (!erasesize) +continue ; + + erasesize =1U << erasesize; + opcode = (half >>8 ) &0xff ; +#ifdef CONFIG_MTD_SPI_NOR_USE_4K_SECTORS +if (erasesize ==SZ_4K ) { + nor->erase_opcode = opcode; + mtd->erasesize = erasesize; +break ; + } +#endif +if (!mtd->erasesize || mtd->erasesize < erasesize) { + nor->erase_opcode = opcode; + mtd->erasesize = erasesize; + } + } + +/* Stop here if not JESD216 rev A or later. */ +if (bfpt_header->length <BFPT_DWORD_MAX ) +return 0 ; + +/* Page size: this field specifies 'N' so the page size = 2^N bytes. */ + params->page_size = bfpt.dwords[BFPT_DWORD (11 )]; + params->page_size &=BFPT_DWORD11_PAGE_SIZE_MASK ; + params->page_size >>=BFPT_DWORD11_PAGE_SIZE_SHIFT ; + params->page_size =1U << params->page_size; + +/* Quad Enable Requirements. */ +switch (bfpt.dwords[BFPT_DWORD (15 )] &BFPT_DWORD15_QER_MASK ) { +case BFPT_DWORD15_QER_NONE : + params->quad_enable =NULL ; +break ; +#if defined(CONFIG_SPI_FLASH_SPANSION ) || defined(CONFIG_SPI_FLASH_WINBOND ) +case BFPT_DWORD15_QER_SR2_BIT1_BUGGY : +case BFPT_DWORD15_QER_SR2_BIT1_NO_RD : + params->quad_enable = spansion_no_read_cr_quad_enable; +break ; +#endif +#ifdef CONFIG_SPI_FLASH_MACRONIX +case BFPT_DWORD15_QER_SR1_BIT6 : + params->quad_enable = macronix_quad_enable; +break ; +#endif +#if defined(CONFIG_SPI_FLASH_SPANSION ) || defined(CONFIG_SPI_FLASH_WINBOND ) +case BFPT_DWORD15_QER_SR2_BIT1 : + params->quad_enable = spansion_read_cr_quad_enable; +break ; +#endif +default : +return -EINVAL ; + } + +return 0 ; +} + +/** +* spi_nor_parse_sfdp() - parse the Serial Flash Discoverable Parameters. +* @nor: pointer to a 'struct spi_nor' +* @params: pointer to the 'struct spi_nor_flash_parameter' to be +* filled +* +* The Serial Flash Discoverable Parameters are described by the JEDEC JESD216 +* specification. This is a standard which tends to supported by almost all +* (Q)SPI memory manufacturers. Those hard-coded tables allow us to learn at +* runtime the main parameters needed to perform basic SPI flash operations such +* as Fast Read, Page Program or Sector Erase commands. +* +* Return: 0 on success, -errno otherwise. +*/ +static int spi_nor_parse_sfdp (struct spi_nor *nor, +struct spi_nor_flash_parameter *params) +{ +const struct sfdp_parameter_header *param_header, *bfpt_header; +struct sfdp_parameter_header *param_headers =NULL ; +struct sfdp_header header; +size_t psize; +int i, err; + +/* Get the SFDP header. */ + err =spi_nor_read_sfdp (nor,0 ,sizeof (header), &header); +if (err <0 ) +return err; + +/* Check the SFDP header version. */ +if (le32_to_cpu (header.signature) !=SFDP_SIGNATURE || + header.major !=SFDP_JESD216_MAJOR ) +return -EINVAL ; + +/* +* Verify that the first and only mandatory parameter header is a +* Basic Flash Parameter Table header as specified in JESD216. +*/ + bfpt_header = &header.bfpt_header; +if (SFDP_PARAM_HEADER_ID (bfpt_header) !=SFDP_BFPT_ID || + bfpt_header->major !=SFDP_JESD216_MAJOR ) +return -EINVAL ; + +/* +* Allocate memory then read all parameter headers with a single +* Read SFDP command. These parameter headers will actually be parsed +* twice: a first time to get the latest revision of the basic flash +* parameter table, then a second time to handle the supported optional +* tables. +* Hence we read the parameter headers once for all to reduce the +* processing time. Also we use kmalloc() instead of devm_kmalloc() +* because we don't need to keep these parameter headers: the allocated +* memory is always released with kfree() before exiting this function. +*/ +if (header.nph) { + psize = header.nph *sizeof (*param_headers); + + param_headers =kmalloc (psize,GFP_KERNEL ); +if (!param_headers) +return -ENOMEM ; + + err =spi_nor_read_sfdp (nor,sizeof (header), + psize, param_headers); +if (err <0 ) { +dev_err (dev,"failed to read SFDP parameter headers\n" ); + goto exit; + } + } + +/* +* Check other parameter headers to get the latest revision of +* the basic flash parameter table. +*/ +for (i =0 ; i < header.nph; i++) { + param_header = ¶m_headers[i]; + +if (SFDP_PARAM_HEADER_ID (param_header) ==SFDP_BFPT_ID && + param_header->major ==SFDP_JESD216_MAJOR && + (param_header->minor > bfpt_header->minor || + (param_header->minor == bfpt_header->minor && + param_header->length > bfpt_header->length))) + bfpt_header = param_header; + } + + err =spi_nor_parse_bfpt (nor, bfpt_header, params); +if (err) + goto exit; + +/* Parse other parameter headers. */ +for (i =0 ; i < header.nph; i++) { + param_header = ¶m_headers[i]; + +switch (SFDP_PARAM_HEADER_ID (param_header)) { +case SFDP_SECTOR_MAP_ID : +dev_info (dev,"non-uniform erase sector maps are not supported yet.\n" ); +break ; + +default : +break ; + } + +if (err) + goto exit; + } + +exit: +kfree (param_headers); +return err; +} +#else +static int spi_nor_parse_sfdp (struct spi_nor *nor, +struct spi_nor_flash_parameter *params) +{ +return -EINVAL ; +} +#endif /* SPI_FLASH_SFDP_SUPPORT */ + +static int spi_nor_init_params (struct spi_nor *nor, +const struct flash_info *info, +struct spi_nor_flash_parameter *params) +{ +/* Set legacy flash parameters as default. */ +memset (params,0 ,sizeof (*params)); + +/* Set SPI NOR sizes. */ + params->size = info->sector_size * info->n_sectors; + params->page_size = info->page_size; + +/* (Fast) Read settings. */ + params->hwcaps.mask |=SNOR_HWCAPS_READ ; +spi_nor_set_read_settings (¶ms->reads[SNOR_CMD_READ ], +0 ,0 ,SPINOR_OP_READ , +SNOR_PROTO_1_1_1 ); + +if (!(info->flags &SPI_NOR_NO_FR )) { + params->hwcaps.mask |=SNOR_HWCAPS_READ_FAST ; +spi_nor_set_read_settings (¶ms->reads[SNOR_CMD_READ_FAST ], +0 ,8 ,SPINOR_OP_READ_FAST , +SNOR_PROTO_1_1_1 ); + } + +if (info->flags &SPI_NOR_DUAL_READ ) { + params->hwcaps.mask |=SNOR_HWCAPS_READ_1_1_2 ; +spi_nor_set_read_settings (¶ms->reads[SNOR_CMD_READ_1_1_2 ], +0 ,8 ,SPINOR_OP_READ_1_1_2 , +SNOR_PROTO_1_1_2 ); + } + +if (info->flags &SPI_NOR_QUAD_READ ) { + params->hwcaps.mask |=SNOR_HWCAPS_READ_1_1_4 ; +spi_nor_set_read_settings (¶ms->reads[SNOR_CMD_READ_1_1_4 ], +0 ,8 ,SPINOR_OP_READ_1_1_4 , +SNOR_PROTO_1_1_4 ); + } + +/* Page Program settings. */ + params->hwcaps.mask |=SNOR_HWCAPS_PP ; +spi_nor_set_pp_settings (¶ms->page_programs[SNOR_CMD_PP ], +SPINOR_OP_PP ,SNOR_PROTO_1_1_1 ); + +if (info->flags &SPI_NOR_QUAD_READ ) { + params->hwcaps.mask |=SNOR_HWCAPS_PP_1_1_4 ; +spi_nor_set_pp_settings (¶ms->page_programs[SNOR_CMD_PP_1_1_4 ], +SPINOR_OP_PP_1_1_4 ,SNOR_PROTO_1_1_4 ); + } + +/* Select the procedure to set the Quad Enable bit. */ +if (params->hwcaps.mask & (SNOR_HWCAPS_READ_QUAD | +SNOR_HWCAPS_PP_QUAD )) { +switch (JEDEC_MFR (info)) { +#ifdef CONFIG_SPI_FLASH_MACRONIX +case SNOR_MFR_MACRONIX : + params->quad_enable = macronix_quad_enable; +break ; +#endif +case SNOR_MFR_ST : +case SNOR_MFR_MICRON : +break ; + +default : +#if defined(CONFIG_SPI_FLASH_SPANSION ) || defined(CONFIG_SPI_FLASH_WINBOND ) +/* Kept only for backward compatibility purpose. */ + params->quad_enable = spansion_read_cr_quad_enable; +#endif +break ; + } +#ifndef __UBOOT__ +/* +* Some manufacturer like GigaDevice may use different +* bit to set QE on different memories, so the MFR can't +* indicate the quad_enable method for this case, we need +* set it in flash info list. +*/ +if (info->quad_enable) + params->quad_enable = info->quad_enable; +#endif + } + +/* Override the parameters with data read from SFDP tables. */ + nor->addr_width =0 ; + nor->mtd.erasesize =0 ; +if ((info->flags & (SPI_NOR_DUAL_READ |SPI_NOR_QUAD_READ )) && + !(info->flags &SPI_NOR_SKIP_SFDP )) { +struct spi_nor_flash_parameter sfdp_params; + +memcpy (&sfdp_params, params,sizeof (sfdp_params)); +if (spi_nor_parse_sfdp (nor, &sfdp_params)) { + nor->addr_width =0 ; + nor->mtd.erasesize =0 ; + }else { +memcpy (params, &sfdp_params,sizeof (*params)); + } + } + +return 0 ; +} + +static int spi_nor_select_read (struct spi_nor *nor, +const struct spi_nor_flash_parameter *params, +u32 shared_hwcaps) +{ +int best_match = shared_hwcaps &SNOR_HWCAPS_READ_MASK ; +int cmd; +const struct spi_nor_read_command *read; + +if (best_match <0 ) +return -EINVAL ; + +if (best_match &SNOR_HWCAPS_READ_1_4_4 ) + cmd =SNOR_CMD_READ_1_4_4 ; +else if (best_match &SNOR_HWCAPS_READ_1_1_4 ) + cmd =SNOR_CMD_READ_1_1_4 ; +else if (best_match &SNOR_HWCAPS_READ_FAST ) + cmd =SNOR_CMD_READ_FAST ; +else + cmd =SNOR_CMD_READ ; + + read = ¶ms->reads[cmd]; + nor->read_opcode = read->opcode; + nor->read_proto = read->proto; + +/* +* In the spi-nor framework, we don't need to make the difference +* between mode clock cycles and wait state clock cycles. +* Indeed, the value of the mode clock cycles is used by a QSPI +* flash memory to know whether it should enter or leave its 0-4-4 +* (Continuous Read / XIP) mode. +* eXecution In Place is out of the scope of the mtd sub-system. +* Hence we choose to merge both mode and wait state clock cycles +* into the so called dummy clock cycles. +*/ + nor->read_dummy = read->num_mode_clocks + read->num_wait_states; +return 0 ; +} + +static int spi_nor_select_pp (struct spi_nor *nor, +const struct spi_nor_flash_parameter *params, +u32 shared_hwcaps) +{ +int best_match = shared_hwcaps &SNOR_HWCAPS_PP_MASK ; +int cmd; +const struct spi_nor_pp_command *pp; + +if (best_match <0 ) +return -EINVAL ; + +if (best_match &SNOR_HWCAPS_PP_1_1_4 ) + cmd =SNOR_CMD_PP_1_1_4 ; +else + cmd =SNOR_CMD_PP ; + + pp = ¶ms->page_programs[cmd]; + nor->program_opcode = pp->opcode; + nor->write_proto = pp->proto; +return 0 ; +} + +static int spi_nor_select_erase (struct spi_nor *nor, +const struct flash_info *info) +{ +struct mtd_info *mtd = &nor->mtd; + +/* Do nothing if already configured from SFDP. */ +if (mtd->erasesize) +return 0 ; + +#ifdef CONFIG_SPI_FLASH_USE_4K_SECTORS +/* prefer "small sector" erase if possible */ +if (info->flags &SECT_4K ) { + nor->erase_opcode =SPINOR_OP_BE_4K ; + mtd->erasesize =4096 ; + }else if (info->flags &SECT_4K_PMC ) { + nor->erase_opcode =SPINOR_OP_BE_4K_PMC ; + mtd->erasesize =4096 ; + } else +#endif + { + nor->erase_opcode =SPINOR_OP_SE ; + mtd->erasesize = info->sector_size; + } +return 0 ; +} + +static int spi_nor_setup (struct spi_nor *nor,const struct flash_info *info, +const struct spi_nor_flash_parameter *params, +const struct spi_nor_hwcaps *hwcaps) +{ +u32 ignored_mask, shared_mask; +bool enable_quad_io; +int err; + +/* +* Keep only the hardware capabilities supported by both the SPI +* controller and the SPI flash memory. +*/ + shared_mask = hwcaps->mask & params->hwcaps.mask; + +/* SPI n-n-n protocols are not supported yet. */ + ignored_mask = (SNOR_HWCAPS_READ_2_2_2 | +SNOR_HWCAPS_READ_4_4_4 | +SNOR_HWCAPS_READ_8_8_8 | +SNOR_HWCAPS_PP_4_4_4 | +SNOR_HWCAPS_PP_8_8_8 ); +if (shared_mask & ignored_mask) { +dev_dbg (nor->dev, +"SPI n-n-n protocols are not supported yet.\n" ); + shared_mask &= ~ignored_mask; + } + +/* Select the (Fast) Read command. */ + err =spi_nor_select_read (nor, params, shared_mask); +if (err) { +dev_dbg (nor->dev, +"can't select read settings supported by both the SPI controller and memory.\n" ); +return err; + } + +/* Select the Page Program command. */ + err =spi_nor_select_pp (nor, params, shared_mask); +if (err) { +dev_dbg (nor->dev, +"can't select write settings supported by both the SPI controller and memory.\n" ); +return err; + } + +/* Select the Sector Erase command. */ + err =spi_nor_select_erase (nor, info); +if (err) { +dev_dbg (nor->dev, +"can't select erase settings supported by both the SPI controller and memory.\n" ); +return err; + } + +/* Enable Quad I/O if needed. */ + enable_quad_io = (spi_nor_get_protocol_width (nor->read_proto) ==4 || +spi_nor_get_protocol_width (nor->write_proto) ==4 ); +if (enable_quad_io && params->quad_enable) + nor->quad_enable = params->quad_enable; +else + nor->quad_enable =NULL ; + +return 0 ; +} + +static int spi_nor_init (struct spi_nor *nor) +{ +int err; + +/* +* Atmel, SST, Intel/Numonyx, and others serial NOR tend to power up +* with the software protection bits set +*/ +if (JEDEC_MFR (nor->info) ==SNOR_MFR_ATMEL || +JEDEC_MFR (nor->info) ==SNOR_MFR_INTEL || +JEDEC_MFR (nor->info) ==SNOR_MFR_SST || + nor->info->flags &SPI_NOR_HAS_LOCK ) { +write_enable (nor); +write_sr (nor,0 ); +spi_nor_wait_till_ready (nor); + } + +if (nor->quad_enable) { + err = nor->quad_enable (nor); +if (err) { +dev_dbg (nor->dev,"quad mode not supported\n" ); +return err; + } + } + +if (nor->addr_width ==4 && + (JEDEC_MFR (nor->info) !=SNOR_MFR_SPANSION ) && + !(nor->info->flags &SPI_NOR_4B_OPCODES )) { +/* +* If the RESET# pin isn't hooked up properly, or the system +* otherwise doesn't perform a reset command in the boot +* sequence, it's impossible to 100% protect against unexpected +* reboots (e.g., crashes). Warn the user (or hopefully, system +* designer) that this is bad. +*/ +if (nor->flags &SNOR_F_BROKEN_RESET ) +printf ("enabling reset hack; may not recover from unexpected reboots\n" ); +set_4byte (nor, nor->info,1 ); + } + +return 0 ; +} + +int spi_nor_scan (struct spi_nor *nor) +{ +struct spi_nor_flash_parameter params; +const struct flash_info *info =NULL ; +struct mtd_info *mtd = &nor->mtd; +struct spi_nor_hwcaps hwcaps = { + .mask =SNOR_HWCAPS_READ | +SNOR_HWCAPS_READ_FAST | +SNOR_HWCAPS_PP , + }; +struct spi_slave *spi = nor->spi; +int ret; + +/* Reset SPI protocol for all commands. */ + nor->reg_proto =SNOR_PROTO_1_1_1 ; + nor->read_proto =SNOR_PROTO_1_1_1 ; + nor->write_proto =SNOR_PROTO_1_1_1 ; + nor->read = spi_nor_read_data; + nor->write = spi_nor_write_data; + nor->read_reg = spi_nor_read_reg; + nor->write_reg = spi_nor_write_reg; + +if (spi->mode &SPI_RX_QUAD ) { + hwcaps.mask |=SNOR_HWCAPS_READ_1_1_4 ; + +if (spi->mode &SPI_TX_QUAD ) + hwcaps.mask |= (SNOR_HWCAPS_READ_1_4_4 | +SNOR_HWCAPS_PP_1_1_4 | +SNOR_HWCAPS_PP_1_4_4 ); + }else if (spi->mode &SPI_RX_DUAL ) { + hwcaps.mask |=SNOR_HWCAPS_READ_1_1_2 ; + +if (spi->mode &SPI_TX_DUAL ) + hwcaps.mask |=SNOR_HWCAPS_READ_1_2_2 ; + } + + info =spi_nor_read_id (nor); +if (IS_ERR_OR_NULL (info)) +return -ENOENT ; +/* Parse the Serial Flash Discoverable Parameters table. */ + ret =spi_nor_init_params (nor, info, ¶ms); +if (ret) +return ret; + +if (!mtd->name) + mtd->name = info->name; + mtd->priv = nor; + mtd->type =MTD_NORFLASH ; + mtd->writesize =1 ; + mtd->flags =MTD_CAP_NORFLASH ; + mtd->size = params.size; + mtd->_erase = spi_nor_erase; + mtd->_read = spi_nor_read; + +#if defined(CONFIG_SPI_FLASH_STMICRO ) || defined(CONFIG_SPI_FLASH_SST ) +/* NOR protection support for STmicro/Micron chips and similar */ +if (JEDEC_MFR (info) ==SNOR_MFR_ST || +JEDEC_MFR (info) ==SNOR_MFR_MICRON || +JEDEC_MFR (info) ==SNOR_MFR_SST || + info->flags &SPI_NOR_HAS_LOCK ) { + nor->flash_lock = stm_lock; + nor->flash_unlock = stm_unlock; + nor->flash_is_locked = stm_is_locked; + } +#endif + +if (nor->flash_lock && nor->flash_unlock && nor->flash_is_locked) { + mtd->_lock = spi_nor_lock; + mtd->_unlock = spi_nor_unlock; + mtd->_is_locked = spi_nor_is_locked; + } + +#ifdef CONFIG_SPI_FLASH_SST +/* sst nor chips use AAI word program */ +if (info->flags &SST_WRITE ) + mtd->_write = sst_write; + else +#endif + mtd->_write = spi_nor_write; + +if (info->flags &USE_FSR ) + nor->flags |=SNOR_F_USE_FSR ; +if (info->flags &SPI_NOR_HAS_TB ) + nor->flags |=SNOR_F_HAS_SR_TB ; +if (info->flags &NO_CHIP_ERASE ) + nor->flags |=SNOR_F_NO_OP_CHIP_ERASE ; +if (info->flags &USE_CLSR ) + nor->flags |=SNOR_F_USE_CLSR ; + +if (info->flags &SPI_NOR_NO_ERASE ) + mtd->flags |=MTD_NO_ERASE ; + + nor->page_size = params.page_size; + mtd->writebufsize = nor->page_size; + +/* Some devices cannot do fast-read, no matter what DT tells us */ +if (info->flags &SPI_NOR_NO_FR ) + params.hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST ; + +/* +* Configure the SPI memory: +* - select op codes for (Fast) Read, Page Program and Sector Erase. +* - set the number of dummy cycles (mode cycles + wait states). +* - set the SPI protocols for register and memory accesses. +* - set the Quad Enable bit if needed (required by SPI x-y-4 protos). +*/ + ret =spi_nor_setup (nor, info, ¶ms, &hwcaps); +if (ret) +return ret; + +if (nor->addr_width) { +/* already configured from SFDP */ + }else if (info->addr_width) { + nor->addr_width = info->addr_width; + }else if (mtd->size >0x1000000 ) { +/* enable 4-byte addressing if the device exceeds 16MiB */ + nor->addr_width =4 ; +if (JEDEC_MFR (info) ==SNOR_MFR_SPANSION || + info->flags &SPI_NOR_4B_OPCODES ) +spi_nor_set_4byte_opcodes (nor, info); + }else { + nor->addr_width =3 ; + } + +if (nor->addr_width >SPI_NOR_MAX_ADDR_WIDTH ) { +dev_dbg (dev,"address width is too large: %u\n" , + nor->addr_width); +return -EINVAL ; + } + +/* Send all the required SPI flash commands to initialize device */ + nor->info = info; + ret =spi_nor_init (nor); +if (ret) +return ret; + + nor->name = mtd->name; + nor->size = mtd->size; + nor->erase_size = mtd->erasesize; + nor->sector_size = mtd->erasesize; + +#ifndef CONFIG_SPL_BUILD +printf ("SF: Detected %s with page size " , nor->name); +print_size (nor->page_size,", erase size " ); +print_size (nor->erase_size,", total " ); +print_size (nor->size,"" ); +puts ("\n" ); +#endif + +#ifndef __UBOOT__ +dev_info (dev,"%s (%lld Kbytes)\n" , info->name, + (long long )mtd->size >>10 ); + +dev_dbg (dev, +"mtd .name = %s, .size = 0x%llx (%lldMiB), " +".erasesize = 0x%.8x (%uKiB) .numeraseregions = %d\n" , + mtd->name, (long long )mtd->size, (long long )(mtd->size >>20 ), + mtd->erasesize, mtd->erasesize /1024 , mtd->numeraseregions); + +if (mtd->numeraseregions) +for (i =0 ; i < mtd->numeraseregions; i++) +dev_dbg (dev, +"mtd.eraseregions[%d] = { .offset = 0x%llx, " +".erasesize = 0x%.8x (%uKiB), " +".numblocks = %d }\n" , + i, (long long )mtd->eraseregions[i].offset, + mtd->eraseregions[i].erasesize, + mtd->eraseregions[i].erasesize /1024 , + mtd->eraseregions[i].numblocks); +#endif + +return 0 ; +} +EXPORT_SYMBOL_GPL (spi_nor_scan); + +/* U-Boot specific functions, need to extend MTD to support these */ +int spi_flash_cmd_get_sw_write_prot (struct spi_nor *nor) +{ +int sr =read_sr (nor); + +if (sr <0 ) +return sr; + +return (sr >>2 ) &7 ; +} + +MODULE_LICENSE ("GPL" ); +MODULE_AUTHOR ("Huang Shijie <[email protected]>" ); +MODULE_AUTHOR ("Mike Lavender" ); +MODULE_DESCRIPTION ("framework for SPI NOR" );
include/linux/mtd/cfi.h new file +32 -0
@@ -0,0 +1,32 @@ +// SPDX-License-Identifier: GPL-2.0 +/* +* Copyright © 2000-2010 David Woodhouse <[email protected]> et al. +* +*/ + +#ifndef __MTD_CFI_H__ +#define __MTD_CFI_H__ + +#define CFI_MFR_ANY 0xFFFF +#define CFI_ID_ANY 0xFFFF +#define CFI_MFR_CONTINUATION 0x007F + +#define CFI_MFR_AMD 0x0001 +#define CFI_MFR_AMIC 0x0037 +#define CFI_MFR_ATMEL 0x001F +#define CFI_MFR_EON 0x001C +#define CFI_MFR_FUJITSU 0x0004 +#define CFI_MFR_HYUNDAI 0x00AD +#define CFI_MFR_INTEL 0x0089 +#define CFI_MFR_MACRONIX 0x00C2 +#define CFI_MFR_NEC 0x0010 +#define CFI_MFR_PMC 0x009D +#define CFI_MFR_SAMSUNG 0x00EC +#define CFI_MFR_SHARP 0x00B0 +#define CFI_MFR_SST 0x00BF +#define CFI_MFR_ST 0x0020/* STMicroelectronics */ +#define CFI_MFR_MICRON 0x002C/* Micron */ +#define CFI_MFR_TOSHIBA 0x0098 +#define CFI_MFR_WINBOND 0x00DA + +#endif /* __MTD_CFI_H__ */
include/linux/mtd/spi-nor.h new file +421 -0
321 lines not on this page · raw message
The rest of this diff is not shown. View the raw message.
Signature · 1 line
2.19.2
Part of the diff is not shown here. View the raw message.
PATCH 5/16 mtd: spi: Port SPI NOR framework from Linux
Quoted 13 lines · Vignesh R
Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top. in order to gain 4 byte addressing support, SFDP support and a way to support SPI controllers with MMIO flash interface.
Quoted 5 lines
Signed-off-by Vignesh R <[email protected]>--- drivers/mtd/spi/spi-nor-core.c | 2647 ++++++++++++++++++++++++++++++++ include/linux/mtd/cfi.h | 32 + include/linux/mtd/spi-nor.h | 421 +++++
Please refer many mails about this comment. I don't look for carbon copy of the code from Linux, you can use the implementation and even macro names etc but the end code would be the code that require U-Boot.
- no __UBOOT ifdef
- file names in u-boot should have _ other than few uclass drivers
PATCH 5/16 mtd: spi: Port SPI NOR framework from Linux
Quoted 20 lines · Jagan Teki
Quoted 13 lines · Vignesh R
Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top. in order to gain 4 byte addressing support, SFDP support and a way to support SPI controllers with MMIO flash interface.Quoted 5 lines
Signed-off-by Vignesh R <[email protected]>--- drivers/mtd/spi/spi-nor-core.c | 2647 ++++++++++++++++++++++++++++++++ include/linux/mtd/cfi.h | 32 + include/linux/mtd/spi-nor.h | 421 +++++
Quoted 6 lines
Please refer many mails about this comment. I don't look for carbon copy of the code from Linux, you can use the implementation and even macro names etc but the end code would be the code that require U-Boot.
- no
__UBOOTifdef
What? This is the exact opposite of what we're doing in several other areas, with a large amount of success precisely because it allows us to leverage developer base to catch and fix problems. Dropping in the code and minor and obvious deviations make for easier re-sync.
Quoted 1 line
- file names in u-boot should have _ other than few uclass drivers
There is no consistent naming scheme really. I see ~1500 "_" C files and ~500 "-" files.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181212/449ece1e/attachment.sig>
PATCH 5/16 mtd: spi: Port SPI NOR framework from Linux
Quoted 27 lines · Tom Rini
Quoted 25 lines · Jagan Teki
Quoted 13 lines · Vignesh R
Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top. in order to gain 4 byte addressing support, SFDP support and a way to support SPI controllers with MMIO flash interface.Quoted 5 lines
Signed-off-by Vignesh R <[email protected]>--- drivers/mtd/spi/spi-nor-core.c | 2647 ++++++++++++++++++++++++++++++++ include/linux/mtd/cfi.h | 32 + include/linux/mtd/spi-nor.h | 421 +++++Please refer many mails about this comment. I don't look for carbon copy of the code from Linux, you can use the implementation and even macro names etc but the end code would be the code that require U-Boot.
Quoted 6 lines
Quoted 1 line
- no
__UBOOTifdefWhat? This is the exact opposite of what we're doing in several other areas, with a large amount of success precisely because it allows us to leverage developer base to catch and fix problems. Dropping in the code and minor and obvious deviations make for easier re-sync.
Several areas, but not spi-flash or spi. ie what I'm maintaining from long. I'm always looking for persistent code to be IN. May be it can't be syn-cable but we can work it more maintainable in u-boot way like other opensource project. Well this is my experience with the U-Boot project development so-far, I never ever hold any features but if u-boot need the same features, better to add then like new code.
Quoted 5 lines
Quoted 2 lines
- file names in u-boot should have _ other than few uclass drivers
There is no consistent naming scheme really. I see ~1500 "_" C files and ~500 "-" files.
I have the same experience when I rename spi_flash.c with spi-flash.c.
PATCH 5/16 mtd: spi: Port SPI NOR framework from Linux
Quoted 35 lines · Jagan Teki
Quoted 27 lines · Tom Rini
Quoted 25 lines · Jagan Teki
Quoted 13 lines · Vignesh R
Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top. in order to gain 4 byte addressing support, SFDP support and a way to support SPI controllers with MMIO flash interface.Quoted 5 lines
Signed-off-by Vignesh R <[email protected]>--- drivers/mtd/spi/spi-nor-core.c | 2647 ++++++++++++++++++++++++++++++++ include/linux/mtd/cfi.h | 32 + include/linux/mtd/spi-nor.h | 421 +++++Please refer many mails about this comment. I don't look for carbon copy of the code from Linux, you can use the implementation and even macro names etc but the end code would be the code that require U-Boot.
Quoted 6 lines
Quoted 1 line
- no
__UBOOTifdefWhat? This is the exact opposite of what we're doing in several other areas, with a large amount of success precisely because it allows us to leverage developer base to catch and fix problems. Dropping in the code and minor and obvious deviations make for easier re-sync.
Quoted 6 lines
Several areas, but not spi-flash or spi. ie what I'm maintaining from long. I'm always looking for persistent code to be IN. May be it can't be syn-cable but we can work it more maintainable in u-boot way like other opensource project. Well this is my experience with the U-Boot project development so-far, I never ever hold any features but if u-boot need the same features, better to add then like new code.
I think that for flash related SPI we should follow the lead of the rest of MTD/NAND and adapt the kernel code.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181212/827053e0/attachment.sig>
PATCH 5/16 mtd: spi: Port SPI NOR framework from Linux
Quoted 43 lines · Tom Rini
Quoted 35 lines · Jagan Teki
Quoted 27 lines · Tom Rini
Quoted 25 lines · Jagan Teki
Quoted 13 lines · Vignesh R
Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top. in order to gain 4 byte addressing support, SFDP support and a way to support SPI controllers with MMIO flash interface.Quoted 5 lines
Signed-off-by Vignesh R <[email protected]>--- drivers/mtd/spi/spi-nor-core.c | 2647 ++++++++++++++++++++++++++++++++ include/linux/mtd/cfi.h | 32 + include/linux/mtd/spi-nor.h | 421 +++++Please refer many mails about this comment. I don't look for carbon copy of the code from Linux, you can use the implementation and even macro names etc but the end code would be the code that require U-Boot.
Quoted 6 lines
Quoted 1 line
- no
__UBOOTifdefWhat? This is the exact opposite of what we're doing in several other areas, with a large amount of success precisely because it allows us to leverage developer base to catch and fix problems. Dropping in the code and minor and obvious deviations make for easier re-sync.
Quoted 6 lines
Several areas, but not spi-flash or spi. ie what I'm maintaining from long. I'm always looking for persistent code to be IN. May be it can't be syn-cable but we can work it more maintainable in u-boot way like other opensource project. Well this is my experience with the U-Boot project development so-far, I never ever hold any features but if u-boot need the same features, better to add then like new code.
Quoted 2 lines
I think that for flash related SPI we should follow the lead of the rest of MTD/NAND and adapt the kernel code.
Yes, we should have learned this lesson from the past. So full ACK from me.
Thanks,
Stefan
Vignesh R
maintainerPATCH 5/16 mtd: spi: Port SPI NOR framework from Linux
In reply to Tom RiniQuoted 43 lines · Tom Rini
Quoted 35 lines · Jagan Teki
Quoted 27 lines · Tom Rini
Quoted 25 lines · Jagan Teki
Quoted 13 lines · Vignesh R
Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top. in order to gain 4 byte addressing support, SFDP support and a way to support SPI controllers with MMIO flash interface.Quoted 5 lines
Signed-off-by Vignesh R <[email protected]>--- drivers/mtd/spi/spi-nor-core.c | 2647 ++++++++++++++++++++++++++++++++ include/linux/mtd/cfi.h | 32 + include/linux/mtd/spi-nor.h | 421 +++++Please refer many mails about this comment. I don't look for carbon copy of the code from Linux, you can use the implementation and even macro names etc but the end code would be the code that require U-Boot.
Quoted 6 lines
Quoted 1 line
- no
__UBOOTifdefWhat? This is the exact opposite of what we're doing in several other areas, with a large amount of success precisely because it allows us to leverage developer base to catch and fix problems. Dropping in the code and minor and obvious deviations make for easier re-sync.
Quoted 6 lines
Several areas, but not spi-flash or spi. ie what I'm maintaining from long. I'm always looking for persistent code to be IN. May be it can't be syn-cable but we can work it more maintainable in u-boot way like other opensource project. Well this is my experience with the U-Boot project development so-far, I never ever hold any features but if u-boot need the same features, better to add then like new code.
Quoted 3 lines
I think that for flash related SPI we should follow the lead of the rest of MTD/NAND and adapt the kernel code.
I have no hard preference, although I prefer MTD conventions wrt __UBOOT__ and file names as this code resides under drivers/mtd/.
Signature · 2 lines
Regards Vignesh
Vignesh R
maintainerPATCH 6/16 mtd: spi: Switch to new SPI NOR framework
In reply to Vignesh RSwitch spi_flash_* interfaces to call into new SPI NOR framework via MTD layer. Fix up sf_dataflash to work in legacy way. And update sandbox to use new interfaces/defintions
--- common/spl/Kconfig | 12 +- drivers/mtd/spi/Kconfig | 15 ++- drivers/mtd/spi/Makefile | 4 +- drivers/mtd/spi/sandbox.c | 36 +++--- drivers/mtd/spi/sf_dataflash.c | 11 +- drivers/mtd/spi/sf_internal.h | 228 +++++++-------------------------- drivers/mtd/spi/sf_probe.c | 33 +++-- drivers/mtd/spi/spi-nor-core.c | 59 +-------- drivers/spi/stm32_qspi.c | 4 +- include/spi_flash.h | 105 ++++----------- 10 files changed, 137 insertions(+), 370 deletions(-)
common/spl/Kconfig +11 -1
@@ -727,13 +727,23 @@ config SPL_SPI_FLASH_SUPPORT lines). This enables the drivers in drivers/mtd/spi as part of an SPL build. This normally requires SPL_SPI_SUPPORT. +if SPL_SPI_FLASH_SUPPORT + +config SPL_SPI_FLASH_SFDP_SUPPORT + bool "SFDP table parsing support for SPI NOR flashes" + help + Enable support for parsing and auto discovery of parameters for + SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP) + tables as per JESD216 standard in SPL. + config SPL_SPI_LOAD bool "Support loading from SPI flash" - depends on SPL_SPI_FLASH_SUPPORT help Enable support for loading next stage, U-Boot or otherwise, from SPI NOR in U-Boot SPL. +endif # SPL_SPI_FLASH_SUPPORT + config SPL_SPI_SUPPORT bool "Support SPI drivers" help
drivers/mtd/spi/Kconfig +11 -4
@@ -27,6 +27,8 @@ config SPI_FLASH_SANDBOX config SPI_FLASH bool "Legacy SPI Flash Interface support" + depends on SPI + select SPI_MEM help Enable the legacy SPI flash support. This will include basic standard support for things like probing, read / write, and
@@ -34,9 +36,17 @@ config SPI_FLASH If unsure, say N +if SPI_FLASH + +config SPI_FLASH_SFDP_SUPPORT + bool "SFDP table parsing support for SPI NOR flashes" + help + Enable support for parsing and auto discovery of parameters for + SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP) + tables as per JESD216 standard. + config SPI_FLASH_BAR bool "SPI flash Bank/Extended address register support" - depends on SPI_FLASH help Enable the SPI flash Bank/Extended address register support. Bank/Extended address registers are used to access the flash
@@ -44,13 +54,10 @@ config SPI_FLASH_BAR config SF_DUAL_FLASH bool "SPI DUAL flash memory support" - depends on SPI_FLASH help Enable this option to support two flash memories connected to a single controller. Currently Xilinx Zynq qspi supports this. -if SPI_FLASH - config SPI_FLASH_ATMEL bool "Atmel SPI flash support" help
drivers/mtd/spi/Makefile +2 -2
@@ -9,7 +9,7 @@ ifdef CONFIG_SPL_BUILD obj-$(CONFIG_SPL_SPI_BOOT) += fsl_espi_spl.o endif -obj-$(CONFIG_SPI_FLASH) += sf_probe.o spi_flash.o spi_flash_ids.o sf.o -obj-$(CONFIG_SPI_FLASH_DATAFLASH) += sf_dataflash.o +obj-$(CONFIG_SPI_FLASH) += sf_probe.o spi-nor-core.o +obj-$(CONFIG_SPI_FLASH_DATAFLASH) += sf_dataflash.o sf.o obj-$(CONFIG_SPI_FLASH_MTD) += sf_mtd.o obj-$(CONFIG_SPI_FLASH_SANDBOX) += sandbox.o
drivers/mtd/spi/sandbox.c +18 -18
@@ -92,7 +92,7 @@ struct sandbox_spi_flash {/* The current flash status (see STAT_XXX defines above) */ u16 status;/* Data describing the flash we're emulating */ -const struct spi_flash_info *data; +const struct flash_info *data;/* The file on disk to serv up data from */ int fd; };
@@ -122,7 +122,7 @@ static int sandbox_sf_probe(struct udevice *dev)/* spec = idcode:file */ struct sandbox_spi_flash *sbsf =dev_get_priv (dev);size_t len, idname_len; -const struct spi_flash_info *data; +const struct flash_info *data;struct sandbox_spi_flash_plat_data *pdata =dev_get_platdata (dev);struct sandbox_state *state =state_get_current ();struct dm_spi_slave_platdata *slave_plat;
@@ -155,7 +155,7 @@ static int sandbox_sf_probe(struct udevice *dev) idname_len =strlen (spec);debug ("%s: device='%s'\n" , __func__, spec); -for (data = spi_flash_ids; data->name; data++) { +for (data = spi_nor_ids; data->name; data++) { len =strlen (data->name);if (idname_len != len)continue ;
@@ -243,43 +243,43 @@ static int sandbox_sf_process_cmd(struct sandbox_spi_flash *sbsf, const u8 *rx, sbsf->cmd = rx[0 ];switch (sbsf->cmd) { -case CMD_READ_ID : +case SPINOR_OP_RDID : sbsf->state =SF_ID ; sbsf->cmd =SF_ID ;break ; -case CMD_READ_ARRAY_FAST : +case SPINOR_OP_READ_FAST : sbsf->pad_addr_bytes =1 ; -case CMD_READ_ARRAY_SLOW : -case CMD_PAGE_PROGRAM : +case SPINOR_OP_READ : +case SPINOR_OP_PP : sbsf->state =SF_ADDR ;break ; -case CMD_WRITE_DISABLE : +case SPINOR_OP_WRDI :debug (" write disabled\n" ); sbsf->status &= ~STAT_WEL ;break ; -case CMD_READ_STATUS : +case SPINOR_OP_RDSR : sbsf->state =SF_READ_STATUS ;break ; -case CMD_READ_STATUS1 : +case SPINOR_OP_RDSR2 : sbsf->state =SF_READ_STATUS1 ;break ; -case CMD_WRITE_ENABLE : +case SPINOR_OP_WREN :debug (" write enabled\n" ); sbsf->status |=STAT_WEL ;break ; -case CMD_WRITE_STATUS : +case SPINOR_OP_WRSR : sbsf->state =SF_WRITE_STATUS ;break ;default : {int flags = sbsf->data->flags;/* we only support erase here */ -if (sbsf->cmd ==CMD_ERASE_CHIP ) { +if (sbsf->cmd ==SPINOR_OP_CHIP_ERASE ) { sbsf->erase_size = sbsf->data->sector_size * sbsf->data->n_sectors; - }else if (sbsf->cmd ==CMD_ERASE_4K && (flags &SECT_4K )) { + }else if (sbsf->cmd ==SPINOR_OP_BE_4K && (flags &SECT_4K )) { sbsf->erase_size =4 <<10 ; - }else if (sbsf->cmd ==CMD_ERASE_64K && !(flags &SECT_4K )) { + }else if (sbsf->cmd ==SPINOR_OP_SE && !(flags &SECT_4K )) { sbsf->erase_size =64 <<10 ; }else {debug (" cmd unknown: %#x\n" , sbsf->cmd);
@@ -380,11 +380,11 @@ static int sandbox_sf_xfer(struct udevice *dev, unsigned int bitlen,return -EIO ; }switch (sbsf->cmd) { -case CMD_READ_ARRAY_FAST : -case CMD_READ_ARRAY_SLOW : +case SPINOR_OP_READ_FAST : +case SPINOR_OP_READ : sbsf->state =SF_READ ;break ; -case CMD_PAGE_PROGRAM : +case SPINOR_OP_PP : sbsf->state =SF_WRITE ;break ;default :
drivers/mtd/spi/sf_dataflash.c +6 -5
@@ -18,6 +18,7 @@#include "sf_internal.h" +#define CMD_READ_ID 0x9f/* reads can bypass the buffers */ #define OP_READ_CONTINUOUS 0xE8#define OP_READ_PAGE 0xD2
@@ -441,7 +442,7 @@ static int add_dataflash(struct udevice *dev, char *name, int nr_pages,return 0 ; } -struct flash_info { +struct data_flash_info {char *name;/*
@@ -460,7 +461,7 @@ struct flash_info {#define IS_POW2PS 0x0001/* uses 2^N byte pages */ }; -static struct flash_info dataflash_data[] = { +static struct data_flash_info dataflash_data[] = {/* * NOTE: chips with SUP_POW2PS (rev D and up) need two entries, * one with IS_POW2PS and the other without. The entry with the
@@ -501,12 +502,12 @@ static struct flash_info dataflash_data[] = { { "at45db642d", 0x1f2800, 8192, 1024, 10, SUP_POW2PS | IS_POW2PS}, }; -static struct flash_info *jedec_probe (struct spi_slave *spi) +static struct data_flash_info *jedec_probe (struct spi_slave *spi) {int tmp;uint8_t id[5 ];uint32_t jedec; -struct flash_info *info; +struct data_flash_info *info;int status;/*
@@ -583,7 +584,7 @@ static int spi_dataflash_probe(struct udevice *dev) {struct spi_slave *spi =dev_get_parent_priv (dev);struct spi_flash *spi_flash; -struct flash_info *info; +struct data_flash_info *info;int status; spi_flash =dev_get_uclass_priv (dev);
drivers/mtd/spi/sf_internal.h +43 -185
263 lines not on this page · raw message
drivers/mtd/spi/sf_probe.c +20 -13
@@ -40,7 +40,7 @@ static int spi_flash_probe_slave(struct spi_flash *flash)return ret; } - ret =spi_flash_scan (flash); + ret =spi_nor_scan (flash);if (ret) goto err_read_id;
@@ -96,32 +96,38 @@ static int spi_flash_std_read(struct udevice *dev, u32 offset, size_t len, void *buf) {struct spi_flash *flash =dev_get_uclass_priv (dev); +struct mtd_info *mtd = &flash->mtd; +size_t retlen; -return log_ret (spi_flash_cmd_read_ops (flash, offset, len, buf)); +return log_ret (mtd->_read (mtd, offset, len, &retlen, buf)); }static int spi_flash_std_write (struct udevice *dev,u32 offset,size_t len,const void *buf) {struct spi_flash *flash =dev_get_uclass_priv (dev); +struct mtd_info *mtd = &flash->mtd; +size_t retlen; -#if defined(CONFIG_SPI_FLASH_SST ) -if (flash->flags &SNOR_F_SST_WR ) { -if (flash->spi->mode &SPI_TX_BYTE ) -return sst_write_bp (flash, offset, len, buf); -else -return sst_write_wp (flash, offset, len, buf); - } -#endif - -return spi_flash_cmd_write_ops (flash, offset, len, buf); +return mtd->_write (mtd, offset, len, &retlen, buf); }static int spi_flash_std_erase (struct udevice *dev,u32 offset,size_t len) {struct spi_flash *flash =dev_get_uclass_priv (dev); +struct mtd_info *mtd = &flash->mtd; +struct erase_info instr; + +if (offset % mtd->erasesize || len % mtd->erasesize) { +printf ("SF: Erase offset/length not multiple of erase size\n" ); +return -EINVAL ; + } + +memset (&instr,0 ,sizeof (instr)); + instr.addr = offset; + instr.len = len; -return spi_flash_cmd_erase_ops (flash, offset, len); +return mtd->_erase (mtd, &instr); }static int spi_flash_std_get_sw_write_prot (struct udevice *dev)
@@ -161,6 +167,7 @@ static const struct dm_spi_flash_ops spi_flash_std_ops = {static const struct udevice_id spi_flash_std_ids[] = { { .compatible ="spi-flash" }, + { .compatible ="jedec,spi-nor" }, { } };
drivers/mtd/spi/spi-nor-core.c +2 -57
71 lines not on this page · raw message
drivers/spi/stm32_qspi.c +2 -2
@@ -271,9 +271,9 @@ static void _stm32_qspi_enable_mmap(struct stm32_qspi_priv *priv, {unsigned int ccr_reg; - priv->command = flash->read_cmd |CMD_HAS_ADR |CMD_HAS_DATA + priv->command = flash->read_opcode |CMD_HAS_ADR |CMD_HAS_DATA |CMD_HAS_DUMMY ; - priv->dummycycles = flash->dummy_byte *8 ; + priv->dummycycles = flash->read_dummy; ccr_reg =_stm32_qspi_gen_ccr (priv,STM32_QSPI_CCR_MEM_MAP );
include/spi_flash.h +22 -83
133 lines not on this page · raw message
Signature · 1 line
2.19.2
Vignesh R
maintainerPATCH 7/16 mtd: spi: Remove unused files
In reply to Vignesh Rspi_flash and spi_flash_ids are no longer needed after SPI NOR migration. Remove them.
--- drivers/mtd/spi/spi_flash.c | 1337 ------------------------------- drivers/mtd/spi/spi_flash_ids.c | 211 ----- 2 files changed, 1548 deletions(-) delete mode 100644 drivers/mtd/spi/spi_flash.c delete mode 100644 drivers/mtd/spi/spi_flash_ids.c
drivers/mtd/spi/spi_flash.c deleted +0 -1337
@@ -1,1337 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0+ -/* -* SPI Flash Core -* -* Copyright (C) 2015 Jagan Teki <[email protected]> -* Copyright (C) 2013 Jagannadha Sutradharudu Teki, Xilinx Inc. -* Copyright (C) 2010 Reinhard Meyer, EMK Elektronik -* Copyright (C) 2008 Atmel Corporation -*/ - -#include <common.h> -#include <errno.h> -#include <malloc.h> -#include <mapmem.h> -#include <spi.h> -#include <spi_flash.h> -#include <linux/log2.h> -#include <linux/sizes.h> -#include <dma.h> - -#include "sf_internal.h" - -static void spi_flash_addr (u32 addr,u8 *cmd) -{ -/* cmd[0] is actual command */ - cmd[1 ] = addr >>16 ; - cmd[2 ] = addr >>8 ; - cmd[3 ] = addr >>0 ; -} - -static int read_sr (struct spi_flash *flash,u8 *rs) -{ -int ret; -u8 cmd; - - cmd =CMD_READ_STATUS ; - ret =spi_flash_read_common (flash, &cmd,1 , rs,1 ); -if (ret <0 ) { -debug ("SF: fail to read status register\n" ); -return ret; - } - -return 0 ; -} - -static int read_fsr (struct spi_flash *flash,u8 *fsr) -{ -int ret; -const u8 cmd =CMD_FLAG_STATUS ; - - ret =spi_flash_read_common (flash, &cmd,1 , fsr,1 ); -if (ret <0 ) { -debug ("SF: fail to read flag status register\n" ); -return ret; - } - -return 0 ; -} - -static int write_sr (struct spi_flash *flash,u8 ws) -{ -u8 cmd; -int ret; - - cmd =CMD_WRITE_STATUS ; - ret =spi_flash_write_common (flash, &cmd,1 , &ws,1 ); -if (ret <0 ) { -debug ("SF: fail to write status register\n" ); -return ret; - } - -return 0 ; -} - -#if defined(CONFIG_SPI_FLASH_SPANSION ) || defined(CONFIG_SPI_FLASH_WINBOND ) -static int read_cr (struct spi_flash *flash,u8 *rc) -{ -int ret; -u8 cmd; - - cmd =CMD_READ_CONFIG ; - ret =spi_flash_read_common (flash, &cmd,1 , rc,1 ); -if (ret <0 ) { -debug ("SF: fail to read config register\n" ); -return ret; - } - -return 0 ; -} - -static int write_cr (struct spi_flash *flash,u8 wc) -{ -u8 data[2 ]; -u8 cmd; -int ret; - - ret =read_sr (flash, &data[0 ]); -if (ret <0 ) -return ret; - - cmd =CMD_WRITE_STATUS ; - data[1 ] = wc; - ret =spi_flash_write_common (flash, &cmd,1 , &data,2 ); -if (ret) { -debug ("SF: fail to write config register\n" ); -return ret; - } - -return 0 ; -} -#endif - -int spi_flash_cmd_get_sw_write_prot (struct spi_flash *flash) -{ -u8 status; -int ret; - - ret =read_sr (flash, &status); -if (ret) -return ret; - -return (status >>2 ) &7 ; -} - -#ifdef CONFIG_SPI_FLASH_BAR -/* -* This "clean_bar" is necessary in a situation when one was accessing -* spi flash memory > 16 MiB by using Bank Address Register's BA24 bit. -* -* After it the BA24 bit shall be cleared to allow access to correct -* memory region after SW reset (by calling "reset" command). -* -* Otherwise, the BA24 bit may be left set and then after reset, the -* ROM would read/write/erase SPL from 16 MiB * bank_sel address. -*/ -static int clean_bar (struct spi_flash *flash) -{ -u8 cmd, bank_sel =0 ; - -if (flash->bank_curr ==0 ) -return 0 ; - cmd = flash->bank_write_cmd; - flash->bank_curr =0 ; - -return spi_flash_write_common (flash, &cmd,1 , &bank_sel,1 ); -} - -static int write_bar (struct spi_flash *flash,u32 offset) -{ -u8 cmd, bank_sel; -int ret; - - bank_sel = offset / (SPI_FLASH_16MB_BOUN << flash->shift); -if (bank_sel == flash->bank_curr) - goto bar_end; - - cmd = flash->bank_write_cmd; - ret =spi_flash_write_common (flash, &cmd,1 , &bank_sel,1 ); -if (ret <0 ) { -debug ("SF: fail to write bank register\n" ); -return ret; - } - -bar_end: - flash->bank_curr = bank_sel; -return flash->bank_curr; -} - -static int read_bar (struct spi_flash *flash,const struct spi_flash_info *info) -{ -u8 curr_bank =0 ; -int ret; - -if (flash->size <=SPI_FLASH_16MB_BOUN ) - goto bar_end; - -switch (JEDEC_MFR (info)) { -case SPI_FLASH_CFI_MFR_SPANSION : - flash->bank_read_cmd =CMD_BANKADDR_BRRD ; - flash->bank_write_cmd =CMD_BANKADDR_BRWR ; -break ; -default : - flash->bank_read_cmd =CMD_EXTNADDR_RDEAR ; - flash->bank_write_cmd =CMD_EXTNADDR_WREAR ; - } - - ret =spi_flash_read_common (flash, &flash->bank_read_cmd,1 , - &curr_bank,1 ); -if (ret) { -debug ("SF: fail to read bank addr register\n" ); -return ret; - } - -bar_end: - flash->bank_curr = curr_bank; -return 0 ; -} -#endif - -#ifdef CONFIG_SF_DUAL_FLASH -static void spi_flash_dual (struct spi_flash *flash,u32 *addr) -{ -switch (flash->dual_flash) { -case SF_DUAL_STACKED_FLASH : -if (*addr >= (flash->size >>1 )) { - *addr -= flash->size >>1 ; - flash->flags |=SNOR_F_USE_UPAGE ; - }else { - flash->flags &= ~SNOR_F_USE_UPAGE ; - } -break ; -case SF_DUAL_PARALLEL_FLASH : - *addr >>= flash->shift; -break ; -default : -debug ("SF: Unsupported dual_flash=%d\n" , flash->dual_flash); -break ; - } -} -#endif - -static int spi_flash_sr_ready (struct spi_flash *flash) -{ -u8 sr; -int ret; - - ret =read_sr (flash, &sr); -if (ret <0 ) -return ret; - -return !(sr &STATUS_WIP ); -} - -static int spi_flash_fsr_ready (struct spi_flash *flash) -{ -u8 fsr; -int ret; - - ret =read_fsr (flash, &fsr); -if (ret <0 ) -return ret; - -return fsr &STATUS_PEC ; -} - -static int spi_flash_ready (struct spi_flash *flash) -{ -int sr, fsr; - - sr =spi_flash_sr_ready (flash); -if (sr <0 ) -return sr; - - fsr =1 ; -if (flash->flags &SNOR_F_USE_FSR ) { - fsr =spi_flash_fsr_ready (flash); -if (fsr <0 ) -return fsr; - } - -return sr && fsr; -} - -static int spi_flash_wait_till_ready (struct spi_flash *flash, -unsigned long timeout) -{ -unsigned long timebase; -int ret; - - timebase =get_timer (0 ); - -while (get_timer (timebase) < timeout) { - ret =spi_flash_ready (flash); -if (ret <0 ) -return ret; -if (ret) -return 0 ; - } - -printf ("SF: Timeout!\n" ); - -return -ETIMEDOUT ; -} - -int spi_flash_write_common (struct spi_flash *flash,const u8 *cmd, -size_t cmd_len,const void *buf,size_t buf_len) -{ -struct spi_slave *spi = flash->spi; -unsigned long timeout =SPI_FLASH_PROG_TIMEOUT ; -int ret; - -if (buf ==NULL ) - timeout =SPI_FLASH_PAGE_ERASE_TIMEOUT ; - - ret =spi_claim_bus (spi); -if (ret) { -debug ("SF: unable to claim SPI bus\n" ); -return ret; - } - - ret =spi_flash_cmd_write_enable (flash); -if (ret <0 ) { -debug ("SF: enabling write failed\n" ); -return ret; - } - - ret =spi_flash_cmd_write (spi, cmd, cmd_len, buf, buf_len); -if (ret <0 ) { -debug ("SF: write cmd failed\n" ); -return ret; - } - - ret =spi_flash_wait_till_ready (flash, timeout); -if (ret <0 ) { -debug ("SF: write %s timed out\n" , - timeout ==SPI_FLASH_PROG_TIMEOUT ? -"program" :"page erase" ); -return ret; - } - -spi_release_bus (spi); - -return ret; -} - -int spi_flash_cmd_erase_ops (struct spi_flash *flash,u32 offset,size_t len) -{ -u32 erase_size, erase_addr; -u8 cmd[SPI_FLASH_CMD_LEN ]; -int ret =-1 ; - - erase_size = flash->erase_size; -if (offset % erase_size || len % erase_size) { -printf ("SF: Erase offset/length not multiple of erase size\n" ); -return -1 ; - } - -if (flash->flash_is_locked) { -if (flash->flash_is_locked (flash, offset, len) >0 ) { -printf ("offset 0x%x is protected and cannot be erased\n" , - offset); -return -EINVAL ; - } - } - - cmd[0 ] = flash->erase_cmd; -while (len) { - erase_addr = offset; - -#ifdef CONFIG_SF_DUAL_FLASH -if (flash->dual_flash >SF_SINGLE_FLASH ) -spi_flash_dual (flash, &erase_addr); -#endif -#ifdef CONFIG_SPI_FLASH_BAR - ret =write_bar (flash, erase_addr); -if (ret <0 ) -return ret; -#endif -spi_flash_addr (erase_addr, cmd); - -debug ("SF: erase %2x %2x %2x %2x (%x)\n" , cmd[0 ], cmd[1 ], - cmd[2 ], cmd[3 ], erase_addr); - - ret =spi_flash_write_common (flash, cmd,sizeof (cmd),NULL ,0 ); -if (ret <0 ) { -debug ("SF: erase failed\n" ); -break ; - } - - offset += erase_size; - len -= erase_size; - } - -#ifdef CONFIG_SPI_FLASH_BAR - ret =clean_bar (flash); -#endif - -return ret; -} - -int spi_flash_cmd_write_ops (struct spi_flash *flash,u32 offset, -size_t len,const void *buf) -{ -struct spi_slave *spi = flash->spi; -unsigned long byte_addr, page_size; -u32 write_addr; -size_t chunk_len, actual; -u8 cmd[SPI_FLASH_CMD_LEN ]; -int ret =-1 ; - - page_size = flash->page_size; - -if (flash->flash_is_locked) { -if (flash->flash_is_locked (flash, offset, len) >0 ) { -printf ("offset 0x%x is protected and cannot be written\n" , - offset); -return -EINVAL ; - } - } - - cmd[0 ] = flash->write_cmd; -for (actual =0 ; actual < len; actual += chunk_len) { - write_addr = offset; - -#ifdef CONFIG_SF_DUAL_FLASH -if (flash->dual_flash >SF_SINGLE_FLASH ) -spi_flash_dual (flash, &write_addr); -#endif -#ifdef CONFIG_SPI_FLASH_BAR - ret =write_bar (flash, write_addr); -if (ret <0 ) -return ret; -#endif - byte_addr = offset % page_size; - chunk_len =min (len - actual, (size_t )(page_size - byte_addr)); - -if (spi->max_write_size) - chunk_len =min (chunk_len, - spi->max_write_size -sizeof (cmd)); - -spi_flash_addr (write_addr, cmd); - -debug ("SF: 0x%p => cmd = { 0x%02x 0x%02x%02x%02x } chunk_len = %zu\n" , - buf + actual, cmd[0 ], cmd[1 ], cmd[2 ], cmd[3 ], chunk_len); - - ret =spi_flash_write_common (flash, cmd,sizeof (cmd), - buf + actual, chunk_len); -if (ret <0 ) { -debug ("SF: write failed\n" ); -break ; - } - - offset += chunk_len; - } - -#ifdef CONFIG_SPI_FLASH_BAR - ret =clean_bar (flash); -#endif - -return ret; -} - -int spi_flash_read_common (struct spi_flash *flash,const u8 *cmd, -size_t cmd_len,void *data,size_t data_len) -{ -struct spi_slave *spi = flash->spi; -int ret; - - ret =spi_claim_bus (spi); -if (ret) { -debug ("SF: unable to claim SPI bus\n" ); -return ret; - } - - ret =spi_flash_cmd_read (spi, cmd, cmd_len, data, data_len); -if (ret <0 ) { -debug ("SF: read cmd failed\n" ); -return ret; - } - -spi_release_bus (spi); - -return ret; -} - -/* -* TODO: remove the weak after all the other spi_flash_copy_mmap -* implementations removed from drivers -*/ -void __weak spi_flash_copy_mmap (void *data,void *offset,size_t len) -{ -#ifdef CONFIG_DMA -if (!dma_memcpy (data, offset, len)) -return ; -#endif -memcpy (data, offset, len); -} - -int spi_flash_cmd_read_ops (struct spi_flash *flash,u32 offset, -size_t len,void *data) -{ -struct spi_slave *spi = flash->spi; -u8 cmdsz; -u32 remain_len, read_len, read_addr; -int bank_sel =0 ; -int ret =0 ; - -/* Handle memory-mapped SPI */ -if (flash->memory_map) { - ret =spi_claim_bus (spi); -if (ret) { -debug ("SF: unable to claim SPI bus\n" ); -return log_ret (ret); - } -spi_xfer (spi,0 ,NULL ,NULL ,SPI_XFER_MMAP ); -spi_flash_copy_mmap (data, flash->memory_map + offset, len); -spi_xfer (spi,0 ,NULL ,NULL ,SPI_XFER_MMAP_END ); -spi_release_bus (spi); -return 0 ; - } - - cmdsz =SPI_FLASH_CMD_LEN + flash->dummy_byte; -u8 cmd[cmdsz]; - - cmd[0 ] = flash->read_cmd; -while (len) { - read_addr = offset; - -#ifdef CONFIG_SF_DUAL_FLASH -if (flash->dual_flash >SF_SINGLE_FLASH ) -spi_flash_dual (flash, &read_addr); -#endif -#ifdef CONFIG_SPI_FLASH_BAR - ret =write_bar (flash, read_addr); -if (ret <0 ) -return log_ret (ret); - bank_sel = flash->bank_curr; -#endif - remain_len = ((SPI_FLASH_16MB_BOUN << flash->shift) * - (bank_sel +1 )) - offset; -if (len < remain_len) - read_len = len; -else - read_len = remain_len; - -if (spi->max_read_size) - read_len =min (read_len, spi->max_read_size); - -spi_flash_addr (read_addr, cmd); - - ret =spi_flash_read_common (flash, cmd, cmdsz, data, read_len); -if (ret <0 ) { -debug ("SF: read failed\n" ); -break ; - } - - offset += read_len; - len -= read_len; - data += read_len; - } - -#ifdef CONFIG_SPI_FLASH_BAR - ret =clean_bar (flash); -#endif - -return log_ret (ret); -} - -#ifdef CONFIG_SPI_FLASH_SST -static bool sst26_process_bpr (u32 bpr_size,u8 *cmd,u32 bit,enum lock_ctl ctl) -{ -switch (ctl) { -case SST26_CTL_LOCK : - cmd[bpr_size - (bit /8 ) -1 ] |=BIT (bit %8 ); -break ; -case SST26_CTL_UNLOCK : - cmd[bpr_size - (bit /8 ) -1 ] &= ~BIT (bit %8 ); -break ; -case SST26_CTL_CHECK : -return !!(cmd[bpr_size - (bit /8 ) -1 ] &BIT (bit %8 )); - } - -return false; -} - -/* -* sst26wf016/sst26wf032/sst26wf064 have next block protection: -* 4x - 8 KByte blocks - read & write protection bits - upper addresses -* 1x - 32 KByte blocks - write protection bits -* rest - 64 KByte blocks - write protection bits -* 1x - 32 KByte blocks - write protection bits -* 4x - 8 KByte blocks - read & write protection bits - lower addresses -* -* We'll support only per 64k lock/unlock so lower and upper 64 KByte region -* will be treated as single block. -*/ - -/* -* Lock, unlock or check lock status of the flash region of the flash (depending -* on the lock_ctl value) -*/ -static int sst26_lock_ctl (struct spi_flash *flash,u32 ofs,size_t len,enum lock_ctl ctl) -{ -u32 i, bpr_ptr, rptr_64k, lptr_64k, bpr_size; -bool lower_64k = false, upper_64k = false; -u8 cmd, bpr_buff[SST26_MAX_BPR_REG_LEN ] = {}; -int ret; - -/* Check length and offset for 64k alignment */ -if ((ofs & (SZ_64K -1 )) || (len & (SZ_64K -1 ))) -return -EINVAL ; - -if (ofs + len > flash->size) -return -EINVAL ; - -/* SST26 family has only 16 Mbit, 32 Mbit and 64 Mbit IC */ -if (flash->size !=SZ_2M && - flash->size !=SZ_4M && - flash->size !=SZ_8M ) -return -EINVAL ; - - bpr_size =2 + (flash->size /SZ_64K /8 ); - - cmd =SST26_CMD_READ_BPR ; - ret =spi_flash_read_common (flash, &cmd,1 , bpr_buff, bpr_size); -if (ret <0 ) { -printf ("SF: fail to read block-protection register\n" ); -return ret; - } - - rptr_64k =min_t (u32, ofs + len , flash->size -SST26_BOUND_REG_SIZE ); - lptr_64k =max_t (u32, ofs,SST26_BOUND_REG_SIZE ); - - upper_64k = ((ofs + len) > (flash->size -SST26_BOUND_REG_SIZE )); - lower_64k = (ofs <SST26_BOUND_REG_SIZE ); - -/* Lower bits in block-protection register are about 64k region */ - bpr_ptr = lptr_64k /SZ_64K -1 ; - -/* Process 64K blocks region */ -while (lptr_64k < rptr_64k) { -if (sst26_process_bpr (bpr_size, bpr_buff, bpr_ptr, ctl)) -return EACCES ; - - bpr_ptr++; - lptr_64k +=SZ_64K ; - } - -/* 32K and 8K region bits in BPR are after 64k region bits */ - bpr_ptr = (flash->size -2 *SST26_BOUND_REG_SIZE ) /SZ_64K ; - -/* Process lower 32K block region */ -if (lower_64k) -if (sst26_process_bpr (bpr_size, bpr_buff, bpr_ptr, ctl)) -return EACCES ; - - bpr_ptr++; - -/* Process upper 32K block region */ -if (upper_64k) -if (sst26_process_bpr (bpr_size, bpr_buff, bpr_ptr, ctl)) -return EACCES ; - - bpr_ptr++; - -/* Process lower 8K block regions */ -for (i =0 ; i <SST26_BPR_8K_NUM ; i++) { -if (lower_64k) -if (sst26_process_bpr (bpr_size, bpr_buff, bpr_ptr, ctl)) -return EACCES ; - -/* In 8K area BPR has both read and write protection bits */ - bpr_ptr +=2 ; - } - -/* Process upper 8K block regions */ -for (i =0 ; i <SST26_BPR_8K_NUM ; i++) { -if (upper_64k) -if (sst26_process_bpr (bpr_size, bpr_buff, bpr_ptr, ctl)) -return EACCES ; - -/* In 8K area BPR has both read and write protection bits */ - bpr_ptr +=2 ; - } - -/* If we check region status we don't need to write BPR back */ -if (ctl ==SST26_CTL_CHECK ) -return 0 ; - - cmd =SST26_CMD_WRITE_BPR ; - ret =spi_flash_write_common (flash, &cmd,1 , bpr_buff, bpr_size); -if (ret <0 ) { -printf ("SF: fail to write block-protection register\n" ); -return ret; - } - -return 0 ; -} - -static int sst26_unlock (struct spi_flash *flash,u32 ofs,size_t len) -{ -return sst26_lock_ctl (flash, ofs, len,SST26_CTL_UNLOCK ); -} - -static int sst26_lock (struct spi_flash *flash,u32 ofs,size_t len) -{ -return sst26_lock_ctl (flash, ofs, len,SST26_CTL_LOCK ); -} - -/* -* Returns EACCES (positive value) if region is locked, 0 if region is unlocked, -* and negative on errors. -*/ -static int sst26_is_locked (struct spi_flash *flash,u32 ofs,size_t len) -{ -/* -* is_locked function is used for check before reading or erasing flash -* region, so offset and length might be not 64k allighned, so adjust -* them to be 64k allighned as sst26_lock_ctl works only with 64k -* allighned regions. -*/ - ofs -= ofs & (SZ_64K -1 ); - len = len & (SZ_64K -1 ) ? (len & ~(SZ_64K -1 )) +SZ_64K : len; - -return sst26_lock_ctl (flash, ofs, len,SST26_CTL_CHECK ); -} - -static int sst_byte_write (struct spi_flash *flash,u32 offset,const void *buf) -{ -struct spi_slave *spi = flash->spi; -int ret; -u8 cmd[4 ] = { -CMD_SST_BP , - offset >>16 , - offset >>8 , - offset, - }; - -debug ("BP[%02x]: 0x%p => cmd = { 0x%02x 0x%06x }\n" , -spi_w8r8 (spi,CMD_READ_STATUS ), buf, cmd[0 ], offset); - - ret =spi_flash_cmd_write_enable (flash); -if (ret) -return ret; - - ret =spi_flash_cmd_write (spi, cmd,sizeof (cmd), buf,1 ); -if (ret) -return ret; - -return spi_flash_wait_till_ready (flash,SPI_FLASH_PROG_TIMEOUT ); -} - -int sst_write_wp (struct spi_flash *flash,u32 offset,size_t len, -const void *buf) -{ -struct spi_slave *spi = flash->spi; -size_t actual, cmd_len; -int ret; -u8 cmd[4 ]; - - ret =spi_claim_bus (spi); -if (ret) { -debug ("SF: Unable to claim SPI bus\n" ); -return ret; - } - -/* If the data is not word aligned, write out leading single byte */ - actual = offset %2 ; -if (actual) { - ret =sst_byte_write (flash, offset, buf); -if (ret) - goto done; - } - offset += actual; - - ret =spi_flash_cmd_write_enable (flash); -if (ret) - goto done; - - cmd_len =4 ; - cmd[0 ] =CMD_SST_AAI_WP ; - cmd[1 ] = offset >>16 ; - cmd[2 ] = offset >>8 ; - cmd[3 ] = offset; - -for (; actual < len -1 ; actual +=2 ) { -debug ("WP[%02x]: 0x%p => cmd = { 0x%02x 0x%06x }\n" , -spi_w8r8 (spi,CMD_READ_STATUS ), buf + actual, - cmd[0 ], offset); - - ret =spi_flash_cmd_write (spi, cmd, cmd_len, - buf + actual,2 ); -if (ret) { -debug ("SF: sst word program failed\n" ); -break ; - } - - ret =spi_flash_wait_till_ready (flash,SPI_FLASH_PROG_TIMEOUT ); -if (ret) -break ; - - cmd_len =1 ; - offset +=2 ; - } - -if (!ret) - ret =spi_flash_cmd_write_disable (flash); - -/* If there is a single trailing byte, write it out */ -if (!ret && actual != len) - ret =sst_byte_write (flash, offset, buf + actual); - - done: -debug ("SF: sst: program %s %zu bytes @ 0x%zx\n" , - ret ?"failure" :"success" , len, offset - actual); - -spi_release_bus (spi); -return ret; -} - -int sst_write_bp (struct spi_flash *flash,u32 offset,size_t len, -const void *buf) -{ -struct spi_slave *spi = flash->spi; -size_t actual; -int ret; - - ret =spi_claim_bus (spi); -if (ret) { -debug ("SF: Unable to claim SPI bus\n" ); -return ret; - } - -for (actual =0 ; actual < len; actual++) { - ret =sst_byte_write (flash, offset, buf + actual); -if (ret) { -debug ("SF: sst byte program failed\n" ); -break ; - } - offset++; - } - -if (!ret) - ret =spi_flash_cmd_write_disable (flash); - -debug ("SF: sst: program %s %zu bytes @ 0x%zx\n" , - ret ?"failure" :"success" , len, offset - actual); - -spi_release_bus (spi); -return ret; -} -#endif - -#if defined(CONFIG_SPI_FLASH_STMICRO ) || defined(CONFIG_SPI_FLASH_SST ) -static void stm_get_locked_range (struct spi_flash *flash,u8 sr,loff_t *ofs, -u64 *len) -{ -u8 mask =SR_BP2 |SR_BP1 |SR_BP0 ; -int shift =ffs (mask) -1 ; -int pow; - -if (!(sr & mask)) { -/* No protection */ - *ofs =0 ; - *len =0 ; - }else { - pow = ((sr & mask) ^ mask) >> shift; - *len = flash->size >> pow; - *ofs = flash->size - *len; - } -} - -/* -* Return 1 if the entire region is locked, 0 otherwise -*/ -static int stm_is_locked_sr (struct spi_flash *flash,loff_t ofs,u64 len, -u8 sr) -{ -loff_t lock_offs; -u64 lock_len; - -stm_get_locked_range (flash, sr, &lock_offs, &lock_len); - -return (ofs + len <= lock_offs + lock_len) && (ofs >= lock_offs); -} - -/* -* Check if a region of the flash is (completely) locked. See stm_lock() for -* more info. -* -* Returns 1 if entire region is locked, 0 if any portion is unlocked, and -* negative on errors. -*/ -int stm_is_locked (struct spi_flash *flash,u32 ofs,size_t len) -{ -int status; -u8 sr; - - status =read_sr (flash, &sr); -if (status <0 ) -return status; - -return stm_is_locked_sr (flash, ofs, len, sr); -} - -/* -* Lock a region of the flash. Compatible with ST Micro and similar flash. -* Supports only the block protection bits BP{0,1,2} in the status register -* (SR). Does not support these features found in newer SR bitfields: -* - TB: top/bottom protect - only handle TB=0 (top protect) -* - SEC: sector/block protect - only handle SEC=0 (block protect) -* - CMP: complement protect - only support CMP=0 (range is not complemented) -* -* Sample table portion for 8MB flash (Winbond w25q64fw): -* -* SEC | TB | BP2 | BP1 | BP0 | Prot Length | Protected Portion -* -------------------------------------------------------------------------- -* X | X | 0 | 0 | 0 | NONE | NONE -* 0 | 0 | 0 | 0 | 1 | 128 KB | Upper 1/64 -* 0 | 0 | 0 | 1 | 0 | 256 KB | Upper 1/32 -* 0 | 0 | 0 | 1 | 1 | 512 KB | Upper 1/16 -* 0 | 0 | 1 | 0 | 0 | 1 MB | Upper 1/8 -* 0 | 0 | 1 | 0 | 1 | 2 MB | Upper 1/4 -* 0 | 0 | 1 | 1 | 0 | 4 MB | Upper 1/2 -* X | X | 1 | 1 | 1 | 8 MB | ALL -* -* Returns negative on errors, 0 on success. -*/ -int stm_lock (struct spi_flash *flash,u32 ofs,size_t len) -{ -u8 status_old, status_new; -u8 mask =SR_BP2 |SR_BP1 |SR_BP0 ; -u8 shift =ffs (mask) -1 , pow, val; -int ret; - - ret =read_sr (flash, &status_old); -if (ret <0 ) -return ret; - -/* SPI NOR always locks to the end */ -if (ofs + len != flash->size) { -/* Does combined region extend to end? */ -if (!stm_is_locked_sr (flash, ofs + len, flash->size - ofs - len, - status_old)) -return -EINVAL ; - len = flash->size - ofs; - } - -/* -* Need smallest pow such that: -* -* 1 / (2^pow) <= (len / size) -* -* so (assuming power-of-2 size) we do: -* -* pow = ceil(log2(size / len)) = log2(size) - floor(log2(len)) -*/ - pow =ilog2 (flash->size) -ilog2 (len); - val = mask - (pow << shift); -if (val & ~mask) -return -EINVAL ; - -/* Don't "lock" with no region! */ -if (!(val & mask)) -return -EINVAL ; - - status_new = (status_old & ~mask) | val; - -/* Only modify protection if it will not unlock other areas */ -if ((status_new & mask) <= (status_old & mask)) -return -EINVAL ; - -write_sr (flash, status_new); - -return 0 ; -} - -/* -* Unlock a region of the flash. See stm_lock() for more info -* -* Returns negative on errors, 0 on success. -*/ -int stm_unlock (struct spi_flash *flash,u32 ofs,size_t len) -{ -uint8_t status_old, status_new; -u8 mask =SR_BP2 |SR_BP1 |SR_BP0 ; -u8 shift =ffs (mask) -1 , pow, val; -int ret; - - ret =read_sr (flash, &status_old); -if (ret <0 ) -return ret; - -/* Cannot unlock; would unlock larger region than requested */ -if (stm_is_locked_sr (flash, ofs - flash->erase_size, flash->erase_size, - status_old)) -return -EINVAL ; -/* -* Need largest pow such that: -* -* 1 / (2^pow) >= (len / size) -* -* so (assuming power-of-2 size) we do: -* -* pow = floor(log2(size / len)) = log2(size) - ceil(log2(len)) -*/ - pow =ilog2 (flash->size) -order_base_2 (flash->size - (ofs + len)); -if (ofs + len == flash->size) { - val =0 ;/* fully unlocked */ - }else { - val = mask - (pow << shift); -/* Some power-of-two sizes are not supported */ -if (val & ~mask) -return -EINVAL ; - } - - status_new = (status_old & ~mask) | val; - -/* Only modify protection if it will not lock other areas */ -if ((status_new & mask) >= (status_old & mask)) -return -EINVAL ; - -write_sr (flash, status_new); - -return 0 ; -} -#endif - - -#ifdef CONFIG_SPI_FLASH_MACRONIX -static int macronix_quad_enable (struct spi_flash *flash) -{ -u8 qeb_status; -int ret; - - ret =read_sr (flash, &qeb_status); -if (ret <0 ) -return ret; - -if (qeb_status &STATUS_QEB_MXIC ) -return 0 ; - - ret =write_sr (flash, qeb_status |STATUS_QEB_MXIC ); -if (ret <0 ) -return ret; - -/* read SR and check it */ - ret =read_sr (flash, &qeb_status); -if (!(ret >=0 && (qeb_status &STATUS_QEB_MXIC ))) { -printf ("SF: Macronix SR Quad bit not clear\n" ); -return -EINVAL ; - } - -return ret; -} -#endif - -#if defined(CONFIG_SPI_FLASH_SPANSION ) || defined(CONFIG_SPI_FLASH_WINBOND ) -static int spansion_quad_enable (struct spi_flash *flash) -{ -u8 qeb_status; -int ret; - - ret =read_cr (flash, &qeb_status); -if (ret <0 ) -return ret; - -if (qeb_status &STATUS_QEB_WINSPAN ) -return 0 ; - - ret =write_cr (flash, qeb_status |STATUS_QEB_WINSPAN ); -if (ret <0 ) -return ret; - -/* read CR and check it */ - ret =read_cr (flash, &qeb_status); -if (!(ret >=0 && (qeb_status &STATUS_QEB_WINSPAN ))) { -printf ("SF: Spansion CR Quad bit not clear\n" ); -return -EINVAL ; - } - -return ret; -} -#endif - -static const struct spi_flash_info *spi_flash_read_id (struct spi_flash *flash) -{ -int tmp; -u8 id[SPI_FLASH_MAX_ID_LEN ]; -const struct spi_flash_info *info; - - tmp =spi_flash_cmd (flash->spi,CMD_READ_ID , id,SPI_FLASH_MAX_ID_LEN ); -if (tmp <0 ) { -printf ("SF: error %d reading JEDEC ID\n" , tmp); -return ERR_PTR (tmp); - } - - info = spi_flash_ids; -for (; info->name !=NULL ; info++) { -if (info->id_len) { -if (!memcmp (info->id, id, info->id_len)) -return info; - } - } - -printf ("SF: unrecognized JEDEC id bytes: %02x, %02x, %02x\n" , - id[0 ], id[1 ], id[2 ]); -return ERR_PTR (-ENODEV ); -} - -static int set_quad_mode (struct spi_flash *flash, -const struct spi_flash_info *info) -{ -switch (JEDEC_MFR (info)) { -#ifdef CONFIG_SPI_FLASH_MACRONIX -case SPI_FLASH_CFI_MFR_MACRONIX : -return macronix_quad_enable (flash); -#endif -#if defined(CONFIG_SPI_FLASH_SPANSION ) || defined(CONFIG_SPI_FLASH_WINBOND ) -case SPI_FLASH_CFI_MFR_SPANSION : -case SPI_FLASH_CFI_MFR_WINBOND : -return spansion_quad_enable (flash); -#endif -#ifdef CONFIG_SPI_FLASH_STMICRO -case SPI_FLASH_CFI_MFR_STMICRO : -case SPI_FLASH_CFI_MFR_MICRON : -debug ("SF: QEB is volatile for %02x flash\n" ,JEDEC_MFR (info)); -return 0 ; -#endif -default : -printf ("SF: Need set QEB func for %02x flash\n" , -JEDEC_MFR (info)); -return -1 ; - } -} - -#if CONFIG_IS_ENABLED (OF_CONTROL ) -int spi_flash_decode_fdt (struct spi_flash *flash) -{ -#ifdef CONFIG_DM_SPI_FLASH -fdt_addr_t addr; -fdt_size_t size; - - addr =dev_read_addr_size (flash->dev,"memory-map" , &size); -if (addr ==FDT_ADDR_T_NONE ) { -debug ("%s: Cannot decode address\n" , __func__); -return 0 ; - } - -if (flash->size > size) { -debug ("%s: Memory map must cover entire device\n" , __func__); -return -1 ; - } - flash->memory_map =map_sysmem (addr, size); -#endif - -return 0 ; -} -#endif /* CONFIG_IS_ENABLED(OF_CONTROL) */ - -int spi_flash_scan (struct spi_flash *flash) -{ -struct spi_slave *spi = flash->spi; -const struct spi_flash_info *info =NULL ; -int ret; - - info =spi_flash_read_id (flash); -if (IS_ERR_OR_NULL (info)) -return -ENOENT ; - -/* -* Flash powers up read-only, so clear BP# bits. -* -* Note on some flash (like Macronix), QE (quad enable) bit is in the -* same status register as BP# bits, and we need preserve its original -* value during a reboot cycle as this is required by some platforms -* (like Intel ICH SPI controller working under descriptor mode). -*/ -if (JEDEC_MFR (info) ==SPI_FLASH_CFI_MFR_ATMEL || - (JEDEC_MFR (info) ==SPI_FLASH_CFI_MFR_SST ) || - (JEDEC_MFR (info) ==SPI_FLASH_CFI_MFR_MACRONIX )) { -u8 sr =0 ; - -if (JEDEC_MFR (info) ==SPI_FLASH_CFI_MFR_MACRONIX ) { -read_sr (flash, &sr); - sr &=STATUS_QEB_MXIC ; - } -write_sr (flash, sr); - } - - flash->name = info->name; - flash->memory_map = spi->memory_map; - -if (info->flags &SST_WR ) - flash->flags |=SNOR_F_SST_WR ; - -#ifndef CONFIG_DM_SPI_FLASH - flash->write = spi_flash_cmd_write_ops; -#if defined(CONFIG_SPI_FLASH_SST ) -if (flash->flags &SNOR_F_SST_WR ) { -if (spi->mode &SPI_TX_BYTE ) - flash->write = sst_write_bp; -else - flash->write = sst_write_wp; - } -#endif - flash->erase = spi_flash_cmd_erase_ops; - flash->read = spi_flash_cmd_read_ops; -#endif - -#if defined(CONFIG_SPI_FLASH_STMICRO ) || defined(CONFIG_SPI_FLASH_SST ) -/* NOR protection support for STmicro/Micron chips and similar */ -if (JEDEC_MFR (info) ==SPI_FLASH_CFI_MFR_STMICRO || -JEDEC_MFR (info) ==SPI_FLASH_CFI_MFR_MICRON || -JEDEC_MFR (info) ==SPI_FLASH_CFI_MFR_SST ) { - flash->flash_lock = stm_lock; - flash->flash_unlock = stm_unlock; - flash->flash_is_locked = stm_is_locked; - } -#endif - -/* sst26wf series block protection implementation differs from other series */ -#if defined(CONFIG_SPI_FLASH_SST ) -if (JEDEC_MFR (info) ==SPI_FLASH_CFI_MFR_SST && info->id[1 ] ==0x26 ) { - flash->flash_lock = sst26_lock; - flash->flash_unlock = sst26_unlock; - flash->flash_is_locked = sst26_is_locked; - } -#endif - -/* Compute the flash size */ - flash->shift = (flash->dual_flash &SF_DUAL_PARALLEL_FLASH ) ?1 :0 ; - flash->page_size = info->page_size; -/* -* The Spansion S25FS512S, S25FL032P and S25FL064P have 256b pages, -* yet use the 0x4d00 Extended JEDEC code. The rest of the Spansion -* flashes with the 0x4d00 Extended JEDEC code have 512b pages. -* All of the others have 256b pages. -*/ -if (JEDEC_EXT (info) ==0x4d00 ) { -if ((JEDEC_ID (info) !=0x0215 ) && - (JEDEC_ID (info) !=0x0216 ) && - (JEDEC_ID (info) !=0x0220 )) - flash->page_size =512 ; - } - flash->page_size <<= flash->shift; - flash->sector_size = info->sector_size << flash->shift; - flash->size = flash->sector_size * info->n_sectors << flash->shift; -#ifdef CONFIG_SF_DUAL_FLASH -if (flash->dual_flash &SF_DUAL_STACKED_FLASH ) - flash->size <<=1 ; -#endif - -#ifdef CONFIG_SPI_FLASH_USE_4K_SECTORS -/* Compute erase sector and command */ -if (info->flags &SECT_4K ) { - flash->erase_cmd =CMD_ERASE_4K ; - flash->erase_size =4096 << flash->shift; - } else -#endif - { - flash->erase_cmd =CMD_ERASE_64K ; - flash->erase_size = flash->sector_size; - } - -/* Now erase size becomes valid sector size */ - flash->sector_size = flash->erase_size; - -/* Look for read commands */ - flash->read_cmd =CMD_READ_ARRAY_FAST ; -if (spi->mode &SPI_RX_SLOW ) - flash->read_cmd =CMD_READ_ARRAY_SLOW ; -else if (spi->mode &SPI_RX_QUAD && info->flags &RD_QUAD ) - flash->read_cmd =CMD_READ_QUAD_OUTPUT_FAST ; -else if (spi->mode &SPI_RX_DUAL && info->flags &RD_DUAL ) - flash->read_cmd =CMD_READ_DUAL_OUTPUT_FAST ; - -/* Look for write commands */ -if (info->flags &WR_QPP && spi->mode &SPI_TX_QUAD ) - flash->write_cmd =CMD_QUAD_PAGE_PROGRAM ; -else -/* Go for default supported write cmd */ - flash->write_cmd =CMD_PAGE_PROGRAM ; - -/* Set the quad enable bit - only for quad commands */ -if ((flash->read_cmd ==CMD_READ_QUAD_OUTPUT_FAST ) || - (flash->read_cmd ==CMD_READ_QUAD_IO_FAST ) || - (flash->write_cmd ==CMD_QUAD_PAGE_PROGRAM )) { - ret =set_quad_mode (flash, info); -if (ret) { -debug ("SF: Fail to set QEB for %02x\n" , -JEDEC_MFR (info)); -return -EINVAL ; - } - } - -/* Read dummy_byte: dummy byte is determined based on the -* dummy cycles of a particular command. -* Fast commands - dummy_byte = dummy_cycles/8 -* I/O commands- dummy_byte = (dummy_cycles * no.of lines)/8 -* For I/O commands except cmd[0] everything goes on no.of lines -* based on particular command but incase of fast commands except -* data all go on single line irrespective of command. -*/ -switch (flash->read_cmd) { -case CMD_READ_QUAD_IO_FAST : - flash->dummy_byte =2 ; -break ; -case CMD_READ_ARRAY_SLOW : - flash->dummy_byte =0 ; -break ; -default : - flash->dummy_byte =1 ; - } - -#ifdef CONFIG_SPI_FLASH_STMICRO -if (info->flags &E_FSR ) - flash->flags |=SNOR_F_USE_FSR ; -#endif - -/* Configure the BAR - discover bank cmds and read current bank */ -#ifdef CONFIG_SPI_FLASH_BAR - ret =read_bar (flash, info); -if (ret <0 ) -return ret; -#endif - -#if CONFIG_IS_ENABLED (OF_CONTROL ) && !CONFIG_IS_ENABLED (OF_PLATDATA ) - ret =spi_flash_decode_fdt (flash); -if (ret) { -debug ("SF: FDT decode error\n" ); -return -EINVAL ; - } -#endif - -#ifndef CONFIG_SPL_BUILD -printf ("SF: Detected %s with page size " , flash->name); -print_size (flash->page_size,", erase size " ); -print_size (flash->erase_size,", total " ); -print_size (flash->size,"" ); -if (flash->memory_map) -printf (", mapped at %p" , flash->memory_map); -puts ("\n" ); -#endif - -#ifndef CONFIG_SPI_FLASH_BAR -if (((flash->dual_flash ==SF_SINGLE_FLASH ) && - (flash->size >SPI_FLASH_16MB_BOUN )) || - ((flash->dual_flash >SF_SINGLE_FLASH ) && - (flash->size >SPI_FLASH_16MB_BOUN <<1 ))) { -puts ("SF: Warning - Only lower 16MiB accessible," ); -puts (" Full access #define CONFIG_SPI_FLASH_BAR\n" ); - } -#endif - -return 0 ; -}
drivers/mtd/spi/spi_flash_ids.c deleted +0 -211
211 lines not on this page · raw message
Signature · 1 line
2.19.2
PATCH 7/16 mtd: spi: Remove unused files
Quoted 8 lines · Vignesh R
spi_flashandspi_flash_idsare no longer needed after SPI NOR migration. Remove them.Signed-off-by Vignesh R <[email protected]>--- drivers/mtd/spi/spi_flash.c | 1337 ------------------------------- drivers/mtd/spi/spi_flash_ids.c | 211 -----
Better to keep this by renaming and other licesnes, ie what I did before. It's good for maintaining ids separately instead of having in one big spi-nor file.
Vignesh R
maintainerPATCH 7/16 mtd: spi: Remove unused files
Quoted 5 lines · Jagan Teki
Quoted 4 lines · Vignesh R
spi_flashandspi_flash_idsare no longer needed after SPI NOR migration. Remove them.
Quoted 9 lines
Quoted 4 lines
Signed-off-by Vignesh R <[email protected]>--- drivers/mtd/spi/spi_flash.c | 1337 ------------------------------- drivers/mtd/spi/spi_flash_ids.c | 211 -----Better to keep this by renaming and other licesnes, ie what I did before. It's good for maintaining ids separately instead of having in one big spi-nor file.
Flash ID table is refactored to separate file spi-nor-ids.c as part of 8/16. Its daunting task to update spi_flash_ids.c file to work with Linux's spi-nor layer due to differences in flags and addition of new SPI_NOR_4B_OPCODES flag.
I can re-add copyright next time around as some of the information is borrowed from existing spi_flash_ids.c
Signature · 2 lines
Regards Vignesh
Vignesh R
maintainerPATCH 8/16 mtd: spi: Add lightweight SPI flash stack for SPL
In reply to Vignesh RAdd a tiny SPI flash stack that just supports reading data/images from SPI flash. This is useful for boards that have SPL size constraints and would need to use SPI flash framework just to read images/data from flash. There is approximately 1.5 to 2KB savings with this.
Based on prior work of reducing spi flash id table by Simon Goldschmidt <[email protected]>
--- common/spl/Kconfig | 9 + drivers/mtd/spi/Makefile | 10 +- drivers/mtd/spi/sf_internal.h | 2 + drivers/mtd/spi/spi-nor-core.c | 266 +---------- drivers/mtd/spi/spi-nor-ids.c | 294 ++++++++++++ drivers/mtd/spi/spi-nor-tiny.c | 810 +++++++++++++++++++++++++++++++++ 6 files changed, 1128 insertions(+), 263 deletions(-) create mode 100644 drivers/mtd/spi/spi-nor-ids.c create mode 100644 drivers/mtd/spi/spi-nor-tiny.c
common/spl/Kconfig +9 -0
@@ -729,8 +729,17 @@ config SPL_SPI_FLASH_SUPPORT if SPL_SPI_FLASH_SUPPORT +config SPL_SPI_FLASH_TINY + bool "Enable low footprint SPL SPI Flash support" + help + Enable lightweight SPL SPI Flash support that supports just reading + data/images from flash. No support to write/erase flash. Enable + this if you have SPL size limitations and don't need full + fledged SPI flash support. + config SPL_SPI_FLASH_SFDP_SUPPORT bool "SFDP table parsing support for SPI NOR flashes" + depends on !SPL_SPI_FLASH_TINY help Enable support for parsing and auto discovery of parameters for SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP)
drivers/mtd/spi/Makefile +9 -1
@@ -4,12 +4,20 @@ # Wolfgang Denk, DENX Software Engineering, wd at denx.de. obj-$(CONFIG_DM_SPI_FLASH) += sf-uclass.o +spi-nor-y := sf_probe.o spi-nor-ids.o ifdef CONFIG_SPL_BUILD obj-$(CONFIG_SPL_SPI_BOOT) += fsl_espi_spl.o +ifeq ($(CONFIG_SPL_SPI_FLASH_TINY),y) +spi-nor-y += spi-nor-tiny.o +else +spi-nor-y += spi-nor-core.o +endif +else +spi-nor-y += spi-nor-core.o endif -obj-$(CONFIG_SPI_FLASH) += sf_probe.o spi-nor-core.o +obj-$(CONFIG_SPI_FLASH) += spi-nor.o obj-$(CONFIG_SPI_FLASH_DATAFLASH) += sf_dataflash.o sf.o obj-$(CONFIG_SPI_FLASH_MTD) += sf_mtd.o obj-$(CONFIG_SPI_FLASH_SANDBOX) += sandbox.o
drivers/mtd/spi/sf_internal.h +2 -0
@@ -16,7 +16,9 @@#define SPI_NOR_MAX_ADDR_WIDTH 4struct flash_info { +#if !CONFIG_IS_ENABLED (SPI_FLASH_TINY )char *name; +#endif /* * This array stores the ID bytes.
drivers/mtd/spi/spi-nor-core.c +4 -262
288 lines not on this page · raw message
drivers/mtd/spi/spi-nor-ids.c new file +294 -0
294 lines not on this page · raw message
drivers/mtd/spi/spi-nor-tiny.c new file +810 -0
810 lines not on this page · raw message
Signature · 1 line
2.19.2
Vignesh R
maintainerPATCH 9/16 sf_mtd: Simply mtd operations
In reply to Vignesh RNow that there is new SPI NOR framework, simplify mtd device registration and read/write/erase operations.
--- drivers/mtd/spi/sf_internal.h | 2 +- drivers/mtd/spi/sf_mtd.c | 52 ++++++++++++++--------------------- drivers/mtd/spi/sf_probe.c | 5 ++-- 3 files changed, 24 insertions(+), 35 deletions(-)
drivers/mtd/spi/sf_internal.h +1 -1
@@ -99,6 +99,6 @@ int spi_flash_cmd_get_sw_write_prot(struct spi_flash *flash);#ifdef CONFIG_SPI_FLASH_MTD int spi_flash_mtd_register (struct spi_flash *flash); -void spi_flash_mtd_unregister (void ); +void spi_flash_mtd_unregister (struct spi_flash *flash);#endif #endif /* _SF_INTERNAL_H_ */
drivers/mtd/spi/sf_mtd.c +20 -32
126 lines not on this page · raw message
drivers/mtd/spi/sf_probe.c +3 -2
@@ -84,7 +84,7 @@ struct spi_flash *spi_flash_probe(unsigned int busnum, unsigned int cs,void spi_flash_free (struct spi_flash *flash) {#ifdef CONFIG_SPI_FLASH_MTD -spi_flash_mtd_unregister (); +spi_flash_mtd_unregister (flash);#endif spi_free_slave (flash->spi);free (flash);
@@ -153,7 +153,8 @@ static int spi_flash_std_probe(struct udevice *dev)static int spi_flash_std_remove (struct udevice *dev) {#ifdef CONFIG_SPI_FLASH_MTD -spi_flash_mtd_unregister (); +struct spi_flash *flash =dev_get_uclass_priv (dev); +spi_flash_mtd_unregister (flash);#endif return 0 ; }
Signature · 1 line
2.19.2
PATCH 9/16 sf_mtd: Simply mtd operations
drivers/mtd/spi/sf_mtd.c static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr) · line 45
Quoted 13 lines · On Wed, 12 Dec 2018 23:02:21 +0530 Vignesh R <[email protected]> wrote:
drivers/mtd/spi/sf_mtd.c +2
-3@@ -39,13 +37,12 @@ static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)static int spi_flash_mtd_read (struct mtd_info *mtd,loff_t from,size_t len,size_t *retlen,u_char *buf) { -struct spi_flash *flash = mtd->priv;int err; -if (!flash) +if (!mtd || !mtd->priv)return -ENODEV ; - err =spi_flash_read (flash, from, len, buf); + err = mtd->_read (mtd, from, len, retlen, buf);
Please use the wrappers instead of calling those hooks directly.
PATCH 9/16 sf_mtd: Simply mtd operations
In reply to Vignesh RAm 12.12.18 um 18:32 schrieb Vignesh R:
Quoted 37 lines
Now that there is new SPI NOR framework, simplify mtd device registration and read/write/erase operations.
Signed-off-by Vignesh R <[email protected]>--- drivers/mtd/spi/sf_internal.h | 2 +- drivers/mtd/spi/sf_mtd.c | 52 ++++++++++++++--------------------- drivers/mtd/spi/sf_probe.c | 5 ++-- 3 files changed, 24 insertions(+), 35 deletions(-)drivers/mtd/spi/sf_internal.h +1
-1@@ -99,6 +99,6 @@ int spi_flash_cmd_get_sw_write_prot(struct spi_flash *flash);#ifdef CONFIG_SPI_FLASH_MTD int spi_flash_mtd_register (struct spi_flash *flash); -void spi_flash_mtd_unregister (void ); +void spi_flash_mtd_unregister (struct spi_flash *flash);#endif #endif /* _SF_INTERNAL_H_ */ drivers/mtd/spi/sf_mtd.c +0
-2@@ -9,21 +9,19 @@#include <linux/mtd/mtd.h> #include <spi_flash.h> -static struct mtd_info sf_mtd_info;static bool sf_mtd_registered;static char sf_mtd_name[8 ];static int spi_flash_mtd_erase (struct mtd_info *mtd,struct erase_info *instr) { -struct spi_flash *flash = mtd->priv;
drivers/mtd/spi/sf_mtd.c line 24
Quoted 10 lines
drivers/mtd/spi/sf_mtd.c +2
-2int err; -if (!flash) +if (!mtd || !mtd->priv)return -ENODEV ; instr->state =MTD_ERASING ; - err =spi_flash_erase (flash, instr->addr, instr->len); + err = mtd->_erase (mtd, instr);
this looks strange. Now you're delegating from the MTD instance created in this driver to the one created by spi-nor. This driver was only meant as an adapter between MTD and legacy SPI flash API. After the switch to spi-nor this driver is obsolete and should be removed in patch 6/16. Or is there any reason why users like cmd_mtd can't directly use the spi-nor MTD instance?
Quoted 135 lines
drivers/mtd/spi/sf_mtd.c +18
-28if (err) { instr->state =MTD_ERASE_FAILED ; instr->fail_addr =MTD_FAIL_ADDR_UNKNOWN ;@@ -39,13 +37,12 @@ static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)static int spi_flash_mtd_read (struct mtd_info *mtd,loff_t from,size_t len,size_t *retlen,u_char *buf) { -struct spi_flash *flash = mtd->priv;int err; -if (!flash) +if (!mtd || !mtd->priv)return -ENODEV ; - err =spi_flash_read (flash, from, len, buf); + err = mtd->_read (mtd, from, len, retlen, buf);if (!err) *retlen = len;@@ -55,13 +52,12 @@ static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,static int spi_flash_mtd_write (struct mtd_info *mtd,loff_t to,size_t len,size_t *retlen,const u_char *buf) { -struct spi_flash *flash = mtd->priv;int err; -if (!flash) +if (!mtd || !mtd->priv)return -ENODEV ; - err =spi_flash_write (flash, to, len, buf); + err = mtd->_write (mtd, to, len, retlen, buf);if (!err) *retlen = len;@@ -83,10 +79,11 @@ static int spi_flash_mtd_number(void)int spi_flash_mtd_register (struct spi_flash *flash) { +struct mtd_info *mtd = &flash->mtd;int ret;if (sf_mtd_registered) { - ret =del_mtd_device (&sf_mtd_info); + ret =del_mtd_device (mtd);if (ret)return ret;@@ -94,42 +91,33 @@ int spi_flash_mtd_register(struct spi_flash *flash) } sf_mtd_registered = false; -memset (&sf_mtd_info,0 ,sizeof (sf_mtd_info));sprintf (sf_mtd_name,"nor%d" ,spi_flash_mtd_number ()); - sf_mtd_info.name = sf_mtd_name; - sf_mtd_info.type =MTD_NORFLASH ; - sf_mtd_info.flags =MTD_CAP_NORFLASH ; - sf_mtd_info.writesize =1 ; - sf_mtd_info.writebufsize = flash->page_size; - - sf_mtd_info._erase = spi_flash_mtd_erase; - sf_mtd_info._read = spi_flash_mtd_read; - sf_mtd_info._write = spi_flash_mtd_write; - sf_mtd_info._sync = spi_flash_mtd_sync; - - sf_mtd_info.size = flash->size; - sf_mtd_info.priv = flash; + mtd->name = sf_mtd_name; + mtd->_erase = spi_flash_mtd_erase; + mtd->_read = spi_flash_mtd_read; + mtd->_write = spi_flash_mtd_write; + mtd->_sync = spi_flash_mtd_sync;/* Only uniform flash devices for now */ - sf_mtd_info.numeraseregions =0 ; - sf_mtd_info.erasesize = flash->sector_size; + mtd->numeraseregions =0 ; - ret =add_mtd_device (&sf_mtd_info); + ret =add_mtd_device (mtd);if (!ret) sf_mtd_registered = true;return ret; } -void spi_flash_mtd_unregister (void ) +void spi_flash_mtd_unregister (struct spi_flash *flash) { +struct mtd_info *mtd = &flash->mtd;int ret;if (!sf_mtd_registered)return ; - ret =del_mtd_device (&sf_mtd_info); + ret =del_mtd_device (mtd);if (!ret) { sf_mtd_registered = false;return ;@@ -141,7 +129,7 @@ void spi_flash_mtd_unregister(void)* use-after-free bug. Still, things should be fixed to prevent the * spi_flash object from being destroyed when del_mtd_device() fails. */ - sf_mtd_info.priv =NULL ; + mtd->priv =NULL ;printf ("Failed to unregister MTD %s and the spi_flash object is going away: you're in deep trouble!" , - sf_mtd_info.name); + sf_mtd_name); }drivers/mtd/spi/sf_probe.c +3
-2@@ -84,7 +84,7 @@ struct spi_flash *spi_flash_probe(unsigned int busnum, unsigned int cs,void spi_flash_free (struct spi_flash *flash) {#ifdef CONFIG_SPI_FLASH_MTD -spi_flash_mtd_unregister (); +spi_flash_mtd_unregister (flash);#endif spi_free_slave (flash->spi);free (flash);@@ -153,7 +153,8 @@ static int spi_flash_std_probe(struct udevice *dev)static int spi_flash_std_remove (struct udevice *dev) {#ifdef CONFIG_SPI_FLASH_MTD -spi_flash_mtd_unregister (); +struct spi_flash *flash =dev_get_uclass_priv (dev); +spi_flash_mtd_unregister (flash);#endif return 0 ; }
Signature · 1 line
- Daniel
PATCH 9/16 sf_mtd: Simply mtd operations
In reply to Vignesh RHi Vignesh,
Quoted 55 lines · Vignesh R
Now that there is new SPI NOR framework, simplify mtd device registration and read/write/erase operations.
Signed-off-by Vignesh R <[email protected]>--- drivers/mtd/spi/sf_internal.h | 2 +- drivers/mtd/spi/sf_mtd.c | 52 ++++++++++++++--------------------- drivers/mtd/spi/sf_probe.c | 5 ++-- 3 files changed, 24 insertions(+), 35 deletions(-)drivers/mtd/spi/sf_internal.h +1
-1@@ -99,6 +99,6 @@ int spi_flash_cmd_get_sw_write_prot(struct spi_flash *flash);#ifdef CONFIG_SPI_FLASH_MTD int spi_flash_mtd_register (struct spi_flash *flash); -void spi_flash_mtd_unregister (void ); +void spi_flash_mtd_unregister (struct spi_flash *flash);#endif #endif /* _SF_INTERNAL_H_ */ drivers/mtd/spi/sf_mtd.c +2
-5@@ -9,21 +9,19 @@#include <linux/mtd/mtd.h> #include <spi_flash.h> -static struct mtd_info sf_mtd_info;static bool sf_mtd_registered;static char sf_mtd_name[8 ];static int spi_flash_mtd_erase (struct mtd_info *mtd,struct erase_info *instr) { -struct spi_flash *flash = mtd->priv;int err; -if (!flash) +if (!mtd || !mtd->priv)return -ENODEV ; instr->state =MTD_ERASING ; - err =spi_flash_erase (flash, instr->addr, instr->len); + err = mtd->_erase (mtd, instr);if (err) { instr->state =MTD_ERASE_FAILED ; instr->fail_addr =MTD_FAIL_ADDR_UNKNOWN ;@@ -39,13 +37,12 @@ static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)static int spi_flash_mtd_read (struct mtd_info *mtd,loff_t from,size_t len,size_t *retlen,u_char *buf) { -struct spi_flash *flash = mtd->priv;
drivers/mtd/spi/sf_mtd.c static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr) · line 47
Quoted 10 lines
drivers/mtd/spi/sf_mtd.c +2
-2int err; -if (!flash) +if (!mtd || !mtd->priv)return -ENODEV ; - err =spi_flash_read (flash, from, len, buf); + err = mtd->_read (mtd, from, len, retlen, buf);if (!err) *retlen = len;
I just tested this patchset on my MIPS linkit smart platform and it hangs in an infinite loop here in this read function. The callstack is:
spi_flash_std_read -> spi_flash_mtd_read
spi_flash_mtd_read() now calls itself recursively.
Any ideas?
Thanks,
Stefan
Vignesh R
maintainerPATCH 9/16 sf_mtd: Simply mtd operations
In reply to Vignesh RBoris, Stefan, Daniel
Quoted 5 lines · Vignesh R
Now that there is new SPI NOR framework, simplify mtd device registration and read/write/erase operations.
Signed-off-by Vignesh R <[email protected]>---
Oops, sorry I messed up rebase-ing this patch onto latest mainline. At this time it looks like MTD kconfig changes [1] are needed before I can simplify sf_mtd.c. Things should work even w/o this patch. I think I will drop this patch for now.
[1] https://patchwork.ozlabs.org/cover/1010033/
Quoted 177 lines
drivers/mtd/spi/sf_internal.h | 2 +- drivers/mtd/spi/sf_mtd.c | 52 ++++++++++++++--------------------- drivers/mtd/spi/sf_probe.c | 5 ++-- 3 files changed, 24 insertions(+), 35 deletions(-)drivers/mtd/spi/sf_internal.h +1
-1@@ -99,6 +99,6 @@ int spi_flash_cmd_get_sw_write_prot(struct spi_flash *flash);#ifdef CONFIG_SPI_FLASH_MTD int spi_flash_mtd_register (struct spi_flash *flash); -void spi_flash_mtd_unregister (void ); +void spi_flash_mtd_unregister (struct spi_flash *flash);#endif #endif /* _SF_INTERNAL_H_ */ drivers/mtd/spi/sf_mtd.c +20
-32@@ -9,21 +9,19 @@#include <linux/mtd/mtd.h> #include <spi_flash.h> -static struct mtd_info sf_mtd_info;static bool sf_mtd_registered;static char sf_mtd_name[8 ];static int spi_flash_mtd_erase (struct mtd_info *mtd,struct erase_info *instr) { -struct spi_flash *flash = mtd->priv;int err; -if (!flash) +if (!mtd || !mtd->priv)return -ENODEV ; instr->state =MTD_ERASING ; - err =spi_flash_erase (flash, instr->addr, instr->len); + err = mtd->_erase (mtd, instr);if (err) { instr->state =MTD_ERASE_FAILED ; instr->fail_addr =MTD_FAIL_ADDR_UNKNOWN ;@@ -39,13 +37,12 @@ static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)static int spi_flash_mtd_read (struct mtd_info *mtd,loff_t from,size_t len,size_t *retlen,u_char *buf) { -struct spi_flash *flash = mtd->priv;int err; -if (!flash) +if (!mtd || !mtd->priv)return -ENODEV ; - err =spi_flash_read (flash, from, len, buf); + err = mtd->_read (mtd, from, len, retlen, buf);if (!err) *retlen = len;@@ -55,13 +52,12 @@ static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,static int spi_flash_mtd_write (struct mtd_info *mtd,loff_t to,size_t len,size_t *retlen,const u_char *buf) { -struct spi_flash *flash = mtd->priv;int err; -if (!flash) +if (!mtd || !mtd->priv)return -ENODEV ; - err =spi_flash_write (flash, to, len, buf); + err = mtd->_write (mtd, to, len, retlen, buf);if (!err) *retlen = len;@@ -83,10 +79,11 @@ static int spi_flash_mtd_number(void)int spi_flash_mtd_register (struct spi_flash *flash) { +struct mtd_info *mtd = &flash->mtd;int ret;if (sf_mtd_registered) { - ret =del_mtd_device (&sf_mtd_info); + ret =del_mtd_device (mtd);if (ret)return ret;@@ -94,42 +91,33 @@ int spi_flash_mtd_register(struct spi_flash *flash) } sf_mtd_registered = false; -memset (&sf_mtd_info,0 ,sizeof (sf_mtd_info));sprintf (sf_mtd_name,"nor%d" ,spi_flash_mtd_number ()); - sf_mtd_info.name = sf_mtd_name; - sf_mtd_info.type =MTD_NORFLASH ; - sf_mtd_info.flags =MTD_CAP_NORFLASH ; - sf_mtd_info.writesize =1 ; - sf_mtd_info.writebufsize = flash->page_size; - - sf_mtd_info._erase = spi_flash_mtd_erase; - sf_mtd_info._read = spi_flash_mtd_read; - sf_mtd_info._write = spi_flash_mtd_write; - sf_mtd_info._sync = spi_flash_mtd_sync; - - sf_mtd_info.size = flash->size; - sf_mtd_info.priv = flash; + mtd->name = sf_mtd_name; + mtd->_erase = spi_flash_mtd_erase; + mtd->_read = spi_flash_mtd_read; + mtd->_write = spi_flash_mtd_write; + mtd->_sync = spi_flash_mtd_sync;/* Only uniform flash devices for now */ - sf_mtd_info.numeraseregions =0 ; - sf_mtd_info.erasesize = flash->sector_size; + mtd->numeraseregions =0 ; - ret =add_mtd_device (&sf_mtd_info); + ret =add_mtd_device (mtd);if (!ret) sf_mtd_registered = true;return ret; } -void spi_flash_mtd_unregister (void ) +void spi_flash_mtd_unregister (struct spi_flash *flash) { +struct mtd_info *mtd = &flash->mtd;int ret;if (!sf_mtd_registered)return ; - ret =del_mtd_device (&sf_mtd_info); + ret =del_mtd_device (mtd);if (!ret) { sf_mtd_registered = false;return ;@@ -141,7 +129,7 @@ void spi_flash_mtd_unregister(void)* use-after-free bug. Still, things should be fixed to prevent the * spi_flash object from being destroyed when del_mtd_device() fails. */ - sf_mtd_info.priv =NULL ; + mtd->priv =NULL ;printf ("Failed to unregister MTD %s and the spi_flash object is going away: you're in deep trouble!" , - sf_mtd_info.name); + sf_mtd_name); }drivers/mtd/spi/sf_probe.c +3
-2@@ -84,7 +84,7 @@ struct spi_flash *spi_flash_probe(unsigned int busnum, unsigned int cs,void spi_flash_free (struct spi_flash *flash) {#ifdef CONFIG_SPI_FLASH_MTD -spi_flash_mtd_unregister (); +spi_flash_mtd_unregister (flash);#endif spi_free_slave (flash->spi);free (flash);@@ -153,7 +153,8 @@ static int spi_flash_std_probe(struct udevice *dev)static int spi_flash_std_remove (struct udevice *dev) {#ifdef CONFIG_SPI_FLASH_MTD -spi_flash_mtd_unregister (); +struct spi_flash *flash =dev_get_uclass_priv (dev); +spi_flash_mtd_unregister (flash);#endif return 0 ; }
Signature · 2 lines
Regards Vignesh
PATCH 9/16 sf_mtd: Simply mtd operations
Quoted 6 lines · Vignesh R
Boris, Stefan, Daniel
Quoted 3 lines · Vignesh R
Now that there is new SPI NOR framework, simplify mtd device registration and read/write/erase operations.
Quoted 7 lines
Quoted 2 lines
Signed-off-by Vignesh R <[email protected]>---
Oops, sorry I messed up rebase-ing this patch onto latest mainline. At this time it looks like MTD kconfig changes [1] are needed before I can simplify
sf_mtd.c. Things should work even w/o this patch. I think I will drop this patch for now.
With this patch removed from this series, all seems to work just fine on my board with the strapped to 4-byte mode SPI NOR chip. Feel free to add my:
Thanks,
Stefan
Quoted 171 lines
[1] https://patchwork.ozlabs.org/cover/1010033/
Quoted 169 lines
drivers/mtd/spi/sf_internal.h | 2 +- drivers/mtd/spi/sf_mtd.c | 52 ++++++++++++++--------------------- drivers/mtd/spi/sf_probe.c | 5 ++-- 3 files changed, 24 insertions(+), 35 deletions(-)drivers/mtd/spi/sf_internal.h +1
-1@@ -99,6 +99,6 @@ int spi_flash_cmd_get_sw_write_prot(struct spi_flash *flash);#ifdef CONFIG_SPI_FLASH_MTD int spi_flash_mtd_register (struct spi_flash *flash); -void spi_flash_mtd_unregister (void ); +void spi_flash_mtd_unregister (struct spi_flash *flash);#endif #endif /* _SF_INTERNAL_H_ */ drivers/mtd/spi/sf_mtd.c +20
-32@@ -9,21 +9,19 @@#include <linux/mtd/mtd.h> #include <spi_flash.h> -static struct mtd_info sf_mtd_info;static bool sf_mtd_registered;static char sf_mtd_name[8 ];static int spi_flash_mtd_erase (struct mtd_info *mtd,struct erase_info *instr) { -struct spi_flash *flash = mtd->priv;int err; -if (!flash) +if (!mtd || !mtd->priv)return -ENODEV ; instr->state =MTD_ERASING ; - err =spi_flash_erase (flash, instr->addr, instr->len); + err = mtd->_erase (mtd, instr);if (err) { instr->state =MTD_ERASE_FAILED ; instr->fail_addr =MTD_FAIL_ADDR_UNKNOWN ;@@ -39,13 +37,12 @@ static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)static int spi_flash_mtd_read (struct mtd_info *mtd,loff_t from,size_t len,size_t *retlen,u_char *buf) { -struct spi_flash *flash = mtd->priv;int err; -if (!flash) +if (!mtd || !mtd->priv)return -ENODEV ; - err =spi_flash_read (flash, from, len, buf); + err = mtd->_read (mtd, from, len, retlen, buf);if (!err) *retlen = len;@@ -55,13 +52,12 @@ static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,static int spi_flash_mtd_write (struct mtd_info *mtd,loff_t to,size_t len,size_t *retlen,const u_char *buf) { -struct spi_flash *flash = mtd->priv;int err; -if (!flash) +if (!mtd || !mtd->priv)return -ENODEV ; - err =spi_flash_write (flash, to, len, buf); + err = mtd->_write (mtd, to, len, retlen, buf);if (!err) *retlen = len;@@ -83,10 +79,11 @@ static int spi_flash_mtd_number(void)int spi_flash_mtd_register (struct spi_flash *flash) { +struct mtd_info *mtd = &flash->mtd;int ret;if (sf_mtd_registered) { - ret =del_mtd_device (&sf_mtd_info); + ret =del_mtd_device (mtd);if (ret)return ret;@@ -94,42 +91,33 @@ int spi_flash_mtd_register(struct spi_flash *flash) } sf_mtd_registered = false; -memset (&sf_mtd_info,0 ,sizeof (sf_mtd_info));sprintf (sf_mtd_name,"nor%d" ,spi_flash_mtd_number ()); - sf_mtd_info.name = sf_mtd_name; - sf_mtd_info.type =MTD_NORFLASH ; - sf_mtd_info.flags =MTD_CAP_NORFLASH ; - sf_mtd_info.writesize =1 ; - sf_mtd_info.writebufsize = flash->page_size; - - sf_mtd_info._erase = spi_flash_mtd_erase; - sf_mtd_info._read = spi_flash_mtd_read; - sf_mtd_info._write = spi_flash_mtd_write; - sf_mtd_info._sync = spi_flash_mtd_sync; - - sf_mtd_info.size = flash->size; - sf_mtd_info.priv = flash; + mtd->name = sf_mtd_name; + mtd->_erase = spi_flash_mtd_erase; + mtd->_read = spi_flash_mtd_read; + mtd->_write = spi_flash_mtd_write; + mtd->_sync = spi_flash_mtd_sync;/* Only uniform flash devices for now */ - sf_mtd_info.numeraseregions =0 ; - sf_mtd_info.erasesize = flash->sector_size; + mtd->numeraseregions =0 ; - ret =add_mtd_device (&sf_mtd_info); + ret =add_mtd_device (mtd);if (!ret) sf_mtd_registered = true;return ret; } -void spi_flash_mtd_unregister (void ) +void spi_flash_mtd_unregister (struct spi_flash *flash) { +struct mtd_info *mtd = &flash->mtd;int ret;if (!sf_mtd_registered)return ; - ret =del_mtd_device (&sf_mtd_info); + ret =del_mtd_device (mtd);if (!ret) { sf_mtd_registered = false;return ;@@ -141,7 +129,7 @@ void spi_flash_mtd_unregister(void)* use-after-free bug. Still, things should be fixed to prevent the * spi_flash object from being destroyed when del_mtd_device() fails. */ - sf_mtd_info.priv =NULL ; + mtd->priv =NULL ;printf ("Failed to unregister MTD %s and the spi_flash object is going away: you're in deep trouble!" , - sf_mtd_info.name); + sf_mtd_name); }drivers/mtd/spi/sf_probe.c +1
-1@@ -84,7 +84,7 @@ struct spi_flash *spi_flash_probe(unsigned int busnum, unsigned int cs,void spi_flash_free (struct spi_flash *flash) {#ifdef CONFIG_SPI_FLASH_MTD -spi_flash_mtd_unregister (); +spi_flash_mtd_unregister (flash);#endif spi_free_slave (flash->spi);free (flash);@@ -153,7 +153,8 @@ static int spi_flash_std_probe(struct udevice *dev)static int spi_flash_std_remove (struct udevice *dev) {
Quoted 9 lines
drivers/mtd/spi/sf_probe.c static int spi_flash_std_probe(struct udevice *dev) · line 160
Quoted 8 lines
drivers/mtd/spi/sf_probe.c +2
-1#ifdef CONFIG_SPI_FLASH_MTD -spi_flash_mtd_unregister (); +struct spi_flash *flash =dev_get_uclass_priv (dev); +spi_flash_mtd_unregister (flash);#endif return 0 ; }
Viele Grüße,
Stefan
Signature · 3 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de
Vignesh R
maintainerPATCH 10/16 configs: Get rid of SPI_FLASH_BAR
In reply to Vignesh RNow that we have new SPI NOR framework in place that supports 4 byte addressing mode by default, get rid of CONFIG_SPI_FLASH_BAR
--- arch/arm/mach-omap2/am33xx/Kconfig | 1 - configs/alt_defconfig | 1 - configs/am57xx_evm_defconfig | 1 - configs/am57xx_hs_evm_defconfig | 1 - configs/ap121_defconfig | 1 - configs/ap143_defconfig | 1 - configs/avnet_ultra96_rev1_defconfig | 1 - configs/axs101_defconfig | 1 - configs/axs103_defconfig | 1 - configs/bg0900_defconfig | 1 - configs/blanche_defconfig | 1 - configs/cl-som-am57x_defconfig | 1 - configs/clearfog_defconfig | 1 - configs/cm_t43_defconfig | 1 - configs/db-88f6820-amc_defconfig | 1 - configs/display5_defconfig | 1 - configs/display5_factory_defconfig | 1 - configs/dra7xx_evm_defconfig | 1 - configs/dra7xx_hs_evm_defconfig | 1 - configs/ds109_defconfig | 1 - configs/ds414_defconfig | 1 - configs/evb-rv1108_defconfig | 1 - configs/gose_defconfig | 1 - configs/helios4_defconfig | 1 - configs/k2g_evm_defconfig | 1 - configs/k2g_hs_evm_defconfig | 1 - configs/koelsch_defconfig | 1 - configs/lager_defconfig | 1 - configs/maxbcm_defconfig | 1 - configs/mt7629_rfb_defconfig | 1 - configs/mx6sxsabreauto_defconfig | 1 - configs/mx6sxsabresd_defconfig | 1 - configs/mx6ul_14x14_evk_defconfig | 1 - configs/mx6ul_9x9_evk_defconfig | 1 - configs/mx6ull_14x14_evk_defconfig | 1 - configs/mx6ull_14x14_evk_plugin_defconfig | 1 - configs/mx7dsabresd_qspi_defconfig | 1 - configs/porter_defconfig | 1 - configs/r8a77970_eagle_defconfig | 1 - configs/silk_defconfig | 1 - configs/socfpga_arria5_defconfig | 1 - configs/socfpga_cyclone5_defconfig | 1 - configs/socfpga_is1_defconfig | 1 - configs/socfpga_sockit_defconfig | 1 - configs/socfpga_socrates_defconfig | 1 - configs/socfpga_sr1500_defconfig | 1 - configs/socfpga_stratix10_defconfig | 1 - configs/stout_defconfig | 1 - configs/topic_miami_defconfig | 1 - configs/topic_miamilite_defconfig | 1 - configs/topic_miamiplus_defconfig | 1 - configs/xilinx_versal_virt_defconfig | 1 - configs/xilinx_zynqmp_mini_qspi_defconfig | 1 - configs/xilinx_zynqmp_zc1232_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1254_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1275_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1275_revB_defconfig | 1 - configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 - configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 - configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 1 - configs/xilinx_zynqmp_zcu100_revC_defconfig | 1 - configs/xilinx_zynqmp_zcu102_rev1_0_defconfig | 1 - configs/xilinx_zynqmp_zcu102_revA_defconfig | 1 - configs/xilinx_zynqmp_zcu102_revB_defconfig | 1 - configs/xilinx_zynqmp_zcu104_revA_defconfig | 1 - configs/xilinx_zynqmp_zcu104_revC_defconfig | 1 - configs/xilinx_zynqmp_zcu106_revA_defconfig | 1 - configs/xilinx_zynqmp_zcu111_revA_defconfig | 1 - configs/zynq_cc108_defconfig | 1 - configs/zynq_cse_qspi_defconfig | 1 - configs/zynq_dlc20_rev1_0_defconfig | 1 - configs/zynq_microzed_defconfig | 1 - configs/zynq_minized_defconfig | 1 - configs/zynq_z_turn_defconfig | 1 - configs/zynq_zc702_defconfig | 1 - configs/zynq_zc706_defconfig | 1 - configs/zynq_zc770_xm010_defconfig | 1 - configs/zynq_zc770_xm013_defconfig | 1 - configs/zynq_zed_defconfig | 1 - configs/zynq_zybo_defconfig | 1 - configs/zynq_zybo_z7_defconfig | 1 - doc/SPI/README.ti_qspi_dra_test | 1 - drivers/mtd/spi/Kconfig | 7 ------- include/configs/T102xQDS.h | 1 - include/configs/T102xRDB.h | 1 - include/configs/T104xRDB.h | 1 - include/configs/T208xQDS.h | 1 - include/configs/T208xRDB.h | 1 - include/configs/gw_ventana.h | 1 - include/configs/km/kmp204x-common.h | 1 - include/configs/ls1021aiot.h | 1 - 91 files changed, 97 deletions(-)
arch/arm/mach-omap2/am33xx/Kconfig +0 -1
@@ -229,7 +229,6 @@ config TARGET_AM43XX_EVM imply DM_I2C imply DM_SPI imply DM_SPI_FLASH - imply SPI_FLASH_BAR imply SPL_ENV_SUPPORT imply SPL_EXT_SUPPORT imply SPL_FAT_SUPPORT
configs/alt_defconfig +0 -1
@@ -65,7 +65,6 @@ CONFIG_RENESAS_SDHI=y CONFIG_MTD=y CONFIG_MTD_DEVICE=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_MTD=y CONFIG_PHY_MICREL=y
configs/am57xx_evm_defconfig +0 -1
@@ -56,7 +56,6 @@ CONFIG_DM_MMC=y CONFIG_MMC_OMAP_HS=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y
configs/am57xx_hs_evm_defconfig +0 -1
@@ -59,7 +59,6 @@ CONFIG_DM_MMC=y CONFIG_MMC_OMAP_HS=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y
configs/ap121_defconfig +0 -1
@@ -35,7 +35,6 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_ATMEL=y CONFIG_SPI_FLASH_EON=y CONFIG_SPI_FLASH_GIGADEVICE=y
configs/ap143_defconfig +0 -1
@@ -34,7 +34,6 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y # CONFIG_NET is not set CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_ATMEL=y CONFIG_SPI_FLASH_EON=y CONFIG_SPI_FLASH_GIGADEVICE=y
configs/avnet_ultra96_rev1_defconfig +0 -1
@@ -60,7 +60,6 @@ CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
configs/axs101_defconfig +0 -1
@@ -38,7 +38,6 @@ CONFIG_MMC=y CONFIG_MMC_DW=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_MTD=y CONFIG_DM_ETH=y
configs/axs103_defconfig +0 -1
@@ -38,7 +38,6 @@ CONFIG_MMC=y CONFIG_MMC_DW=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_MTD=y CONFIG_DM_ETH=y
configs/bg0900_defconfig +0 -1
@@ -32,7 +32,6 @@ CONFIG_DOS_PARTITION=y CONFIG_NAND=y CONFIG_NAND_MXS=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_MII=y CONFIG_CONS_INDEX=0
configs/blanche_defconfig +0 -1
@@ -49,7 +49,6 @@ CONFIG_MTD_NOR_FLASH=y CONFIG_FLASH_CFI_DRIVER=y CONFIG_SYS_FLASH_CFI=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SMC911X=y CONFIG_SMC911X_BASE=0x18000000
configs/cl-som-am57x_defconfig +0 -1
@@ -37,7 +37,6 @@ CONFIG_LED_STATUS_BIT=37 CONFIG_LED_STATUS_STATE=2 CONFIG_MMC_OMAP_HS=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_ATMEL=y CONFIG_SPI_FLASH_EON=y CONFIG_SPI_FLASH_GIGADEVICE=y
configs/clearfog_defconfig +0 -1
@@ -48,7 +48,6 @@ CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_MV=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_WINBOND=y CONFIG_SPI_FLASH_MTD=y CONFIG_PHY_MARVELL=y
configs/cm_t43_defconfig +0 -1
@@ -49,7 +49,6 @@ CONFIG_DM_GPIO=y CONFIG_MMC_OMAP_HS=y CONFIG_NAND=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_ATMEL=y CONFIG_SPI_FLASH_EON=y CONFIG_SPI_FLASH_GIGADEVICE=y
configs/db-88f6820-amc_defconfig +0 -1
@@ -49,7 +49,6 @@ CONFIG_SYS_I2C_MVTWSI=y CONFIG_NAND=y CONFIG_NAND_PXA3XX=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHY_MARVELL=y
configs/display5_defconfig +0 -1
@@ -64,7 +64,6 @@ CONFIG_SYS_BOOTCOUNT_ADDR=0x020CC068 CONFIG_FSL_ESDHC=y CONFIG_MTD_DEVICE=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHYLIB=y
configs/display5_factory_defconfig +0 -1
@@ -65,7 +65,6 @@ CONFIG_DFU_SF=y CONFIG_FSL_ESDHC=y CONFIG_MTD_DEVICE=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHYLIB=y
configs/dra7xx_evm_defconfig +0 -1
@@ -67,7 +67,6 @@ CONFIG_SPL_MMC_HS200_SUPPORT=y CONFIG_MMC_OMAP_HS=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_DM_ETH=y CONFIG_DRIVER_TI_CPSW=y
configs/dra7xx_hs_evm_defconfig +0 -1
@@ -65,7 +65,6 @@ CONFIG_MMC_HS200_SUPPORT=y CONFIG_MMC_OMAP_HS=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_DM_ETH=y CONFIG_DRIVER_TI_CPSW=y
configs/ds109_defconfig +0 -1
@@ -25,7 +25,6 @@ CONFIG_SYS_I2C_MVTWSI=y # CONFIG_MMC is not set CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_MVGBE=y CONFIG_MII=y
configs/ds414_defconfig +0 -1
@@ -44,7 +44,6 @@ CONFIG_SPL_OF_TRANSLATE=y # CONFIG_MMC is not set CONFIG_MTD_DEVICE=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHY_ADDR_ENABLE=y CONFIG_PHY_MARVELL=y
configs/evb-rv1108_defconfig +0 -1
@@ -29,7 +29,6 @@ CONFIG_FASTBOOT_FLASH_MMC_DEV=1 CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_SPI_FLASH_WINBOND=y CONFIG_SPI_FLASH_MTD=y
configs/gose_defconfig +0 -1
@@ -64,7 +64,6 @@ CONFIG_RENESAS_SDHI=y CONFIG_MTD=y CONFIG_MTD_DEVICE=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_MTD=y CONFIG_PHY_MICREL=y
configs/helios4_defconfig +0 -1
@@ -48,7 +48,6 @@ CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_MV=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_WINBOND=y CONFIG_PHY_GIGE=y CONFIG_MVNETA=y
configs/k2g_evm_defconfig +0 -1
@@ -42,7 +42,6 @@ CONFIG_NAND=y CONFIG_NAND_DAVINCI=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHYLIB=y
configs/k2g_hs_evm_defconfig +0 -1
@@ -35,7 +35,6 @@ CONFIG_NAND=y CONFIG_NAND_DAVINCI=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHYLIB=y
configs/koelsch_defconfig +0 -1
@@ -64,7 +64,6 @@ CONFIG_RENESAS_SDHI=y CONFIG_MTD=y CONFIG_MTD_DEVICE=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_MTD=y CONFIG_PHY_MICREL=y
configs/lager_defconfig +0 -1
@@ -66,7 +66,6 @@ CONFIG_RENESAS_SDHI=y CONFIG_MTD=y CONFIG_MTD_DEVICE=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_MTD=y CONFIG_PHY_MICREL=y
configs/maxbcm_defconfig +0 -1
@@ -33,7 +33,6 @@ CONFIG_DEFAULT_DEVICE_TREE="armada-xp-maxbcm" CONFIG_SPL_OF_TRANSLATE=y # CONFIG_MMC is not set CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
configs/mt7629_rfb_defconfig +0 -1
@@ -43,7 +43,6 @@ CONFIG_DM_GPIO=y # CONFIG_MMC is not set CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_EON=y CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_SPI_FLASH_ISSI=y
configs/mx6sxsabreauto_defconfig +0 -1
@@ -38,7 +38,6 @@ CONFIG_NAND=y CONFIG_NAND_MXS=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHYLIB=y CONFIG_MII=y
configs/mx6sxsabresd_defconfig +0 -1
@@ -40,7 +40,6 @@ CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHYLIB=y
configs/mx6ul_14x14_evk_defconfig +0 -1
@@ -45,7 +45,6 @@ CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHYLIB=y CONFIG_PHY_MICREL=y
configs/mx6ul_9x9_evk_defconfig +0 -1
@@ -45,7 +45,6 @@ CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHYLIB=y CONFIG_PHY_MICREL=y
configs/mx6ull_14x14_evk_defconfig +0 -1
@@ -32,7 +32,6 @@ CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_PINCTRL=y CONFIG_PINCTRL_IMX6=y
configs/mx6ull_14x14_evk_plugin_defconfig +0 -1
@@ -33,7 +33,6 @@ CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_PINCTRL=y CONFIG_PINCTRL_IMX6=y
configs/mx7dsabresd_qspi_defconfig +0 -1
@@ -49,7 +49,6 @@ CONFIG_MMC_HS200_SUPPORT=y CONFIG_FSL_ESDHC=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_EON=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_PHYLIB=y
configs/porter_defconfig +0 -1
@@ -64,7 +64,6 @@ CONFIG_RENESAS_SDHI=y CONFIG_MTD=y CONFIG_MTD_DEVICE=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_MTD=y CONFIG_PHY_MICREL=y
configs/r8a77970_eagle_defconfig +0 -1
@@ -43,7 +43,6 @@ CONFIG_SYS_I2C_RCAR_IIC=y # CONFIG_MMC is not set CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHY_MICREL=y
configs/silk_defconfig +0 -1
@@ -66,7 +66,6 @@ CONFIG_RENESAS_SDHI=y CONFIG_MTD=y CONFIG_MTD_DEVICE=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_MTD=y CONFIG_PHY_MICREL=y
configs/socfpga_arria5_defconfig +0 -1
@@ -51,7 +51,6 @@ CONFIG_DM_MMC=y CONFIG_MMC_DW=y CONFIG_MTD_DEVICE=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
configs/socfpga_cyclone5_defconfig +0 -1
@@ -51,7 +51,6 @@ CONFIG_DM_MMC=y CONFIG_MMC_DW=y CONFIG_MTD_DEVICE=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
configs/socfpga_is1_defconfig +0 -1
@@ -48,7 +48,6 @@ CONFIG_SYS_I2C_DW=y # CONFIG_MMC is not set CONFIG_MTD_DEVICE=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y
configs/socfpga_sockit_defconfig +0 -1
@@ -51,7 +51,6 @@ CONFIG_DM_MMC=y CONFIG_MMC_DW=y CONFIG_MTD_DEVICE=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
configs/socfpga_socrates_defconfig +0 -1
@@ -52,7 +52,6 @@ CONFIG_DM_MMC=y CONFIG_MMC_DW=y CONFIG_MTD_DEVICE=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
configs/socfpga_sr1500_defconfig +0 -1
@@ -53,7 +53,6 @@ CONFIG_DM_MMC=y CONFIG_MMC_DW=y CONFIG_MTD_DEVICE=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHY_MARVELL=y
configs/socfpga_stratix10_defconfig +0 -1
@@ -39,7 +39,6 @@ CONFIG_SYS_I2C_DW=y CONFIG_DM_MMC=y CONFIG_MMC_DW=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
configs/stout_defconfig +0 -1
@@ -64,7 +64,6 @@ CONFIG_RENESAS_SDHI=y CONFIG_MTD=y CONFIG_MTD_DEVICE=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_MTD=y CONFIG_PHY_MICREL=y
configs/topic_miami_defconfig +0 -1
@@ -40,7 +40,6 @@ CONFIG_ZYNQ_I2C1=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_DEBUG_UART_ZYNQ=y
configs/topic_miamilite_defconfig +0 -1
@@ -40,7 +40,6 @@ CONFIG_ZYNQ_I2C1=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
configs/topic_miamiplus_defconfig +0 -1
@@ -39,7 +39,6 @@ CONFIG_ZYNQ_I2C1=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
configs/xilinx_versal_virt_defconfig +0 -1
@@ -47,7 +47,6 @@ CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_mini_qspi_defconfig +0 -1
@@ -55,7 +55,6 @@ CONFIG_SPL_DM_SEQ_ALIAS=y # CONFIG_MMC is not set CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y
configs/xilinx_zynqmp_zc1232_revA_defconfig +0 -1
@@ -37,7 +37,6 @@ CONFIG_FPGA_ZYNQMPPL=y CONFIG_MISC=y CONFIG_DM_MMC=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y
configs/xilinx_zynqmp_zc1254_revA_defconfig +0 -1
@@ -37,7 +37,6 @@ CONFIG_FPGA_ZYNQMPPL=y CONFIG_MISC=y CONFIG_DM_MMC=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y
configs/xilinx_zynqmp_zc1275_revA_defconfig +0 -1
@@ -37,7 +37,6 @@ CONFIG_FPGA_ZYNQMPPL=y CONFIG_MISC=y CONFIG_DM_MMC=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y
configs/xilinx_zynqmp_zc1275_revB_defconfig +0 -1
@@ -40,7 +40,6 @@ CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y
configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig +0 -1
@@ -61,7 +61,6 @@ CONFIG_MMC_HS200_SUPPORT=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig +0 -1
@@ -58,7 +58,6 @@ CONFIG_MTD_DEVICE=y CONFIG_NAND=y CONFIG_NAND_ARASAN=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SST=y CONFIG_PHY_MARVELL=y CONFIG_PHY_NATSEMI=y
configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig +0 -1
@@ -47,7 +47,6 @@ CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zcu100_revC_defconfig +0 -1
@@ -60,7 +60,6 @@ CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zcu102_rev1_0_defconfig +0 -1
@@ -75,7 +75,6 @@ CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zcu102_revA_defconfig +0 -1
@@ -72,7 +72,6 @@ CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zcu102_revB_defconfig +0 -1
@@ -72,7 +72,6 @@ CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zcu104_revA_defconfig +0 -1
@@ -57,7 +57,6 @@ CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y
configs/xilinx_zynqmp_zcu104_revC_defconfig +0 -1
@@ -58,7 +58,6 @@ CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y
configs/xilinx_zynqmp_zcu106_revA_defconfig +0 -1
@@ -66,7 +66,6 @@ CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y
configs/xilinx_zynqmp_zcu111_revA_defconfig +0 -1
@@ -60,7 +60,6 @@ CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
configs/zynq_cc108_defconfig +0 -1
@@ -34,7 +34,6 @@ CONFIG_DM_GPIO=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_ISSI=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y
configs/zynq_cse_qspi_defconfig +0 -1
@@ -57,7 +57,6 @@ CONFIG_DEFAULT_DEVICE_TREE="zynq-cse-qspi-single" CONFIG_SPL_DM_SEQ_ALIAS=y # CONFIG_MMC is not set CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_ISSI=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y
configs/zynq_dlc20_rev1_0_defconfig +0 -1
@@ -50,7 +50,6 @@ CONFIG_ZYNQ_I2C0=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y CONFIG_PHY_REALTEK=y
configs/zynq_microzed_defconfig +0 -1
@@ -40,7 +40,6 @@ CONFIG_DM_GPIO=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y
configs/zynq_minized_defconfig +0 -1
@@ -41,7 +41,6 @@ CONFIG_DM_GPIO=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y
configs/zynq_z_turn_defconfig +0 -1
@@ -40,7 +40,6 @@ CONFIG_LED_GPIO=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y
configs/zynq_zc702_defconfig +0 -1
@@ -52,7 +52,6 @@ CONFIG_LED_GPIO=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_ISSI=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y
configs/zynq_zc706_defconfig +0 -1
@@ -52,7 +52,6 @@ CONFIG_ZYNQ_I2C0=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_ISSI=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y
configs/zynq_zc770_xm010_defconfig +0 -1
@@ -41,7 +41,6 @@ CONFIG_DM_GPIO=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_ISSI=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y
configs/zynq_zc770_xm013_defconfig +0 -1
@@ -35,7 +35,6 @@ CONFIG_FPGA_ZYNQPL=y CONFIG_DM_GPIO=y # CONFIG_MMC is not set CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_ISSI=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y
configs/zynq_zed_defconfig +0 -1
@@ -43,7 +43,6 @@ CONFIG_DM_GPIO=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y
configs/zynq_zybo_defconfig +0 -1
@@ -50,7 +50,6 @@ CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET=0xFA CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y CONFIG_PHY_REALTEK=y
configs/zynq_zybo_z7_defconfig +0 -1
@@ -47,7 +47,6 @@ CONFIG_ZYNQ_I2C1=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_REALTEK=y CONFIG_MII=y
doc/SPI/README.ti_qspi_dra_test +0 -1
@@ -22,7 +22,6 @@ Commands to erase/write u-boot/mlo to flash device -------------------------------------------------- U-Boot# sf probe 0 SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB, mapped at 5c000000 -SF: Warning - Only lower 16MiB accessible, Full access #define CONFIG_SPI_FLASH_BAR U-Boot# sf erase 0 0x10000 SF: 65536 bytes @ 0x0 Erased: OK U-Boot# sf erase 0x20000 0x10000
drivers/mtd/spi/Kconfig +0 -7
@@ -45,13 +45,6 @@ config SPI_FLASH_SFDP_SUPPORT SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP) tables as per JESD216 standard. -config SPI_FLASH_BAR - bool "SPI flash Bank/Extended address register support" - help - Enable the SPI flash Bank/Extended address register support. - Bank/Extended address registers are used to access the flash - which has size > 16MiB in 3-byte addressing. - config SF_DUAL_FLASH bool "SPI DUAL flash memory support" help
include/configs/T102xQDS.h +0 -1
@@ -501,7 +501,6 @@ unsigned long get_board_ddr_clk(void);/* * eSPI - Enhanced SPI */ -#define CONFIG_SPI_FLASH_BAR #define CONFIG_SF_DEFAULT_SPEED 10000000#define CONFIG_SF_DEFAULT_MODE 0
include/configs/T102xRDB.h +0 -1
@@ -498,7 +498,6 @@ unsigned long get_board_ddr_clk(void);/* * eSPI - Enhanced SPI */ -#define CONFIG_SPI_FLASH_BAR #define CONFIG_SF_DEFAULT_SPEED 10000000#define CONFIG_SF_DEFAULT_MODE 0
include/configs/T104xRDB.h +0 -1
@@ -521,7 +521,6 @@ $(SRCTREE)/board/freescale/t104xrdb/t1042d4_sd_rcw.cfg/* * eSPI - Enhanced SPI */ -#define CONFIG_SPI_FLASH_BAR #define CONFIG_SF_DEFAULT_SPEED 10000000#define CONFIG_SF_DEFAULT_MODE 0#define CONFIG_ENV_SPI_BUS 0
include/configs/T208xQDS.h +0 -1
@@ -497,7 +497,6 @@ unsigned long get_board_ddr_clk(void);*/ #ifdef CONFIG_SPI_FLASH -#define CONFIG_SPI_FLASH_BAR #define CONFIG_SF_DEFAULT_SPEED 10000000#define CONFIG_SF_DEFAULT_MODE 0#endif
include/configs/T208xRDB.h +0 -1
@@ -437,7 +437,6 @@ unsigned long get_board_ddr_clk(void);* eSPI - Enhanced SPI */ #ifdef CONFIG_SPI_FLASH -#define CONFIG_SPI_FLASH_BAR #define CONFIG_SF_DEFAULT_SPEED 10000000#define CONFIG_SF_DEFAULT_MODE 0#endif
include/configs/gw_ventana.h +0 -1
@@ -52,7 +52,6 @@/* SPI */ #ifdef CONFIG_CMD_SF #define CONFIG_SPI_FLASH_MTD -#define CONFIG_SPI_FLASH_BAR #define CONFIG_SF_DEFAULT_BUS 0#define CONFIG_SF_DEFAULT_CS 0/* GPIO 3-19 (21248) */
include/configs/km/kmp204x-common.h +0 -1
@@ -253,7 +253,6 @@ int get_scl(void);/* * eSPI - Enhanced SPI */ -#define CONFIG_SPI_FLASH_BAR /* 4 byte-addressing */ #define CONFIG_SF_DEFAULT_SPEED 20000000#define CONFIG_SF_DEFAULT_MODE 0
include/configs/ls1021aiot.h +0 -1
@@ -135,7 +135,6 @@#define QSPI0_AMBA_BASE 0x40000000#define FSL_QSPI_FLASH_SIZE (1 << 24)#define FSL_QSPI_FLASH_NUM 2 -#define CONFIG_SPI_FLASH_BAR #define CONFIG_SPI_FLASH_SPANSION #endif
Signature · 1 line
2.19.2
PATCH 10/16 configs: Get rid of SPI_FLASH_BAR
Quoted 3 lines · Vignesh R
Now that we have new SPI NOR framework in place that supports 4 byte addressing mode by default, get rid of
CONFIG_SPI_FLASH_BAR
I already mentioned in previous mail, BAR is not exact replacement for 4-byte. Some controllers do handle > 16MB flashes even-though controller support 3-byte addressing. we have these board since from 2014.
Better to make changes in accordance with that.
PATCH 10/16 configs: Get rid of SPI_FLASH_BAR
Quoted 9 lines · On Thu, 13 Dec 2018 02:11:48 +0530 Jagan Teki <[email protected]>…
Quoted 3 lines · Vignesh R
Now that we have new SPI NOR framework in place that supports 4 byte addressing mode by default, get rid of
CONFIG_SPI_FLASH_BARI already mentioned in previous mail, BAR is not exact replacement for 4-byte. Some controllers do handle > 16MB flashes even-though controller support 3-byte addressing. we have these board since from 2014.
That's something you should be able to detect with spi_mem_supports_op(). If the controller does not support sending 4 byte addresses, it should return -ENOTSUPP and the framework should fallback to BAR setting (if the NOR supports it). Do we really need a config option for that?
PATCH 10/16 configs: Get rid of SPI_FLASH_BAR
In reply to Jagan TekiAm Mi., 12. Dez. 2018, 21:42 hat Jagan Teki <[email protected]> geschrieben:
Quoted 11 lines · Vignesh R
Quoted 3 lines
Now that we have new SPI NOR framework in place that supports 4 byte addressing mode by default, get rid of
CONFIG_SPI_FLASH_BARI already mentioned in previous mail, BAR is not exact replacement for 4-byte. Some controllers do handle > 16MB flashes even-though controller support 3-byte addressing. we have these board since from 2014.
Better to make changes in accordance with that.
While BAR is one possibility to address > 16 MiB, I think it's about the worst solution. So it's ok for boards that support no other methods, but how do we ensure it's only used for those and not the default?
Regards,
Simon
Vignesh R
maintainerPATCH 10/16 configs: Get rid of SPI_FLASH_BAR
In reply to Jagan TekiQuoted 5 lines · Jagan Teki
Quoted 3 lines · Vignesh R
Now that we have new SPI NOR framework in place that supports 4 byte addressing mode by default, get rid of
CONFIG_SPI_FLASH_BAR
Quoted 7 lines
I already mentioned in previous mail, BAR is not exact replacement for 4-byte. Some controllers do handle > 16MB flashes even-though controller support 3-byte addressing. we have these board since from 2014.
Better to make changes in accordance with that.
Hmm, could you point to such SPI controller drivers?
I can work on adding a fallback and enable FLASH_BAR support only for such SoC/Board. We dont want to enable this support for all.
Signature · 2 lines
Regards Vignesh
Vignesh R
maintainerPATCH 11/16 configs: Remove SF_DUAL_FLASH
In reply to Vignesh RSF_DUAL_FLASH claims to enable support for SF_DUAL_STACKED_FLASH and SF_DUAL_PARALLEL_FLASH. But, in current U-Boot code, grepping for above enums yield no user and therefore support seems to be incomplete. Remove these configs so as to avoid confusion.
--- configs/topic_miamilite_defconfig | 1 - configs/topic_miamiplus_defconfig | 1 - configs/xilinx_zynqmp_mini_qspi_defconfig | 1 - configs/xilinx_zynqmp_zc1232_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1254_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1275_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1275_revB_defconfig | 1 - configs/xilinx_zynqmp_zcu104_revA_defconfig | 1 - configs/xilinx_zynqmp_zcu104_revC_defconfig | 1 - configs/xilinx_zynqmp_zcu106_revA_defconfig | 1 - doc/SPI/README.dual-flash | 92 --------------------- drivers/mtd/spi/Kconfig | 6 -- include/configs/socfpga_stratix10_socdk.h | 1 - 13 files changed, 109 deletions(-) delete mode 100644 doc/SPI/README.dual-flash
configs/topic_miamilite_defconfig +0 -1
@@ -40,7 +40,6 @@ CONFIG_ZYNQ_I2C1=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_DEBUG_UART_ZYNQ=y
configs/topic_miamiplus_defconfig +0 -1
@@ -39,7 +39,6 @@ CONFIG_ZYNQ_I2C1=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set # CONFIG_NETDEVICES is not set
configs/xilinx_zynqmp_mini_qspi_defconfig +0 -1
@@ -55,7 +55,6 @@ CONFIG_SPL_DM_SEQ_ALIAS=y # CONFIG_MMC is not set CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zc1232_revA_defconfig +0 -1
@@ -37,7 +37,6 @@ CONFIG_FPGA_ZYNQMPPL=y CONFIG_MISC=y CONFIG_DM_MMC=y CONFIG_SPI_FLASH=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zc1254_revA_defconfig +0 -1
@@ -37,7 +37,6 @@ CONFIG_FPGA_ZYNQMPPL=y CONFIG_MISC=y CONFIG_DM_MMC=y CONFIG_SPI_FLASH=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zc1275_revA_defconfig +0 -1
@@ -37,7 +37,6 @@ CONFIG_FPGA_ZYNQMPPL=y CONFIG_MISC=y CONFIG_DM_MMC=y CONFIG_SPI_FLASH=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zc1275_revB_defconfig +0 -1
@@ -40,7 +40,6 @@ CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zcu104_revA_defconfig +0 -1
@@ -57,7 +57,6 @@ CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zcu104_revC_defconfig +0 -1
@@ -58,7 +58,6 @@ CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zcu106_revA_defconfig +0 -1
@@ -66,7 +66,6 @@ CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y
doc/SPI/README.dual-flash deleted +0 -92
92 lines not on this page · raw message
drivers/mtd/spi/Kconfig +0 -6
@@ -45,12 +45,6 @@ config SPI_FLASH_SFDP_SUPPORT SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP) tables as per JESD216 standard. -config SF_DUAL_FLASH - bool "SPI DUAL flash memory support" - help - Enable this option to support two flash memories connected to a single - controller. Currently Xilinx Zynq qspi supports this. - config SPI_FLASH_ATMEL bool "Atmel SPI flash support" help
include/configs/socfpga_stratix10_socdk.h +0 -1
@@ -57,7 +57,6 @@*/ #ifdef CONFIG_CADENCE_QSPI /* Enable it if you want to use dual-stacked mode */ -#undef CONFIG_SF_DUAL_FLASH/*#define CONFIG_QSPI_RBF_ADDR 0x720000*/ /* Flash device info */
Signature · 1 line
2.19.2
PATCH 11/16 configs: Remove SF_DUAL_FLASH
Quoted 7 lines · Vignesh R
SF_DUAL_FLASHclaims to enable support forSF_DUAL_STACKED_FLASHandSF_DUAL_PARALLEL_FLASH. But, in current U-Boot code, grepping for above enums yield no user and therefore support seems to be incomplete. Remove these configs so as to avoid confusion.Signed-off-by Vignesh R <[email protected]>
Quoted 16 lines
--- configs/topic_miamilite_defconfig | 1 - configs/topic_miamiplus_defconfig | 1 - configs/xilinx_zynqmp_mini_qspi_defconfig | 1 - configs/xilinx_zynqmp_zc1232_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1254_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1275_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1275_revB_defconfig | 1 - configs/xilinx_zynqmp_zcu104_revA_defconfig | 1 - configs/xilinx_zynqmp_zcu104_revC_defconfig | 1 - configs/xilinx_zynqmp_zcu106_revA_defconfig | 1 - doc/SPI/README.dual-flash | 92 --------------------- drivers/mtd/spi/Kconfig | 6 -- include/configs/socfpga_stratix10_socdk.h | 1 - 13 files changed, 109 deletions(-) delete mode 100644 doc/SPI/README.dual-flash
dual flash has used boards, even though spi driver can't enable it. I asked Siva, and(Michal) about the updates. we have some drivers and code in tree even-thought the relevant users out-of tree.
Siva., Michal any inputs?
Vignesh R
maintainerPATCH 12/16 axm_defconfig: Enable simple malloc in SPL
In reply to Vignesh REnable CONFIG_SPL_SYS_MALLOC_SIMPLE in SPL to reduce SPL size
--- configs/axm_defconfig | 1 + 1 file changed, 1 insertion(+)
configs/axm_defconfig +1 -0
@@ -44,3 +44,4 @@ CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHYLIB=y CONFIG_USE_TINY_PRINTF=y +CONFIG_SPL_SYS_MALLOC_SIMPLE=y
Signature · 1 line
2.19.2
Vignesh R
maintainerPATCH 13/16 taurus_defconfig: Enable simple malloc in SPL
In reply to Vignesh REnable SPL simple malloc to reduce SPL size
--- configs/taurus_defconfig | 1 + 1 file changed, 1 insertion(+)
configs/taurus_defconfig +1 -0
@@ -64,3 +64,4 @@ CONFIG_USE_TINY_PRINTF=y CONFIG_WDT=y CONFIG_WDT_AT91=y CONFIG_AT91_HW_WDT_TIMEOUT=y +CONFIG_SPL_SYS_MALLOC_SIMPLE=y
Signature · 1 line
2.19.2
Vignesh R
maintainerPATCH 14/16 da850_am18xxevm: Enable tiny printf
In reply to Vignesh REnable tiny printf to reduce SPL size
--- configs/da850_am18xxevm_defconfig | 1 + 1 file changed, 1 insertion(+)
configs/da850_am18xxevm_defconfig +1 -0
@@ -57,3 +57,4 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_DAVINCI_SPI=y # CONFIG_FAT_WRITE is not set +CONFIG_USE_TINY_PRINTF=y
Signature · 1 line
2.19.2
Vignesh R
maintainerPATCH 15/16 turris_omnia_defconfig: Enable tiny printf
In reply to Vignesh REnable tiny printf to reduce SPL size
--- configs/turris_omnia_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
configs/turris_omnia_defconfig +1 -1
@@ -52,6 +52,6 @@ CONFIG_KIRKWOOD_SPI=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_EHCI_HCD=y -CONFIG_USB_STORAGE=y CONFIG_WDT=y CONFIG_WDT_ORION=y +CONFIG_USE_TINY_PRINTF=y
Signature · 1 line
2.19.2
Vignesh R
maintainerPATCH 16/16 MAINTAINERS: Add an entry for SPI NOR
In reply to Vignesh RAdd myself as co-maintainer for U-Boot SPI NOR subsystem
---
Jagan,
If you agree, I can help in co-maintaining SPI NOR part especially for the code that is added/sync'd from Linux.
MAINTAINERS | 8 ++++++++ 1 file changed, 8 insertions(+)
MAINTAINERS +8 -0
@@ -634,6 +634,14 @@ F: drivers/mtd/spi/ F: drivers/spi/ F: include/spi* +SPI-NOR +M: Vignesh R <[email protected]> +S: Maintained +F: drivers/mtd/spi/ +F: include/spi_flash.h +F: include/linux/mtd/cfi.h +F: include/linux/mtd/spi-nor.h + SPMI M: Mateusz Kulikowski <[email protected]> S: Maintained
Signature · 1 line
2.19.2
PATCH 16/16 MAINTAINERS: Add an entry for SPI NOR
Quoted 9 lines · Vignesh R
Add myself as co-maintainer for U-Boot SPI NOR subsystem
Signed-off-by Vignesh R <[email protected]>---
Jagan,If you agree, I can help in co-maintaining SPI NOR part especially for the code that is added/sync'd from Linux.
Thanks for the help and support.
MAINTAINERS F: drivers/mtd/spi/ · line 637
Quoted 13 lines
MAINTAINERS | 8 ++++++++ 1 file changed, 8 insertions(+)MAINTAINERS +1
-0@@ -634,6 +634,14 @@ F: drivers/mtd/spi/ F: drivers/spi/ F: include/spi* +SPI-NOR
You missed my name :)
Quoted 6 lines
MAINTAINERS +6
-0+M: Vignesh R <[email protected]> +S: Maintained +F: drivers/mtd/spi/ +F: include/spi_flash.h +F: include/linux/mtd/cfi.h +F: include/linux/mtd/spi-nor.h
Vignesh R
maintainerPATCH 16/16 MAINTAINERS: Add an entry for SPI NOR
Quoted 26 lines · Jagan Teki
Quoted 9 lines · On Wed, Dec 12, 2018 at 11:19 PM Vignesh R <[email protected]…
Add myself as co-maintainer for U-Boot SPI NOR subsystem
Signed-off-by Vignesh R <vigneshr at ti.com <mailto:[email protected]>>---
Jagan,If you agree, I can help in co-maintaining SPI NOR part especially for the code that is added/sync'd from Linux.
Thanks for the help and support.
Quoted 12 lines
MAINTAINERS| 8 ++++++++1 file changed, 8 insertions(+)MAINTAINERS +0
-0@@ -634,6 +634,14 @@ F: drivers/mtd/spi/F: drivers/spi/
F: include/spi*
Quoted 4 lines
Quoted 1 line
+SPI-NOR
You missed my name :)
Sorry, I thought regex under SPI entry would cover all. Anyways, will add your name here as well.
Quoted 6 lines
Quoted 6 lines
MAINTAINERS +6
-0+M: Vignesh R <vigneshr at ti.com <mailto:[email protected]>> +S: Maintained +F: drivers/mtd/spi/ +F: include/spi_flash.h +F: include/linux/mtd/cfi.h +F: include/linux/mtd/spi-nor.h
Signature · 2 lines
Regards Vignesh
cover SF: Migrate to Linux SPI NOR framework
In reply to Vignesh RQuoted 19 lines · Vignesh R
U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
This patch series syncs SPI NOR framework from Linux v4.19. It also adds spi-mem support on top.
So, we gain 4byte addressing support and SFDP support. This makes migrating to U-Boot MTD framework easier.Tested with few Spansion, micron and macronix flashes with TI's dra7xx, k2g, am43xx EVMs. I dont have access to flashes from other vendors. So, I would greatly appreciate testing on other platforms. Complete series with dependencies here[1]
Quoted 7 lines
For clean build on some platforms, depends on
CONFIG_SPI_FLASHmigration to defconfigs [2][1] https://github.com/r-vignesh/u-boot.git branch: spi-nor-mig-patch-v1
[2] https://patchwork.ozlabs.org/patch/1007485/Patch 12-15 are compile tested.
Fist of all thanks for your time and work on this.
Since most of the discussion on the individual patches seems similar, repeat and never ended. I'm trying to summarize my comments here.
1) You can sync or add new features by grabbing the code from Linux, but I don't recommend __UBOOT macro or any Linux specific stuff in drivers/mtd/spi
2) For BAR support, lets place it as it is and support via spi-nor
3) For dual flash, wait for Xilinx developers if they really want to support it?
4) For non-dm code in spi-mem, no comments? (Tom is already commented, may be Simon can comment)
Jagan.
Vignesh R
maintainercover SF: Migrate to Linux SPI NOR framework
Quoted 28 lines · Jagan Teki
Quoted 19 lines · Vignesh R
U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
This patch series syncs SPI NOR framework from Linux v4.19. It also adds spi-mem support on top.
So, we gain 4byte addressing support and SFDP support. This makes migrating to U-Boot MTD framework easier.Tested with few Spansion, micron and macronix flashes with TI's dra7xx, k2g, am43xx EVMs. I dont have access to flashes from other vendors. So, I would greatly appreciate testing on other platforms. Complete series with dependencies here[1]
Quoted 7 lines
For clean build on some platforms, depends on
CONFIG_SPI_FLASHmigration to defconfigs [2][1] https://github.com/r-vignesh/u-boot.git branch: spi-nor-mig-patch-v1
[2] https://patchwork.ozlabs.org/patch/1007485/Patch 12-15 are compile tested.
Quoted 7 lines
Fist of all thanks for your time and work on this.
Since most of the discussion on the individual patches seems similar, repeat and never ended. I'm trying to summarize my comments here.
1) You can sync or add new features by grabbing the code from Linux, but I don't recommend__UBOOTmacro or any Linux specific stuff indrivers/mtd/spi
I am fine either way.
Quoted 1 line
2) For BAR support, lets place it as it is and support via spi-nor
Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems like 4 byte addressing (stateless dedicated opcode or with enter/exit 4 byte mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining when it may not be needed.
But if you insist, I just have to add BAR support back.
Quoted 1 line
3) For dual flash, wait for Xilinx developers if they really want to support it?
Sorry, this feature was never supported properly *in mainline U-Boot*. If support is needed in the future, we can accept patches on top of new framework.
Quoted 3 lines
4) For non-dm code in spi-mem, no comments? (Tom is already commented, may be Simon can comment)
Signature · 2 lines
Regards Vignesh
cover SF: Migrate to Linux SPI NOR framework
Am Fr., 14. Dez. 2018, 16:59 hat Vignesh R <[email protected]> geschrieben:
Quoted 51 lines · Jagan Teki
Quoted 4 lines · Vignesh R
Quoted 3 lines
U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different
types of
Quoted 16 lines
Quoted 16 lines
quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
This patch series syncs SPI NOR framework from Linux v4.19. It also adds spi-mem support on top.
So, we gain 4byte addressing support and SFDP support. This makes migrating to U-Boot MTD framework easier.Tested with few Spansion, micron and macronix flashes with TI's dra7xx, k2g, am43xx EVMs. I dont have access to flashes from other vendors. So, I would greatly appreciate testing on other platforms. Complete series with dependencies here[1]
Quoted 4 lines
Quoted 4 lines
For clean build on some platforms, depends on
CONFIG_SPI_FLASHmigration to defconfigs [2][1] https://github.com/r-vignesh/u-boot.git branch:
spi-nor-mig-patch-v1
Quoted 11 lines
Quoted 3 lines
[2] https://patchwork.ozlabs.org/patch/1007485/
Patch 12-15 are compile tested.
Fist of all thanks for your time and work on this.
Since most of the discussion on the individual patches seems similar, repeat and never ended. I'm trying to summarize my comments here.
1) You can sync or add new features by grabbing the code from Linux, but I don't recommend__UBOOTmacro or any Linux specific stuff indrivers/mtd/spiI am fine either way.
Quoted 1 line
2) For BAR support, lets place it as it is and support via spi-nor
Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems like 4 byte addressing (stateless dedicated opcode or with enter/exit 4 byte mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining when it may not be needed.
Quoted 2 lines
But if you insist, I just have to add BAR support back.
But if we do that, could we please have a config option so that I can somehow ensure only 4 byte opcoses are used that don't change some state in the chip?
BTW, should I re-read this series or is it equal to the RFC I tested?
Simon
Quoted 20 lines
Quoted 1 line
3) For dual flash, wait for Xilinx developers if they really want to
support it?
Sorry, this feature was never supported properly *in mainline U-Boot*. If support is needed in the future, we can accept patches on top of new framework.
Quoted 3 lines
4) For non-dm code in spi-mem, no comments? (Tom is already commented, may be Simon can comment)
--
Regards
Vignesh
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot
Vignesh R
maintainercover SF: Migrate to Linux SPI NOR framework
Quoted 64 lines · Simon Goldschmidt
Am Fr., 14. Dez. 2018, 16:59 hat Vignesh R <[email protected] <mailto:[email protected]>> geschrieben:
On 14/12/18 3:43 PM, Jagan Teki wrote:
> On Wed, Dec 12, 2018 at 11:02 PM Vignesh R <[email protected] <mailto:[email protected]>> wrote:
>>
>> U-Boot SPI NOR support (sf layer) is quite outdated as it does not >> support 4 byte addressing opcodes, SFDP table parsing and different types of
>> quad mode enable sequences. Many newer flashes no longer support BANK >> registers used by sf layer to a access >16MB space.
>> Also, many SPI controllers have special MMIO interfaces which provide >> accelerated read/write access but require knowledge of flash parameters
>> to make use of it. Recent spi-mem layer provides a way to support such
>> flashes but sf layer isn't using that.
>> This patch series syncs SPI NOR framework from Linux v4.19. It also adds
>> spi-mem support on top.
>> So, we gain 4byte addressing support and SFDP support. This makes >> migrating to U-Boot MTD framework easier.
>>
>> Tested with few Spansion, micron and macronix flashes with TI's dra7xx,
>> k2g, am43xx EVMs. I dont have access to flashes from other vendors. So,
>> I would greatly appreciate testing on other platforms. Complete series
>> with dependencies here[1]
>>
>> For clean build on some platforms, depends onCONFIG_SPI_FLASHmigration
>> to defconfigs [2]
>>
>> [1] https://github.com/r-vignesh/u-boot.git branch:
spi-nor-mig-patch-v1
>> [2] https://patchwork.ozlabs.org/patch/1007485/
>>
>> Patch 12-15 are compile tested.
>
> Fist of all thanks for your time and work on this.
>
> Since most of the discussion on the individual patches seems similar, > repeat and never ended. I'm trying to summarize my comments here. > 1) You can sync or add new features by grabbing the code from Linux, > but I don't recommend__UBOOTmacro or any Linux specific stuff in >drivers/mtd/spiI am fine either way.
> 2) For BAR support, lets place it as it is and support via spi-nor
Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems like 4 byte addressing (stateless dedicated opcode or with enter/exit 4 byte mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining when it may not be needed.
Quoted 7 lines
But if you insist, I just have to add BAR support back.
But if we do that, could we please have a config option so that I can somehow ensure only 4 byte opcoses are used that don't change some state in the chip?
I am afraid BAR support would be the default as Jagan suggests not to change existing behavior. You would have to disable SPI_FLASH_BAR to use 4 Byte addressing opcodes.
Quoted 2 lines
BTW, should I re-read this series or is it equal to the RFC I tested?
Nope, its same as that branch you gave Tested-by to(sorry forgot to carry the tag here). But I may have to do one more revision if above change is needed.
Regards
Vignesh
Quoted 23 lines
Simon
Quoted 1 line
3) For dual flash, wait for Xilinx developers if they really want
to support it?
Sorry, this feature was never supported properly *in mainline U-Boot*. If support is needed in the future, we can accept patches on top of new framework.
> 4) For non-dm code in spi-mem, no comments? (Tom is already commented, > may be Simon can comment)
>--
Regards
Vignesh
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de <mailto:[email protected]>
https://lists.denx.de/listinfo/u-boot
cover SF: Migrate to Linux SPI NOR framework
Am Fr., 14. Dez. 2018, 17:28 hat Vignesh R <[email protected]> geschrieben:
Quoted 76 lines · Simon Goldschmidt
Quoted 5 lines
Am Fr., 14. Dez. 2018, 16:59 hat Vignesh R <[email protected] <mailto:[email protected]>> geschrieben:
Quoted 8 lines
On 14/12/18 3:43 PM, Jagan Teki wrote:
> On Wed, Dec 12, 2018 at 11:02 PM Vignesh R <[email protected] <mailto:[email protected]>> wrote:
>>
>> U-Boot SPI NOR support (sf layer) is quite outdated as it does not >> support 4 byte addressing opcodes, SFDP table parsing and different types of
>> quad mode enable sequences. Many newer flashes no longer supportBANK
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
registers used by sf layer to a access >16MB space. Also, many SPI controllers have special MMIO interfaces which
provide
Quoted 27 lines
Quoted 1 line
Quoted 1 line
accelerated read/write access but require knowledge of flash
parameters
>> to make use of it. Recent spi-mem layer provides a way to support such
>> flashes but sf layer isn't using that.
>> This patch series syncs SPI NOR framework from Linux v4.19. It also adds
>> spi-mem support on top.
>> So, we gain 4byte addressing support and SFDP support. This makes >> migrating to U-Boot MTD framework easier.
>>
>> Tested with few Spansion, micron and macronix flashes with TI's dra7xx,
>> k2g, am43xx EVMs. I dont have access to flashes from other vendors. So,
>> I would greatly appreciate testing on other platforms. Complete series
>> with dependencies here[1]
>>
>> For clean build on some platforms, depends onCONFIG_SPI_FLASHmigration
>> to defconfigs [2]
>>
>> [1] https://github.com/r-vignesh/u-boot.git branch:
spi-nor-mig-patch-v1
>> [2] https://patchwork.ozlabs.org/patch/1007485/
>>Quoted 5 lines
>> Patch 12-15 are compile tested.
>
> Fist of all thanks for your time and work on this. >
> Since most of the discussion on the individual patches seemssimilar,
Quoted 2 lines
Quoted 2 lines
repeat and never ended. I'm trying to summarize my comments here.
1) You can sync or add new features by grabbing the code fromLinux,
Quoted 9 lines
Quoted 2 lines
but I don't recommend
__UBOOTmacro or any Linux specific stuff indrivers/mtd/spiI am fine either way.
> 2) For BAR support, lets place it as it is and support via spi-nor
Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems
like 4
Quoted 4 lines
byte addressing (stateless dedicated opcode or with enter/exit 4 byte mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintainingwhen
Quoted 5 lines
it may not be needed.
But if you insist, I just have to add BAR support back.
Quoted 9 lines
Quoted 4 lines
But if we do that, could we please have a config option so that I can somehow ensure only 4 byte opcoses are used that don't change some state in the chip?
I am afraid BAR support would be the default as Jagan suggests not to change existing behavior. You would have to disable
SPI_FLASH_BARto use 4 Byte addressing opcodes.
Honestly, I don't like the idea of making BAR the default. Why can't we go the Linux way and enable BAR (maybe then as default) for boards that need it only?
Quoted 7 lines
Quoted 2 lines
BTW, should I re-read this series or is it equal to the RFC I tested?
Nope, its same as that branch you gave Tested-by to(sorry forgot to carry the tag here). But I may have to do one more revision if above change is needed.
Ok, thanks.
Regards,
Simon
Quoted 30 lines
Regards
VigneshQuoted 7 lines
Simon
Quoted 1 line
3) For dual flash, wait for Xilinx developers if they really want
to support it?
Sorry, this feature was never supported properly *in mainline
U-Boot*.
Quoted 1 line
If support is needed in the future, we can accept patches on top of
new
Quoted 3 lines
framework.
> 4) For non-dm code in spi-mem, no comments? (Tom is already
commented,
Quoted 12 lines
Quoted 2 lines
may be Simon can comment)
--
Regards
Vignesh
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de <mailto:[email protected]>
https://lists.denx.de/listinfo/u-boot
Vignesh R
maintainercover SF: Migrate to Linux SPI NOR framework
Quoted 25 lines
Quoted 2 lines
> 2) For BAR support, lets place it as it is and support via
spi-nor
Quoted 3 lines
Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it
seems like 4
> byte addressing (stateless dedicated opcode or with enter/exit 4 byte
> mode) seems to be standard.
> Also, Linux doesn't support BAR and haven't seen any request for BAR
> support. Why support additional feature and burden of maintaining when
> it may not be needed.
>
> But if you insist, I just have to add BAR support back. >
>
> But if we do that, could we please have a config option so that I can > somehow ensure only 4 byte opcoses are used that don't change some state
> in the chip?
>
Quoted 9 lines
I am afraid BAR support would be the default as Jagan suggests not to change existing behavior. You would have to disable
SPI_FLASH_BARto use 4 Byte addressing opcodes.Honestly, I don't like the idea of making BAR the default. Why can't we go the Linux way and enable BAR (maybe then as default) for boards that need it only?
Jagan, would that be acceptable?
Regards
Vignesh
cover SF: Migrate to Linux SPI NOR framework
Quoted 31 lines · Vignesh R
Quoted 31 lines
Quoted 3 lines
Quoted 3 lines
2) For BAR support, lets place it as it is and support via
spi-nor
Quoted 3 lines
Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it
seems like 4
> byte addressing (stateless dedicated opcode or with enter/exit
4 byte
> mode) seems to be standard.
> Also, Linux doesn't support BAR and haven't seen any request
for BAR
> support. Why support additional feature and burden of
maintaining when
> it may not be needed.
>
> But if you insist, I just have to add BAR support back.
>
>
> But if we do that, could we please have a config option so that I can > somehow ensure only 4 byte opcoses are used that don't change some state
> in the chip?
>I am afraid BAR support would be the default as Jagan suggests not to change existing behavior. You would have to disable
SPI_FLASH_BARto use 4 Byte addressing opcodes.
Quoted 6 lines
Quoted 4 lines
Honestly, I don't like the idea of making BAR the default. Why can't we go the Linux way and enable BAR (maybe then as default) for boards that need it only?
Jagan, would that be acceptable?
Better way to have some controller flag to check we go with 3-byte or 4-byte addressing if flash > 16MiB. anyway let me give some time, will come back for the better to way to go this. ofcourse CONFIG would require if BAR handling code occupy more foot-print, but we have to enable based some controller indication.
cover SF: Migrate to Linux SPI NOR framework
Quoted 38 lines · Jagan Teki
Quoted 36 lines · Vignesh R
Quoted 35 lines
Quoted 3 lines
Quoted 3 lines
2) For BAR support, lets place it as it is and support via
spi-nor
Quoted 3 lines
Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it
seems like 4
> byte addressing (stateless dedicated opcode or with enter/exit
4 byte
> mode) seems to be standard.
> Also, Linux doesn't support BAR and haven't seen any request
for BAR
> support. Why support additional feature and burden of
maintaining when
> it may not be needed.
>
> But if you insist, I just have to add BAR support back.
>
>
> But if we do that, could we please have a config option so that I can > somehow ensure only 4 byte opcoses are used that don't change some state
> in the chip?
>I am afraid BAR support would be the default as Jagan suggests not to change existing behavior. You would have to disable
SPI_FLASH_BARto use 4 Byte addressing opcodes.Honestly, I don't like the idea of making BAR the default. Why can't we go the Linux way and enable BAR (maybe then as default) for boards that need it only?
Quoted 7 lines
Quoted 1 line
Jagan, would that be acceptable?
Better way to have some controller flag to check we go with 3-byte or 4-byte addressing if flash > 16MiB. anyway let me give some time, will come back for the better to way to go this. ofcourse CONFIG would require if BAR handling code occupy more foot-print, but we have to enable based some controller indication.
another approach can be do some sanity transfer if the flash > 16MiB with 4-byte addressing failure can lead to enable BAR.
cover SF: Migrate to Linux SPI NOR framework
In reply to Vignesh RQuoted 70 lines · Vignesh R
Quoted 67 lines · Simon Goldschmidt
Am Fr., 14. Dez. 2018, 16:59 hat Vignesh R <[email protected] <mailto:[email protected]>> geschrieben:
On 14/12/18 3:43 PM, Jagan Teki wrote:
> On Wed, Dec 12, 2018 at 11:02 PM Vignesh R <[email protected] <mailto:[email protected]>> wrote:
>>
>> U-Boot SPI NOR support (sf layer) is quite outdated as it does not >> support 4 byte addressing opcodes, SFDP table parsing and different types of
>> quad mode enable sequences. Many newer flashes no longer support BANK >> registers used by sf layer to a access >16MB space.
>> Also, many SPI controllers have special MMIO interfaces which provide >> accelerated read/write access but require knowledge of flash parameters
>> to make use of it. Recent spi-mem layer provides a way to support such
>> flashes but sf layer isn't using that.
>> This patch series syncs SPI NOR framework from Linux v4.19. It also adds
>> spi-mem support on top.
>> So, we gain 4byte addressing support and SFDP support. This makes >> migrating to U-Boot MTD framework easier.
>>
>> Tested with few Spansion, micron and macronix flashes with TI's dra7xx,
>> k2g, am43xx EVMs. I dont have access to flashes from other vendors. So,
>> I would greatly appreciate testing on other platforms. Complete series
>> with dependencies here[1]
>>
>> For clean build on some platforms, depends onCONFIG_SPI_FLASHmigration
>> to defconfigs [2]
>>
>> [1] https://github.com/r-vignesh/u-boot.git branch:
spi-nor-mig-patch-v1
>> [2] https://patchwork.ozlabs.org/patch/1007485/
>>
>> Patch 12-15 are compile tested.
>
> Fist of all thanks for your time and work on this.
>
> Since most of the discussion on the individual patches seems similar, > repeat and never ended. I'm trying to summarize my comments here. > 1) You can sync or add new features by grabbing the code from Linux, > but I don't recommend__UBOOTmacro or any Linux specific stuff in >drivers/mtd/spiI am fine either way.
> 2) For BAR support, lets place it as it is and support via spi-nor
Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems like 4 byte addressing (stateless dedicated opcode or with enter/exit 4 byte mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining when it may not be needed.But if you insist, I just have to add BAR support back.
Quoted 8 lines
Quoted 4 lines
But if we do that, could we please have a config option so that I can somehow ensure only 4 byte opcoses are used that don't change some state in the chip?
I am afraid BAR support would be the default as Jagan suggests not to change existing behavior. You would have to disable
SPI_FLASH_BARto use 4 Byte addressing opcodes.
Please don't make SPI_FLASH_BAR support the default. It never was enabled per default until now IIRC.
Thanks,
Stefan
cover SF: Migrate to Linux SPI NOR framework
In reply to Vignesh RQuoted 50 lines · Vignesh R
Quoted 28 lines · Jagan Teki
Quoted 19 lines · Vignesh R
U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
This patch series syncs SPI NOR framework from Linux v4.19. It also adds spi-mem support on top.
So, we gain 4byte addressing support and SFDP support. This makes migrating to U-Boot MTD framework easier.Tested with few Spansion, micron and macronix flashes with TI's dra7xx, k2g, am43xx EVMs. I dont have access to flashes from other vendors. So, I would greatly appreciate testing on other platforms. Complete series with dependencies here[1]
Quoted 7 lines
For clean build on some platforms, depends on
CONFIG_SPI_FLASHmigration to defconfigs [2][1] https://github.com/r-vignesh/u-boot.git branch: spi-nor-mig-patch-v1
[2] https://patchwork.ozlabs.org/patch/1007485/Patch 12-15 are compile tested.
Quoted 7 lines
Fist of all thanks for your time and work on this.
Since most of the discussion on the individual patches seems similar, repeat and never ended. I'm trying to summarize my comments here.
1) You can sync or add new features by grabbing the code from Linux, but I don't recommend__UBOOTmacro or any Linux specific stuff indrivers/mtd/spiI am fine either way.
Quoted 1 line
2) For BAR support, lets place it as it is and support via spi-nor
Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems like 4 byte addressing (stateless dedicated opcode or with enter/exit 4 byte mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining when it may not be needed.
Quoted 1 line
But if you insist, I just have to add BAR support back.
It's not about insistence, ie how we support since from long and u-boot bootloader project does in general. bootloader can be some certain boot difference functionalities unlike Linux, it's better not to compare u-boot with Linux in all cases.
Example we have SPI_TX_BYTE which usually not supported in Linux. Since it's ich controller specific and it require for bootloader to do byte tx on that specific controller, so we supported. Same for the case with the BAR, this specific controller(or supported boards) has been in U-Boot since from long and they do upstream well. So we need to support BAR in any case or we can find any alternative to work the same functionalities. (we tried before but ended-up adding BAR)
Quoted 6 lines
Quoted 2 lines
3) For dual flash, wait for Xilinx developers if they really want to support it?
Sorry, this feature was never supported properly *in mainline U-Boot*. If support is needed in the future, we can accept patches on top of new framework.
Siva, Michael any time-line to work on this topic?
Vignesh R
maintainercover SF: Migrate to Linux SPI NOR framework
Quoted 17 lines
Quoted 11 lines
Quoted 1 line
2) For BAR support, lets place it as it is and support via spi-nor
Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems like 4 byte addressing (stateless dedicated opcode or with enter/exit 4 byte mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining when it may not be needed.But if you insist, I just have to add BAR support back.
It's not about insistence, ie how we support since from long and u-boot bootloader project does in general. bootloader can be some certain boot difference functionalities unlike Linux, it's better not to compare u-boot with Linux in all cases.
Quoted 8 lines
Example we have
SPI_TX_BYTEwhich usually not supported in Linux. Since it's ich controller specific and it require for bootloader to do byte tx on that specific controller, so we supported. Same for the case with the BAR, this specific controller(or supported boards) has been in U-Boot since from long and they do upstream well. So we need to support BAR in any case or we can find any alternative to work the same functionalities. (we tried before but ended-up adding BAR)
How about this instead?
Lets use 4 byte addressing opcodes as default for >16MB flashes. But if CONFIG_SPI_FLASH_BAR is enabled then, spi-nor layer will use BAR registers for >16MB access instead of 4 byte addressing.
I will remove SPI_FLASH_BAR from defconfigs from all boards expect those controllers that really cannot handle 4 byte addressing. From a quick glance it looks following controllers support only 3 byte addresses:stm32_qspi.cich.cfsl_qspi.crenesas_rpc_spi.cmtk_qspi.c
So, except for boards with above controllers, I will remove SPI_FLASH_BAR for all other boards. If there is a regression, then such boards can go back to enabling CONFIG_SPI_FLASH_BAR.
AFAIU, above controller HWs(except ich perhaps) can support 4 byte addressing but would need to move to spi-mem.
Regards
Vignesh
ex
cover SF: Migrate to Linux SPI NOR framework
Quoted 26 lines · Vignesh R
Quoted 18 lines
Quoted 11 lines
Quoted 2 lines
2) For BAR support, lets place it as it is and support via spi-nor
Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems like 4 byte addressing (stateless dedicated opcode or with enter/exit 4 byte mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining when it may not be needed.Quoted 1 line
But if you insist, I just have to add BAR support back.
It's not about insistence, ie how we support since from long and u-boot bootloader project does in general. bootloader can be some certain boot difference functionalities unlike Linux, it's better not to compare u-boot with Linux in all cases.
Quoted 8 lines
Example we have
SPI_TX_BYTEwhich usually not supported in Linux. Since it's ich controller specific and it require for bootloader to do byte tx on that specific controller, so we supported. Same for the case with the BAR, this specific controller(or supported boards) has been in U-Boot since from long and they do upstream well. So we need to support BAR in any case or we can find any alternative to work the same functionalities. (we tried before but ended-up adding BAR)
Quoted 5 lines
How about this instead?
Lets use 4 byte addressing opcodes as default for >16MB flashes. But if
CONFIG_SPI_FLASH_BARis enabled then, spi-nor layer will use BAR registers for >16MB access instead of 4 byte addressing.
Yes, this can be normal approach. but what I'm trying to initiate here is if we have a generic kind of sanity check transfer for > 16MB flashes, then we can notify the controllers enable BAR to support > 16MiB.
This way we can reduce the ifdefs on code, and if we handle BAR in better way to minimize the code eventually we even drop the CONFIG option.
Quoted 8 lines
I will remove
SPI_FLASH_BARfrom defconfigs from all boards expect those controllers that really cannot handle 4 byte addressing. From a quick glance it looks following controllers support only 3 byte addresses:stm32_qspi.cich.cfsl_qspi.crenesas_rpc_spi.cmtk_qspi.c
I'm not sure whether all these support 4-byte addressing or not? since we don't have 4-byte on spi-flash they do use BAR for accessing > 16MiB, zynq_qspi is the key taker for this initially.
Quoted 4 lines
So, except for boards with above controllers, I will remove
SPI_FLASH_BARfor all other boards. If there is a regression, then such boards can go back to enablingCONFIG_SPI_FLASH_BAR.
I think we can go the BAR code in flash as you mentioned with CONFIG option, and don't remove any CONFIG items from board configs then we can add sanity check patch on top of spi-nor changes and give warning to boards which never need BAR(ask them to drop CONFIG_BAR). This way transition look promising to move BAR to 4-byte addressing.
Quoted 3 lines
AFAIU, above controller HWs(except ich perhaps) can support 4 byte addressing but would need to move to spi-mem.
Even if we move to spi-mem, but BAR need to handle it flash side. isn't it?
Vignesh R
maintainercover SF: Migrate to Linux SPI NOR framework
Quoted 29 lines · Jagan Teki
Quoted 28 lines · Vignesh R
Quoted 18 lines
Quoted 11 lines
Quoted 2 lines
2) For BAR support, lets place it as it is and support via spi-nor
Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems like 4 byte addressing (stateless dedicated opcode or with enter/exit 4 byte mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining when it may not be needed.Quoted 1 line
But if you insist, I just have to add BAR support back.
It's not about insistence, ie how we support since from long and u-boot bootloader project does in general. bootloader can be some certain boot difference functionalities unlike Linux, it's better not to compare u-boot with Linux in all cases.
Quoted 8 lines
Example we have
SPI_TX_BYTEwhich usually not supported in Linux. Since it's ich controller specific and it require for bootloader to do byte tx on that specific controller, so we supported. Same for the case with the BAR, this specific controller(or supported boards) has been in U-Boot since from long and they do upstream well. So we need to support BAR in any case or we can find any alternative to work the same functionalities. (we tried before but ended-up adding BAR)How about this instead?
Quoted 9 lines
Quoted 3 lines
Lets use 4 byte addressing opcodes as default for >16MB flashes. But if
CONFIG_SPI_FLASH_BARis enabled then, spi-nor layer will use BAR registers for >16MB access instead of 4 byte addressing.Yes, this can be normal approach. but what I'm trying to initiate here is if we have a generic kind of sanity check transfer for > 16MB flashes, then we can notify the controllers enable BAR to support > 16MiB.
I guess you are saying to attempt 4 byte addressing transfers and if that fails then try using BAR? AFAIK, there is _no way_ to detect whether or not controller/flash supports 4 byte addressing and then do a fallback.
Quoted 13 lines
This way we can reduce the ifdefs on code, and if we handle BAR in better way to minimize the code eventually we even drop the CONFIG option.
Quoted 8 lines
I will remove
SPI_FLASH_BARfrom defconfigs from all boards expect those controllers that really cannot handle 4 byte addressing. From a quick glance it looks following controllers support only 3 byte addresses:stm32_qspi.cich.cfsl_qspi.crenesas_rpc_spi.cmtk_qspi.c
Quoted 1 line
I'm not sure whether all these support 4-byte addressing or not?
Just to be clear, all SPI drivers _except_ those in above list can support 4 byte addressing mode w/o any additional code change.
Quoted 3 lines
since we don't have 4-byte on spi-flash they do use BAR for accessing > 16MiB,
zynq_qspiis the key taker for this initially.
I am confused here, let me put down more details:
Access >16MB of flash memory is possible by 3 ways:
1. using dedicated 4 byte addressing opcodes
2. Send "enter 4 byte" command and then use normal commands but with 4 bytes of address
3 Provide BA24 BA25 of address via BAR register
AFAIK, all flashes support 1 or 2. But only some flashes support 3. So, the idea is to use option 1 or 2 as default and use 3 only if SPI_FLASH_BAR is enabled.
Ideally, there is _nothing_ in SPI controllers that would stop us from using 4 byte addressing because a SPI controller would have no idea of slave connected (ie. it may or may not be a flash). SPI drivers should _blindly_ send/receive dout/din buffers passed as part of spi_xfer() and not interpret these buffers as cmd/addr/data separately
So, the decision on which of the above 3 options to use should be in the SPI NOR layer and has nothing to do with SPI controller drivers.
But since spi_flash.c was always used 3 byte addressing, _some_ of the SPI controller drivers are _hard-coded_ to expect 3 byte addresses (eg.:
above 4 drivers that I mentioned) See [1] on how these drivers convert dout buffer is back to flash offset. This is because there is no way to communicate cmd/addr/data separately using spi_xfer(), but _intelligent_ SPI HW do need this information. This is not a HW limitation but more of a framework limitation.
So, thus we can classify SPI controllers into roughly two types:
1. Controllers that need to know flash specific information like opcode, address length, dummy bytes etc (controllers that supports memory mapped access to flash(or such other acceleration interface).
Such controllers should move to spi-mem (but can optionally implement spi_xfer to support non flash devices)
2. Traditional SPI controllers that are usually FIFO/shift register based and provide direct access to SPI bus will continue to use traditional SPI framework.
Moving to 4 byte addressing mode will not affect second type of SPI controllers, but will break first type of controllers that do their own address conversion logic like[1].
So my suggestion is to enable CONFIG_SPI_FLASH_BAR only for controllers to do[1] until moved to spi-mem.
From my analysis:
Quoted 7 lines
Quoted 7 lines
stm32_qspi.cich.cfsl_qspi.crenesas_rpc_spi.cmtk_qspi.cti_qspi.ccadence_quadspi.c
are candidates to move to spi-mem layer. Rest seems to be traditional SPI controllers.
AFAIU, zynq_qspi seems to be FIFO based SPI controller. Why would zynq_qspi driverneed to know whether SPI NOR layer uses BAR or not? Or did I miss something?
Quoted 11 lines
Quoted 4 lines
So, except for boards with above controllers, I will remove
SPI_FLASH_BARfor all other boards. If there is a regression, then such boards can go back to enablingCONFIG_SPI_FLASH_BAR.I think we can go the BAR code in flash as you mentioned with CONFIG option, and don't remove any CONFIG items from board configs then we can add sanity check patch on top of spi-nor changes and give warning to boards which never need
BAR(ask them to drop CONFIG_BAR). This way transition look promising to move BAR to 4-byte addressing.
Are you suggesting board users should individually remove CONFIG_SPI_FLASH_BAR from defconfigs based on their judgement? How do you propose to do sanity check?
Why not use 4 byte addressing as default and enable CONFIG_SPI_FLASH_BAR only for controllers that need them?
Quoted 6 lines
Quoted 3 lines
AFAIU, above controller HWs(except ich perhaps) can support 4 byte addressing but would need to move to spi-mem.
t
Even if we move to spi-mem, but BAR need to handle it flash side. isn't it?
Yes, presence/configuration of BAR registers is abstracted by SPI NOR and spi-mem drivers need not have any knowledge.
[1]
https://elixir.bootlin.com/u-boot/latest/source/drivers/spi/renesas_rpc_spi.c#L264
https://elixir.bootlin.com/u-boot/v2019.01-rc2/source/drivers/spi/mtk_qspi.c#L253
Regards
Vignesh
cover SF: Migrate to Linux SPI NOR framework
Quoted 73 lines
-----Original Message-----
From: U-Boot <[email protected]> On Behalf Of Vignesh R
Sent: Tuesday, December 18, 2018 10:49 PM
To: Jagan Teki <[email protected]>
Cc: Marek Vasut <[email protected]>; Tom Rini <[email protected]>; U-Boot- Denx <[email protected]>; Michal Simek <[email protected]>; Siva Durga Prasad Paladugu <[email protected]>; Boris Brezillon <[email protected]>; Miquel Raynal <[email protected]>; Stefan Roese <[email protected]>; Jagan Teki <[email protected]>
Subject: Re: [U-Boot] [PATCH 00/16] SF: Migrate to Linux SPI NOR frameworkQuoted 31 lines · Jagan Teki
Quoted 30 lines · Vignesh R
Quoted 19 lines
Quoted 12 lines
Quoted 2 lines
2) For BAR support, lets place it as it is and support via spi-nor
Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems like 4 byte addressing (stateless dedicated opcode or with enter/exit 4 byte
mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining when it may not be needed.Quoted 1 line
But if you insist, I just have to add BAR support back.
It's not about insistence, ie how we support since from long and u-boot bootloader project does in general. bootloader can be some certain boot difference functionalities unlike Linux, it's better not to compare u-boot with Linux in all cases.
Quoted 9 lines
Example we have
SPI_TX_BYTEwhich usually not supported in Linux. Since it's ich controller specific and it require for bootloader to do byte tx on that specific controller, so we supported. Same for the case with the BAR, this specific controller(or supported boards) has been in U-Boot since from long and they do upstream well. So we need to support BAR in any case or we can find any alternative to work the same functionalities. (we tried before but ended-up adding BAR)How about this instead?
Quoted 9 lines
Quoted 3 lines
Lets use 4 byte addressing opcodes as default for >16MB flashes. But if
CONFIG_SPI_FLASH_BARis enabled then, spi-nor layer will use BAR registers for >16MB access instead of 4 byte addressing.Yes, this can be normal approach. but what I'm trying to initiate here is if we have a generic kind of sanity check transfer for > 16MB flashes, then we can notify the controllers enable BAR to support > 16MiB.
I guess you are saying to attempt 4 byte addressing transfers and if that fails then try using BAR? AFAIK, there is
_noway_to detect whether or not controller/flash supports 4 byte addressing and then do a fallback.Quoted 13 lines
This way we can reduce the ifdefs on code, and if we handle BAR in better way to minimize the code eventually we even drop the CONFIG option.
Quoted 8 lines
I will remove
SPI_FLASH_BARfrom defconfigs from all boards expect those controllers that really cannot handle 4 byte addressing. From a quick glance it looks following controllers support only 3 byte addresses:stm32_qspi.cich.cfsl_qspi.crenesas_rpc_spi.cmtk_qspi.c
Quoted 4 lines
Quoted 1 line
I'm not sure whether all these support 4-byte addressing or not?
Just to be clear, all SPI drivers _except_ those in above list can support 4 byte addressing mode w/o any additional code change.
fsl_qspi.c: should support 4 byte as well, since the current frame work had limitation, u-boot.denx.de version of this driver was only supporting until 16MB
Regards
Ashish
Quoted 57 lines
Quoted 4 lines
since we don't have 4-byte on spi-flash they do use BAR for accessing
Quoted 1 line
16MiB,
zynq_qspiis the key taker for this initially.I am confused here, let me put down more details:
Access >16MB of flash memory is possible by 3 ways:
1. using dedicated 4 byte addressing opcodes 2. Send "enter 4 byte" command and then use normal commands but with
4 bytes of address
3 Provide BA24 BA25 of address via BAR registerAFAIK, all flashes support 1 or 2. But only some flashes support 3. So, the idea is to use option 1 or 2 as default and use 3 only if
SPI_FLASH_BARis enabled.Ideally, there is _nothing_ in SPI controllers that would stop us from using 4 byte addressing because a SPI controller would have no idea of slave connected (ie. it may or may not be a flash). SPI drivers should _blindly_ send/receive dout/din buffers passed as part of
spi_xfer()and not interpret these buffers as cmd/addr/data separately So, the decision on which of the above 3 options to use should be in the SPI NOR layer and has nothing to do with SPI controller drivers.But since
spi_flash.cwas always used 3 byte addressing, _some_ of the SPI controller drivers are _hard-coded_ to expect 3 byte addresses (eg.:
above 4 drivers that I mentioned) See [1] on how these drivers convert dout buffer is back to flash offset. This is because there is no way to communicate cmd/addr/data separately usingspi_xfer(), but _intelligent_ SPI HW do need this information. This is not a HW limitation but more of a framework limitation.So, thus we can classify SPI controllers into roughly two types:
1. Controllers that need to know flash specific information like opcode, address length, dummy bytes etc (controllers that supports memory mapped access to flash(or such other acceleration interface).
Such controllers should move to spi-mem (but can optionally implementspi_xferto support non flash devices)2. Traditional SPI controllers that are usually FIFO/shift register based and provide direct access to SPI bus will continue to use traditional SPI framework.
Moving to 4 byte addressing mode will not affect second type of SPI controllers, but will break first type of controllers that do their own address conversion logic like[1].
So my suggestion is to enableCONFIG_SPI_FLASH_BARonly for controllers to do[1] until moved to spi-mem.From my analysis:
Quoted 7 lines
Quoted 7 lines
stm32_qspi.cich.cfsl_qspi.crenesas_rpc_spi.cmtk_qspi.cti_qspi.ccadence_quadspi.c
Quoted 2 lines
are candidates to move to spi-mem layer. Rest seems to be traditional SPI controllers.
Yes fsl_qspi.c should be moved to spi-mem layer. Similar work in being done in Linux as well.
Regards
Ashish
Quoted 60 lines
AFAIU,
zynq_qspiseems to be FIFO based SPI controller. Why wouldzynq_qspidriverneed to know whether SPI NOR layer uses BAR or not? Or did I miss something?Quoted 11 lines
Quoted 4 lines
So, except for boards with above controllers, I will remove
SPI_FLASH_BARfor all other boards. If there is a regression, then such boards can go back to enablingCONFIG_SPI_FLASH_BAR.I think we can go the BAR code in flash as you mentioned with CONFIG option, and don't remove any CONFIG items from board configs then we can add sanity check patch on top of spi-nor changes and give warning to boards which never need
BAR(ask them to drop CONFIG_BAR). This way transition look promising to move BAR to 4-byte addressing.Are you suggesting board users should individually remove
CONFIG_SPI_FLASH_BARfrom defconfigs based on their judgement? How do you propose to do sanity check?
Why not use 4 byte addressing as default and enableCONFIG_SPI_FLASH_BARonly for controllers that need them?Quoted 6 lines
Quoted 3 lines
AFAIU, above controller HWs(except ich perhaps) can support 4 byte addressing but would need to move to spi-mem.
t
Even if we move to spi-mem, but BAR need to handle it flash side. isn't it?Yes, presence/configuration of BAR registers is abstracted by SPI NOR and spi- mem drivers need not have any knowledge.
[1]
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.b
ootlin.com%2Fu- boot%2Flatest%2Fsource%2Fdrivers%2Fspi%2Frenesas_rpc_spi.c%23L264&am p;data=02%7C01%7CAshish.Kumar%40nxp.com%7Cd535d3bc013949ad15230 8d6650d0bfa%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63680 7504073361903&sdata=DpdMcJ%2F81jOOVE5MRNe6xSqgAlRGXVyvFb6C dm3ot8Q%3D&reserved=0
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.b
ootlin.com%2Fu-boot%2Fv2019.01- rc2%2Fsource%2Fdrivers%2Fspi%2Fmtk_qspi.c%23L253&data=02%7C01 %7CAshish.Kumar%40nxp.com%7Cd535d3bc013949ad152308d6650d0bfa%7 C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636807504073361903 &sdata=JprAHMDaR4DY2vZocYIP0Wfu1l9yuxrl4zveN69hVA0%3D&re served=0Regards
Vignesh
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.de
nx.de%2Flistinfo%2Fu- boot&data=02%7C01%7CAshish.Kumar%40nxp.com%7Cd535d3bc013949 ad152308d6650d0bfa%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0% 7C636807504073361903&sdata=bJBeSCBf%2BtAcF3XyUr04jB1ba4UMTS ZC%2FRSlr6qKkcA%3D&reserved=0
Vignesh R
maintainercover SF: Migrate to Linux SPI NOR framework
In reply to Jagan TekiQuoted 17 lines
Quoted 11 lines
Quoted 1 line
2) For BAR support, lets place it as it is and support via spi-nor
Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems like 4 byte addressing (stateless dedicated opcode or with enter/exit 4 byte mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining when it may not be needed.But if you insist, I just have to add BAR support back.
It's not about insistence, ie how we support since from long and u-boot bootloader project does in general. bootloader can be some certain boot difference functionalities unlike Linux, it's better not to compare u-boot with Linux in all cases.
Quoted 8 lines
Example we have
SPI_TX_BYTEwhich usually not supported in Linux. Since it's ich controller specific and it require for bootloader to do byte tx on that specific controller, so we supported. Same for the case with the BAR, this specific controller(or supported boards) has been in U-Boot since from long and they do upstream well. So we need to support BAR in any case or we can find any alternative to work the same functionalities. (we tried before but ended-up adding BAR)
How about this instead?
Lets use 4 byte addressing opcodes as default for >16MB flashes. But if CONFIG_SPI_FLASH_BAR is enabled then, spi-nor layer will use BAR registers for >16MB access instead of 4 byte addressing.
I will remove SPI_FLASH_BAR from defconfigs from all boards expect those controllers that really cannot handle 4 byte addressing. From a quick glance it looks following controllers support only 3 byte addresses:stm32_qspi.cich.cfsl_qspi.crenesas_rpc_spi.cmtk_qspi.c
So, except for boards with above controllers, I will remove SPI_FLASH_BAR for all other boards. If there is a regression, then such boards can go back to enabling CONFIG_SPI_FLASH_BAR.
AFAIU, above controller HWs(except ich) can support 4 byte addressing but would need to move to spi-mem.
Regards
Vignesh
ex