On Thu, Jan 31, 2019 at 3:54 PM Tom Rini trini@konsulko.com wrote:
On Thu, Jan 31, 2019 at 08:21:29PM +0530, Jagan Teki wrote:
On Thu, Jan 31, 2019 at 8:18 PM Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
On Thu, Jan 31, 2019 at 3:43 PM Tom Rini trini@konsulko.com wrote:
On Thu, Jan 31, 2019 at 08:10:53PM +0530, Jagan Teki wrote:
On Tue, Jan 29, 2019 at 11:19 AM Vignesh R vigneshr@ti.com wrote:
Here is the v3 of SPI NOR migration(github branch at [1]). I have retained Tested-by from v2 as this is just re split of patches and minor fixups.
Travis ci reports all green.
Change log: Since v2: Split sync up patches into smaller versions so that its easier for review. Address comments by Jagan and Simon Goldschmidt on v2. Make SPI_FLASH_TINY(read only SF stack) as default for SPL build to offset against size increase due to new code.
Since v1: Remove #ifindef __UBOOT__ Add back BAR support, but dont enable as default for all platform (see 10/11 for more details) Enable SPI_FLASH_TINY on boards where there is SPL size constraint as seen on travis ci builds. Drop sf_mtd changes for now as it seems to cause issues. v1: https://patchwork.ozlabs.org/cover/1012146/
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/
Background:
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-v3 [2] https://patchwork.ozlabs.org/patch/1007485/
Vignesh R (20): configs: Move CONFIG_SPI_FLASH into defconfigs bitops: Fix GENMASK definition for Sandbox spi: spi-mem: Allow use of spi_mem_exec_op for all SPI modes spi: spi-mem: Extend spi_mem_adjust_op_size() to honor max xfer size spi: 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: spi-nor-core: Add SPI MEM support mtd: spi: spi-nor-core: Add 4 Byte addressing support mtd: spi: spi-nor-core: Add SFDP support mtd: spi: spi-nor-core: Add back U-Boot specific features mtd: spi: sf_probe: Add "jedec,spi-nor" compatible string mtd: spi: Switch to new SPI NOR framework mtd: spi: Remove unused files mtd: spi: Add lightweight SPI flash stack for SPL spl: Kconfig: Enable SPI_FLASH_TINY by default for SPL configs: Remove SF_DUAL_FLASH configs: Don't use SPI_FLASH_BAR as default MAINTAINERS: Add an entry for SPI NOR
Except 16/20 and 19/20, all look fine to me.
Reviewed-by: Jagan Teki jagan@openedev.com Tested-by: Jagan Teki jagan@amarulasolutions.com #zynq-microzed
And based on the Xilinx folks reply to 19/20, is 16/20 something we can deal with as a follow-up? Thanks!
Going without 16/20 will increase the footprint in SPL. Given the limitation of size checks discussed recently, I don't think that would be a good idea.
Please read the my comments again, I won't oppose the change.
Ah, I think I have the numbers backwards then, I was thinking 19 was the one about BAR stuff and 16 was some style comments? But I do want to stress again that I want to see this come in and the we deal with any further fall-out, this cycle. Thanks!
You were right about 19 (BAR). But 16 contains size-improvements for SPL. The new framework as is lets SPL grow. Patch 16 introduces size improvements for SPL that are a bit unrelated to this series but help making it acceptable because it ensures this series as a whole does not grow SPL.
Oh, you meant commit 16 as is and make style changes later?
Regards, Simon