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.
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.