+ 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=d297949cd3f44278f109dff4... [4] https://patchwork.ozlabs.org/patch/853337/