[U-Boot] is it mandatory for SPL to support DM

[Marek Vasut]

On 5/25/20 9:28 PM, Tom Rini wrote:
> On Mon, May 25, 2020 at 09:07:54PM +0200, Marek Vasut wrote:
>> On 5/25/20 7:32 PM, Tom Rini wrote:
>>> On Mon, May 25, 2020 at 10:58:12PM +0530, Jagan Teki wrote:
>>>> On Mon, May 25, 2020 at 9:06 PM Simon Glass <sjg at chromium.org> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Mon, 25 May 2020 at 04:35, Marek Vasut <marex at denx.de> wrote:
>>>>>>
>>>>>> On 5/25/20 10:44 AM, Jagan Teki wrote:
>>>>>>> SPL has a foot-print constraint, so fully switching a particular
>>>>>>> subsystem like SPI or SPI Flash to DM would increase the size of it.
>>>>>>>
>>>>>>> Possible areas to look at are (assume SPL_DM supported)
>>>>>>> 1) platdata
>>>>>>> 2) implement board or platform specific spl device driver which
>>>>>>> bypassed the actual framework ex: spl_spi_sunxi.c
>>>>>>>
>>>>>>> Do we have any other solutions? or any arguments on above step 2?
>>>>>>
>>>>>> SPL does not need to support DM until the size problem is solved.
>>>>>
>>>>> I don't think the problem will ever be 'solved'. It is an ongoing battle.
>>>>>
>>>>> But as it happens I've just sent a proposal for tiny-dm that I think will help.
>>>>>
>>>>> Jagan, which board are you trying to convert? If you are trying to
>>>>> convert SPI flash, I think we need to remove the legacy code first.
>>>>
>>>> These are the partially dm converted drivers, so boards which are
>>>> using can eventually need a dm spi switch.
>>>>
>>>>         drivers/spi/fsl_dspi.c
>>>>         drivers/spi/kirkwood_spi.c
>>>>         drivers/spi/mxc_spi.c
>>>>         drivers/spi/mxs_spi.c
>>>>         drivers/spi/omap3_spi.c
>>>>         drivers/spi/sh_qspi.c
>>>>
>>>> I'm looking for proper options along with removal of some legacy code,
>>>> and tiny-dm.
>>>
>>> For the number of about to be year past published deadline (which has
>>> been extended at times to get to that point even) boards, I think we
>>> need to start by dropping boards.  Then we can see what makes sense
>>> moving forward.
>>
>> At least mxc_spi and sh_qspi must stay, since those are heavily used in
>> embedded/industrial/automotive.
> 
> So, this brings us back to the main topic of this thread.  Both of the
> drivers you mention ARE converted to DM, but cannot fit adding DM to
> SPL.  Where do we put non-DM SPL code as we have real size constraints
> in SPL/TPL?  I should bring this up in Simon's new thread too, but I
> wonder if we shouldn't just make drivers/spl/{mmc,spi,xxx}/ and have the
> non-DM-framework drivers for SPL reside somewhere and move on.  The
> notions of "we have a nice abstract framework" and "we need to be as
> small as possible" can and do conflict.

But then how do you propose to keep sharing code between the two worlds?