From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Tue, 26 Nov 2019 18:07:12 +0100 Subject: [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [RFC] Eliminate boards not using CONFIG_DM=y In-Reply-To: <20191126165259.GY15966@bill-the-cat> References: <717e50a5-9b61-37d9-a322-d9f758c517d3@denx.de> <20191126162618.GX15966@bill-the-cat> <20191126165259.GY15966@bill-the-cat> Message-ID: <644594d0-e32d-14ae-a0a4-e33ce1066d78@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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?