On 31/01/19 8:15 PM, Jagan Teki wrote: > On Thu, Jan 31, 2019 at 8:12 PM Tom Rini <tr...@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 <vigne...@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 <ja...@openedev.com> >>> Tested-by: Jagan Teki <ja...@amarulasolutions.com> #zynq-microzed
Thanks for all the reviews! >> >> And based on the Xilinx folks reply to 19/20, is 16/20 something we can >> deal with as a follow-up? Thanks! > > 19/20, can (If some don't believe me) and 16/20 can be fixed here. > I have replied to individual patches. In summary, 19/20 can be fixed as a follow up patch if Zynq SoCs cant really support 4 byte addressing. I will send a follow up patch to remove MODULE_LICENSE(), EXPORT_SYMBOL_GPL() macros. I dont plan to respin unless there are more objections -- Regards Vignesh _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot