Am Fr., 14. Dez. 2018, 17:28 hat Vignesh R <vigne...@ti.com> geschrieben:
> > > On 14-Dec-18 9:44 PM, Simon Goldschmidt wrote: > > > > > > Am Fr., 14. Dez. 2018, 16:59 hat Vignesh R <vigne...@ti.com > > <mailto:vigne...@ti.com>> geschrieben: > > > > On 14/12/18 3:43 PM, Jagan Teki wrote: > > > On Wed, Dec 12, 2018 at 11:02 PM Vignesh R <vigne...@ti.com > > <mailto:vigne...@ti.com>> 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. > Honestly, I don't like the idea of making BAR the default. Why can't we go the Linux way and enable BAR (maybe then as default) for boards that need it only? > > 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. > Ok, thanks. Regards, Simon > 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@lists.denx.de <mailto:U-Boot@lists.denx.de> > > https://lists.denx.de/listinfo/u-boot > > > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
