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

[Marek Vasut]

On 5/25/20 9:55 PM, Tom Rini wrote:
> On Mon, May 25, 2020 at 09:48:29PM +0200, Marek Vasut wrote:
>> 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?
> 
> Sharing defines is easy.  Sharing information buried in the device tree
> requires some of the dtoc changes either in progress or variations on
> them.  Sharing other functionality?  Depends on what fits well
> (logically) in inline functions.  But I don't see some duplication of
> either functional (i.e. read()/write()) nor initialization code as a
> hard blocker.
> 
> But the only choice that doesn't have some duplication of code would be
> "throw out current DM, replace with a new DM that's small enough in all
> cases".  And we're at a few years now of "DM is too big and bloaty!"
> without "here are my patches to slim down DM for all cases".

Surely the functionality to control/access hardware can be shared ?
See tiny-mmc for example.