All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [U-Boot-Board-Maintainers] [U-Boot-Custodians] [RFC] Eliminate boards not using CONFIG_DM=y
Date: Tue, 26 Nov 2019 11:56:39 -0500	[thread overview]
Message-ID: <20191126165639.GZ15966@bill-the-cat> (raw)
In-Reply-To: <20191126173126.3a2dc0d5@jawa>

On Tue, Nov 26, 2019 at 05:31:26PM +0100, Lukasz Majewski wrote:
> Hi Tom,
> 
> > 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?
> > 
> 
> I can speak of some i.MX28 board(s). If there is a will one can try to
> use OF_PLATDATA without the full blown support of FDT (patches recently
> added to not include some not necessary stuff).

Right, making use of OF_PLATDATA is one of the things to address bloat
and DM isn't _required_ in SPL.

> (The board which uses this approach still waits for SPL_DM_GPIO
> definition in Kconfig to be re-posted to ML)

Ah that patch.  Sorry it's taking so long, I need to put it back on my
to-grab list.

> However, I don't know if this would work for all kinds of _bloat_
> mentioned by Marek.

And "bloat" is something I'm actively looking for people to post some
RFCs on how to address.

-- 
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/attachments/20191126/eea82dee/attachment.sig>

  reply	other threads:[~2019-11-26 16:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-25 23:16 [U-Boot] [RFC] Eliminate boards not using CONFIG_DM=y Heinrich Schuchardt
2019-11-26  8:11 ` [U-Boot] [U-Boot-Board-Maintainers] " Marek Vasut
2019-11-26 16:26   ` [U-Boot] [U-Boot-Custodians] " Tom Rini
2019-11-26 16:31     ` [U-Boot] [U-Boot-Board-Maintainers] [U-Boot-Custodians] " Lukasz Majewski
2019-11-26 16:56       ` Tom Rini [this message]
2019-11-26 16:47     ` [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] " Marek Vasut
2019-11-26 16:52       ` Tom Rini
2019-11-26 17:07         ` Marek Vasut
2019-11-28  6:22           ` Heinrich Schuchardt
2019-11-28  9:40             ` Marek Vasut
2019-11-28 16:51               ` Tom Rini
2019-11-29  6:46 ` [U-Boot] [U-Boot-Custodians] " Priyanka Jain
2019-11-29 15:18   ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191126165639.GZ15966@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.