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

[Boris Brezillon]

On Mon, 10 Dec 2018 18:32:09 +0530
Jagan Teki <jagan at amarulasolutions.com> wrote:

> On Thu, Dec 6, 2018 at 11:55 PM Vignesh R <vigneshr at ti.com> wrote:
> >
> > Hi Jagan,
> >
> > 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.  
> 
> Merging or syncing spi-nor features stuff from Linux is good, I'm not
> stopping that. but this can be do by satisfying u-boot driver-model
> with proper architectural model. I know you take care but I'm not sure
> ie what can be manageable for long term.
> 
> Let's discuss the proper architectural model, so-that we can move
> further to incorporate the changes accordingly. (thanks at last we
> have a thread to discuss)

Having discussions about the long term plan is good, as long as it's
not blocking support for new features for too long. Look, you've been
discussing the spi-nor stuff for more than 1 year now, and people are
still waiting it. Yogesh's attempt seems to go in the right direction,
so let's not block that just because we don't know how to integrate
things in the DM (that's not entirely BTW, I suggested an approach in
one of my previous reply).

> 
> Linux m25p80 is moved to spi-nor right? so does controllers on spi-nor
> should be reside in same area like drivers/mtd/spi-nor or it should be
> part of spi-mem. The last mail with  Boris, noted all spi-nor can't be
> fit into spi-mem(sorry I lost the thread)
> 
> Example: we have zynq qspi it support BAR(with >16MB flashes), dual
> qspi ect so does it comes under spi-mem or spi-nor?

Everything should go in drivers/spi/ and be exposed as spi/spi-mem
controllers. So yes, that's one aspect where Linux and u-boot should
differ IMO, at least until we have all SPI NOR controller drivers
converted to spi-mem in Linux.

> 
> So, if no driver should be part of spi-nor and all can be handle
> spi-mem even-though they have controller specific features, yes we can
> skip SPI_NOR_UCLASS otherwise we need spi-nor uclass that can be child
> uclass of MTD.

That's the idea, yes. Note that I'm open to any discussion regarding the
needed features and how we want expose that at the spi-mem level.