[U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [RFC] Eliminate boards not using CONFIG_DM=y

[Marek Vasut <marex@denx.de>]

On 11/28/19 7:22 AM, Heinrich Schuchardt wrote:
> On 11/26/19 6:07 PM, Marek Vasut wrote:
>> On 11/26/19 5:52 PM, Tom Rini wrote:
>>> On Tue, Nov 26, 2019 at 05:47:48PM +0100, Marek Vasut wrote:
>>>> On 11/26/19 5:26 PM, Tom Rini wrote:
>>>>> On Tue, Nov 26, 2019 at 09:11:51AM +0100, Marek Vasut wrote:
>>>>>> On 11/26/19 12:16 AM, Heinrich Schuchardt wrote:
>>>>>>> Dear maintainers,
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>> we have been trying to move to the driver model for several years
>>>>>>> now.
>>>>>>> Starting in 2018 we have added warnings to the Makefile that
>>>>>>> boards not
>>>>>>> supporting the driver model will be eliminated. Still 24 % of the
>>>>>>> configuration files have not been converted and do not even use
>>>>>>> CONFIG_DM=y.
>>>>>>>
>>>>>>> If we want to get rid of legacy drivers, at some point we have to
>>>>>>> remove
>>>>>>> the 347 configuration files in the list below not using the
>>>>>>> driver model.
>>>>>>>
>>>>>>> I suggest to do this directly after the release of v2020.01
>>>>>>> scheduled
>>>>>>> January 6th.
>>>>>>>
>>>>>>> This should not stop the maintainers from reinserting the boards
>>>>>>> after
>>>>>>> conversion to the driver model.
>>>>>>
>>>>>> Some boards just cannot accommodate this DM stuff. For those boards,
>>>>>> it's just bloat without any useful added value. Hence, these boards
>>>>>> would be removed because they cannot accommodate arbitrary bloat.
>>>>>> This
>>>>>> makes U-Boot not-so-universal bootloader anymore, but rather a
>>>>>> bloated one.
>>>>>>
>>>>>> I don't think we can force boards out or impose DM on everyone
>>>>>> unless we
>>>>>> can solve this bloat issue first.
>>>>>
>>>>> As someone who was involved in creating this DM stuff, do you have
>>>>> some
>>>>> ideas on addressing things?  Given that you're responsible for a
>>>>> number
>>>>> of these platforms and can test out some ideas on them, what are you
>>>>> suggesting?
>>>>
>>>> How about directly calling driver functions for drivers which have
>>>> single instance only ? Then we could optimize out all the DM overhead
>>>> for that.
>>>
>>> And when are you hoping to post an RFC / example?
>>
>> Currently I have zero time available. Maybe someone else can look into
>> this option?
> 
> Dear Marex,
> 
> DM drivers make use of the DM infrastructure for instance for the
> allocation of the private data area. The uclass files often include
> common logic needed for accessing all drivers (see for example tpm_xfer()).
> 
> So which drivers do you think of that could be simplified?

UART for example ? You only usually have one.

> I would also be interested to learn which of the 347 boards not using
> CONFIG_DM=y are still actively maintained.

Probably quite a few of those iMX, omap and PPC ones.
The qemu ones are probably used for CI ?