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

[Jagan Teki <jagan@amarulasolutions.com>]

+ Simon
+ Tom
(suggesting MTD driver model abstraction layer)

On Mon, Jun 25, 2018 at 2:39 PM, Boris Brezillon
<boris.brezillon@bootlin.com> wrote:
> +Richard to comment on the MTD abstraction stuff and how uboot port
> of UBI might be impacted by some changes requested here.
>
> Hi Jagan,
>
> On Mon, 25 Jun 2018 13:59:37 +0530
> Jagan Teki <jagannadh.teki@gmail.com> wrote:
>
>>
>> I've looked the code on the respective patches, look like most of the
>> code copy from Linux by adding __UBOOT__. I have no issue with Linux
>> copy but we need to structure the code according to U-Boot in the form
>> of driver-model (this series lack with that).
>>
>> Here are my suggestions, based the MTD work so-far
>>
>> First we need to design MTD driver-model which can capable to drive
>> one driver from each interface. (not converting all interface drivers
>> at once, that is taking more time and other issues)
>>
>> Like Linux MTD, U-Boot should have MTD dm for underlying flash devices
>> like nand, parallel nor, spinor etc. So to drive this theory with
>> driver model(with an example of block layer) mtd is common device
>> interaction for most of  memory technology  flashes like nand,
>> parallel nor, spinor etc, these are treated as interface types wrt
>> u-boot driver model.
>>
>> Once the respective interface driver bind happen, the uclass driver
>> will pass an 'interface type' to mtd layer to create device for it,
>> for example once spinor ULASS_SPI_NOR driver bind happen, the uclass
>> driver of spinor will pass MTD_IF_TYPE_SPI_NOR
>> interface type to create mtd device for spinor devices.
>>
>> So If we add this design to SPI-NAND changes, we need to implement
>> - MTD dm core that can driver all interfaces
>
> That's already what the MTD framework provides, and Miquel even added
> some stuff to integrate the MTD layer even further in the DM. It's
> probably not perfect yet, but the changes are, IMHO, going in the right
> direction.
>
> Now, if you're talking about the new MTD API that creates helper
> functions prefixed with dm_, sorry, but I don't see the point. We
> already have plenty of MTD users in u-boot, they all manipulate MTD
> objects and go through the standard MTD API to do that. What you
> suggest would make things messier for several reasons:
>
> 1/ we won't be able to easily port Linux code to u-boot. Look at the
>    JFFS2 UBI support. They all use mtd_info objects. What's the point of
>    changing that except making things harder to port.
>
> 2/ Not all MTD providers will be converted to the device model at once,
>    so how do you plan to deal with that?
>
> 3/ What's the benefit of exposing yet another way to manipulate MTD
>    devices?
>
>> - one driver for raw nand
>
> Unfortunately, that's not how it works right now, and clearly, we
> don't have time to work on this raw NAND rework right now.
>
>> - one driver for spinand
>
> I think that's already the case.
>
>> - spi-mem
>
> It's also what Miquel is doing in this series.
>
>> - 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?

>
>> - implement command to handle
>
> This I don't get. What do you mean by "implement command to handle"?
> Are we talking about cmd/mtd.c? I think the work Miquel has done is
> already a good start, what's missing in there?
>
>>
>> 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.

[3] http://git.denx.de/?p=u-boot-spi.git;a=commitdiff;h=d297949cd3f44278f109dff42fb88a879722121c
[4] https://patchwork.ozlabs.org/patch/853337/