On Thu, Dec 13, 2018 at 04:40:30AM +0530, Jagan Teki wrote: > On Thu, Dec 13, 2018 at 2:55 AM Boris Brezillon > <boris.brezil...@bootlin.com> wrote: > > > > On Wed, 12 Dec 2018 22:07:44 +0100 > > Jagan Teki <ja...@amarulasolutions.com> wrote: > > > > > On Wed 12 Dec, 2018, 10:02 PM Boris Brezillon <boris.brezil...@bootlin.com > > > wrote: > > > > > > > On Thu, 13 Dec 2018 02:15:16 +0530 > > > > Jagan Teki <ja...@amarulasolutions.com> wrote: > > > > > > > > > On Thu, Dec 13, 2018 at 2:10 AM Boris Brezillon > > > > > <boris.brezil...@bootlin.com> wrote: > > > > > > > > > > > > Hi Jagan, > > > > > > > > > > > > On Thu, 13 Dec 2018 01:55:08 +0530 > > > > > > Jagan Teki <ja...@amarulasolutions.com> wrote: > > > > > > > > > > > > > On Wed, Dec 12, 2018 at 11:08 PM Vignesh R <vigne...@ti.com> > > > > wrote: > > > > > > > > > > > > > > > > Add non DM version of SPI_MEM to support easy migration to new > > > > > > > > SPI > > > > NOR > > > > > > > > framework. This can be removed once DM_SPI conversion is > > > > complete. > > > > > > > > > > > > > > Our intention to use new driver to follow dm, why we need to > > > > > > > support > > > > > > > non-dm? any usecases? > > > > > > > > > > > > Looks like we're having the same discussion over and over. Vignesh > > > > > > is > > > > > > dropping spi_flash.c which AFAICT was not depending on DM_SPI, so, > > > > > > if > > > > > > we want to keep everyone happy while getting rid of some legacy > > > > > > code, > > > > > > that's the only solution. DM conversion is a nice goal, but it's > > > > > > kind > > > > > > of orthogonal to what Vignesh is working on. If DM_SPI conversion > > > > > > happens before the spi-nor stuff is merged (which I doubt) then > > > > > > this > > > > > > patch can simply be dropped. > > > > > > > > > > spi_flash.c is a core code not a specific driver it belongs. spi-mem > > > > > is new feature driver how come new driver will support legacy non-dm > > > > > do we have legacy use for that(ie what I'm asking about usecase) > > > > > > > > I recommend that you read the spi-mem code carefully. spi-mem is not > > > > driver specific, it's a thin layer on top of spi and driver *can* (but > > > > are not forced to) provide optimized methods to execute spi-mem > > > > operations. When that's not the case, the implementation falls back to > > > > regular spi transfers. AFAIK, both DM and non-DM drivers support > > > > regular spi transfers, right? So why should we depend on DM_SPI? And > > > > more importantly, if we do that, that means we can't get rid of > > > > spi_flash.c since some users might still have non-DM SPI drivers, which > > > > in turn means we keep more legacy code for no good reasons. > > > > > > > > > > I understand spi-mem is core file, but new code too. > > > > Sorry, I don't get it. > > > > > > > > > > > > You want non-DM SPI controller drivers to go away, then remove them, > > > > instead of blocking other changes using this excuse. > > > > > > > > > > Please understand uboot development flow, legacy driver can be removed if > > > possible once migration expire and NEW drivers or code must be dm driven. > > > > Sorry, but I think you're the one misunderstanding what we are trying > > to do here. Vignesh changes have simply no impact on the DM SPI > > conversion you're aiming at. All Vignesh does is provide a dummy > > wrapper for non-DM drivers, which would probably have been implemented > > by Miquel if you had not been so insistent on your precious DM_SPI > > conversion. That was not really a problem for spi-nand, as we were > > I'm sure, I'm in right direction. > > This is what I asked in the first mail, > > "Our intention to use new driver to follow dm, why we need to support > non-dm? any usecases?" > > and I have the answer on this thread about the use case. > > I do really understand your intention about the real question. > - Any code or generic code will add in U-Boot should be driver-model > driven, are you agree this point? > Yes- thanks. > No - we need to have separate discussion. > > Any code that related to spi, or spi-flash should be driver-model > driven, ie what my AIM as a Maintainer (ie only reason for my spi-nor > changes resist for long time to fit).
And since we have both been "stuck" for so very long and a clear commitment from a few people to follow through on the "and DM it after" part, I'm OK with bending the rules. -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
