Hi Jagan, On 06-Dec-18 10:44 PM, Jagan Teki wrote: > On Tue, Dec 4, 2018 at 5:56 PM Vignesh R <[email protected]> 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. > > We(someone) has proposed this sync before, but we(at-least I) rely on > implementing via DM not direct sync to Linux.
As I said in my cover letter, U-Boot sf layer is unable to support newer flashes mainly due to lack of 4 byte addressing and proper support for MMIO capable SPI controllers. My idea of fixing this is to borrow _features_ from Linux SPI NOR "as is". All that's needed is stateless 4 byte addressing, SFDP parsing(optionally), Quad/Octal support and spi-mem like abstraction for MMIO capable Controllers. I see no point in re-coding them from ground up. Could you be more specific on what you would like to see here in DM way? I have no issues in adapting this code to any framework here in U-Boot. Linux has driver model and SPI NOR subsystem is a framework and therefore any code ported from Linux will inherently have those abstractions. The only difference I see wrt your code in branch below vs this series is SPI-NOR uclass. This can be easily achieved by moving nor->ops out of struct spi_nor into uclass abstraction. Upstream Linux is anyways merging m25p80 and spi-nor so I did not see a need for SPI NOR uclass. I am okay to change that if you insist on having it. > ofcourse other > subsystems might have doing this but I literally don't propose to do > that, since it may fire the u-boot implementation in future. > Could you explain what might be possible issues in future? I will work on it. > If you really get things up further, try to check this DM based > spi-nor here[1] and lets discuss on u-boot point-of-view. I've paused > this because of non-dm code, but I'm thinking we even re-change this > to fit MTD driver-model (this is my TODO, once spi dm migration done). > AFAICS, Non DM code is not going away anytime soon. Meanwhile, IMHO, lack of 4 byte addressing support is significantly hampering new development (as evident from number of people trying to add 4 byte addressing support.) > [1] http://git.denx.de/?p=u-boot-spi.git;a=shortlog;h=refs/heads/next-working > IIRC, last post of this branch was in January 2018. And looking at my inbox, its seems that 4 byte addressing was broken in that series. If you add 4 byte addressing + SFDP parsing logic + spi-mem support to above branch, I am pretty sure you spi-nor.c would look almost the same to whats there in this series. Regards Vignesh _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
