From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vignesh R Date: Fri, 14 Dec 2018 21:57:54 +0530 Subject: [U-Boot] [PATCH 00/16] SF: Migrate to Linux SPI NOR framework In-Reply-To: References: <20181212173228.12281-1-vigneshr@ti.com> <1cd66c4d-d37b-e48b-0a6a-6037e1d255f8@ti.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de On 14-Dec-18 9:44 PM, Simon Goldschmidt wrote: > > > Am Fr., 14. Dez. 2018, 16:59 hat Vignesh R > geschrieben: > > On 14/12/18 3:43 PM, Jagan Teki wrote: > > On Wed, Dec 12, 2018 at 11:02 PM Vignesh R > 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 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. > > > > 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 > > I 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. > > > 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. > 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 > Simon > > > > 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 > https://lists.denx.de/listinfo/u-boot >