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

[Boris Brezillon]

+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 at 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.

> - 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.

Regards,

Boris