[U-Boot] [RFC PATCH v2 00/11] SF: Migrate to Linux SPI NOR framework

[Boris Brezillon]

On Thu, 6 Dec 2018 23:55:30 +0530
Vignesh R <vigneshr at ti.com> wrote:

> On 06-Dec-18 10:44 PM, Jagan Teki wrote:
> > On Tue, Dec 4, 2018 at 5:56 PM Vignesh R <vigneshr at 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.  
> > 
> > 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.
> 

No, please don't add a SPI_NOR_UCLASS. We already have the MTD_UCLASS
which is barely used by drivers, so if anything, we should work on
converting drivers to this UCLASS and maybe automate a few more things
for MTD drivers (like MTD dev registration/deregistration [1]) instead
of adding yet another UCLASS.

If you need an example of how integration with the DM (and the MTD
UCLASS) should be been done, you can look at the SPI NAND driver [2].

[1]http://code.bulix.org/9lart9-519406
[2]http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mtd/nand/spi/core.c;h=cb8ffa3fa96a16dd40dda3553bbb171107e71df7;hb=HEAD#l1249