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

[Richard Weinberger]

Am Montag, 25. Juni 2018, 11:09:41 CEST schrieb 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.

+1

As someone who is concerned that UBI and UBIFS are sane within u-boot
I'm not at all in favor of adding such a layer. The current MTD framework
does not need another abstraction level.
It will make keeping u-boot in sync with Linux more complicated that it
is already.

Thanks,
//richard