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 ?