From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Sat, 15 Dec 2018 07:31:51 +0100 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.12.18 17:27, Vignesh R wrote: > > > 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. Please don't make SPI_FLASH_BAR support the default. It never was enabled per default until now IIRC. Thanks, Stefan