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

[Tom Rini]

On Mon, Dec 10, 2018 at 02:15:05PM +0100, Boris Brezillon wrote:
> 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).

To be clear, we've been having this discussion for probably closer to
two or three years now.  Which is why at this point what I'm saying we
need to do is get a logical evolution of To be clear, we've been having
this discussion for probably closer to two or three years now.  Which is
why at this point what I'm saying we need to do is get a logical
evolution of Vignesh's series in, for v2019.04 and improve it over time.
The notion of "we'll block progress on new features in order to make
sure we get conversion done" has failed.  Lets go back to good old
reliable incremental change over time.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181210/11e71bbe/attachment.sig>