+ Simon + Tom On Mon, Jun 25, 2018 at 7:57 PM, Jagan Teki <ja...@amarulasolutions.com> wrote: > + Simon > + Tom > (suggesting MTD driver model abstraction layer) > > On Mon, Jun 25, 2018 at 2:39 PM, Boris Brezillon > <boris.brezil...@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.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. > > 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/
-- Jagan Teki Senior Linux Kernel Engineer | Amarula Solutions U-Boot, Linux | Upstream Maintainer Hyderabad, India. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
