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.t...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
