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

[Tom Rini]

On Thu, Nov 28, 2019 at 10:40:38AM +0100, Marek Vasut wrote:
> 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 ?

I need to reply more directly to the opening post but yes, i.MX is still
for various reasons needing help, and no, shouldn't be dropped, but we
need to have a serious conversation about it.  The OMAP platforms
probably could be dropped or need a quick conversion.  PowerPC is
another place where we need a serious conversation.  MIPS I think just
needs some updating for conversion, along with the vexpress ones we also
use in CI via QEMU.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot-board-maintainers/attachments/20191128/b22c6067/attachment.sig>