[U-Boot] [RFC PATCH 00/20] SPI-NAND support

[Boris Brezillon <boris.brezillon@bootlin.com>]

On Mon, 25 Jun 2018 19:58:37 +0530
Jagan Teki <jagan@amarulasolutions.com> wrote:

> >>> - convert fsl-qspi to spi-mem  
> >>
> >> We're not targeting the fsl-qspi controller here but a simple SPI
> >> controller that is already upstreamed. But yes, the fsl-qspi driver
> >> will have to be patched to support the spi-mem interface at some point.  
> >
> > Can you point me that simple spi-mem controller driver?

It's not a controller that implements spi-mem operations but a simple
SPI controller (one that knows how to do regular SPI transfers and
nothing more). But the spi-mem layer knows how to send spi_mem_op using
regular transfer and that's why it works without any modification at
the driver level.


> >>>
> >>> For spi-nor interface design, we have an example code here[2]
> >>>
> >>> I've paused this [2] series because of dm conversion of spi-drivers
> >>> otherwise I need add legacy code like mmc-legacy.c, so if we really
> >>> move to spi-mem design and okay with above design. I will try to move
> >>> the current spi flash to add MTD driver-model so-that we can add
> >>> spi-mem, spi-nand on top of it or we can work together to convert them
> >>> all.  
> >>
> >> Why can't we do things iteratively. I mean, if the long term goal is to
> >> convert everything to the driver model, then this patchset is going in
> >> the right direction:
> >>  - addition of DM helpers to the MTD_UCLASS
> >>  - addition of the spi-mem interface properly integrated in the DM
> >>    model of the SPI framework
> >>  - addition of a SPI NAND driver, again properly integrated in the DM
> >>  - integration of DM-ready MTD drivers and old MTD drivers in a single
> >>    view exposed by the cmd/mtd.c command set
> >>
> >> I'd really like to limit the scope of this development to these topics,
> >> which doesn't prevent you from converting other part of u-boot to the
> >> spi-mem approach (SPI NOR is one example).
> >>
> >> I hope you understand our concerns and the fact that what you're asking
> >> us to do as a dependency of getting SPI NAND support + cmd/mtd.c merged
> >> is way more than we can actually provide.  
> >
> > To answer all these questions, I think we need to decide whether we go
> > for MTD dm abstraction or existing MTD layer.
> >
> > When I say MTD dm abstraction, all mtd operation prototypes are in the
> > form of udevice unlike existing MTD has mtd_info. when I initially
> > supporting spi-nor (during Linux early spi-nor) I've reused existing
> > MTD and written something like what Miquel did using mtd_info ops [3].
> > but then developers on ML, proposed the new drivers should be form of
> > driver-model abstraction, so I've added mtd driver model ops [4].
> >
> > I understand the new MTD dm abstraction in U-Boot is not possible for
> > direct syncing from Linux, but we really want the u-boot way of
> > handling drivers and trying to copy code from Linux by removing
> > __UBOOT__ or any Linux specific macros. Since this is pretty much big
> > task, ie the reason I'm asking for single driver from each MTD device
> > so-that once the clear stack is ready other drivers can convert
> > one-by-one.

I think I have to repeat my previous statement here. It would be very
unfortunate if u-boot decides to take this direction (see Richard's
reply), especially since I see absolutely no benefit in doing what you
suggest. Having MTD devices registered to the uboot DM is something I
can understand, deciding to no longer support the standard MTD API is
something I don't.