From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Goldschmidt Date: Fri, 14 Dec 2018 17:14:14 +0100 Subject: [U-Boot] [PATCH 00/16] SF: Migrate to Linux SPI NOR framework In-Reply-To: <1cd66c4d-d37b-e48b-0a6a-6037e1d255f8@ti.com> 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="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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? BTW, should I re-read this series or is it equal to the RFC I tested? 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 >