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

[Jagan Teki <jagan@amarulasolutions.com>]

On Mon, Jun 25, 2018 at 8:25 PM, Tom Rini <trini@konsulko.com> wrote:
> On Mon, Jun 25, 2018 at 04:46:56PM +0200, Boris Brezillon wrote:
>> 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.
>
> I agree.  We want U-Boot to be able to leverage as much as possible from
> the Linux kernel with as little re-working as possible.

I'm not denying that, but the basic design flow must follow u-boot
driver model. this is what everyone told from the beginning when I
started spi-nor work. Initially I did the design like this and
leverage with existing MTD, everyone NAK and suggested to use
driver-model on each stage with MTD dm abstraction.
So
- After 2 years of work
- With nearly 10 versions [4]
- Adding MIGRATION expire date for spi drivers dm conversion
- Simon Reviewed-by and
- Planning to apply after v2018.09.

but now all want the existing MTD, I don't understand what I can do
further on this?

[4] https://patchwork.ozlabs.org/user/todo/uboot/?series=20450