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

[Jagan Teki]

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)

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?

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.