[U-Boot] [PATCH 03/16] spi: Add non DM version of SPI_MEM

Vignesh R vigneshr at ti.com
Fri Dec 14 10:57:41 UTC 2018


Hi,

On 14/12/18 3:32 PM, Jagan Teki wrote:
> On Thu, Dec 13, 2018 at 2:19 PM Vignesh R <vigneshr at 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 at 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/

-- 
Regards
Vignesh


More information about the U-Boot mailing list