Hi,
On 14/12/18 3:32 PM, Jagan Teki wrote:
On Thu, Dec 13, 2018 at 2:19 PM Vignesh R vigneshr@ti.com wrote:
On 13/12/18 1:55 AM, Jagan Teki 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?
As said by others, AFAICS, DM_SPI migration is not going to be complete anytime soon. There are many boards and configs that don't enable DM_SPI. I propose you add a patch to print _warning during build_ for boards that don't have DM_SPI enabled (like DM_MMC and DM_USB) targeting v2019.07 or v2019.04 as deadline for removal. At the deadline you can remove spi-mem-nodm.c along with all other non DM code in SPI core.
I don't understand why DM_SPI migration came to this topic? It's a separate thread/issue.
I respectfully disagree. If DM_SPI migration was complete then SPI_MEM would be available for use by all subsystem. This patch wouldn't have been needed.
Do you think any development opensource project will agree to push the code which may remove it in future? ie what my point here.
Do you agree some code needs to be added to spi-nor layer so as not to break non DM_SPI converted boards but make use spi-mem APIs in spi-nor? If yes, then that code is spi-mem-nodm.c. I can rename it as spi_mem_emulation.c or something, but that does not change the fact.
Else, are you proposing to do following in spi-nor-core like in rfc v1[1]?
#if defined(CONFIG_DM_SPI) && defined(CONFIG_SPI_MEM) /* call spi_mem_*_ops() */ #else /* call SPI ops like spi_xfer() etc #endif
I am not seeing any solution here. Please have a look at spi-mem.c and spi-nor.c interaction. What do you propose as a solution to use spi-mem APIs but not break non DM_SPI drivers?
[1]https://patchwork.ozlabs.org/patch/1004836/