On Mon, Jun 25, 2018 at 04:46:56PM +0200, Boris Brezillon wrote: > On Mon, 25 Jun 2018 19:58:37 +0530 > Jagan Teki <ja...@amarulasolutions.com> wrote: > > > >>> - 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? > > It's not a controller that implements spi-mem operations but a simple > SPI controller (one that knows how to do regular SPI transfers and > nothing more). But the spi-mem layer knows how to send spi_mem_op using > regular transfer and that's why it works without any modification at > the driver level. > > > > >>> > > >>> 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. > > I think I have to repeat my previous statement here. It would be very > unfortunate if u-boot decides to take this direction (see Richard's > reply), especially since I see absolutely no benefit in doing what you > suggest. Having MTD devices registered to the uboot DM is something I > can understand, deciding to no longer support the standard MTD API is > something I don't.
I agree. We want U-Boot to be able to leverage as much as possible from the Linux kernel with as little re-working as possible. -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
