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

[Tom Rini <trini@konsulko.com>]

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

We need to make sure things overall are a good fit and I know we've had
some back and forth on this, but, "sync with Linux subsystem and make it
work cleanly (as possible) in U-Boot" is the path I think we need to
take and I like what Vignesh has done and to repeat myself from earlier,
I want to see this series (or rather, it's overall evolution) come in
for v2019.04.  Progress over time on top of those changes is good but as
you note, your series is from a year ago and that was a pretty long
evolution in that direction too.  We need to get this solved and since
we have motivated developers right now, I want to see this resolved.
Thanks!

-- 
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/20181206/7372397c/attachment.sig>