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.brezillon@bootlin.com wrote:
On Wed, 12 Dec 2018 22:07:44 +0100 Jagan Teki jagan@amarulasolutions.com wrote:
On Wed 12 Dec, 2018, 10:02 PM Boris Brezillon <boris.brezillon@bootlin.com wrote:
On Thu, 13 Dec 2018 02:15:16 +0530 Jagan Teki jagan@amarulasolutions.com wrote:
On Thu, Dec 13, 2018 at 2:10 AM Boris Brezillon boris.brezillon@bootlin.com wrote:
Hi Jagan,
On Thu, 13 Dec 2018 01:55:08 +0530 Jagan Teki jagan@amarulasolutions.com wrote:
> On Wed, Dec 12, 2018 at 11:08 PM Vignesh R vigneshr@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.