On Thu, Mar 25, 2021 at 06:45:35PM -0400, Tom Rini wrote:
On Fri, Mar 26, 2021 at 08:41:42AM +1300, Simon Glass wrote:
Hi Tom,
On Fri, 26 Mar 2021 at 08:30, Tom Rini trini@konsulko.com wrote:
On Fri, Mar 26, 2021 at 08:11:30AM +1300, Simon Glass wrote:
Hi Tom,
On Fri, 26 Mar 2021 at 08:05, Tom Rini trini@konsulko.com wrote:
On Fri, Mar 26, 2021 at 06:48:26AM +1300, Simon Glass wrote:
Hi Tom,
On Fri, 26 Mar 2021 at 04:59, Tom Rini trini@konsulko.com wrote: > > On Thu, Mar 25, 2021 at 01:39:28PM +1300, Simon Glass wrote: > > > This probably should have been done a while back since it is a core > > system. Add a migration deadline of later this year, to catch the > > stragglers. > > > > Signed-off-by: Simon Glass sjg@chromium.org > > What boards trigger this warning when done on top of say the > WIP/remove-non-AHCI_LIBATA-drivers branch I've pushed to my github or > WIP/make-DM_PCI-fatal which has more removals, but I need to cycle back > to and finish removing even more boards I suspect.
With us/WIP/make-DM_PCI-fatal it looks like 250.
Ugh. Can you link me the CI run please? I'm curious about which.
Sorry, I did it locally
I'm having trouble with that, sorry. It looks like it's complaining about boards that with your series applied locally don't throw up a warning about I2C (but do for DM_ETH, which already has a soon deadline).
Yes I was just going off the number of migration messages in the output (using grep).
Then we can introduce this warning for v2021.04 (I'll grab it shortly) and set the deadline of v2022.04 (a year of being loud) and hopefully things are migrated / otherwise removed before v2024.04 and they get nuked like we're starting with now on v2019.xx deadlines.
Do you mean 2022.04? My view has become that things that haven't been done probably won't be, so we should save ourselves the trouble and cost of maintaining the boards and just remove them now. For example, the Kconfig migration would be in much better shape (although I haven't analysed how much better).
Note I sent a series to clean up the warnings, plus add I2C and GPIO, so you should look at that instead of this patch.
Well, lets get some numbers on what boards throw this I2C warning first. I did a quick merge of this series and pushed WIP/add-DM_I2C-warning right now and I'm doing the before/after build now.
OK.
So, the list of DM_I2C violators is: am335x_guardian am335x_shc am335x_shc_ict am335x_shc_netboot am335x_shc_sdboot cm_t335 cm_t43 chiliboard am335x_igep003x draco etamin rastaban thuban pxm2 rut am335x_sl50 am335x_baltos igep00x0 omap3_beagle omap3_evm devkit8000 omap4_panda omap4_sdp4430 omap5_uevm all of which are using the omap i2c driver, which has been converted. I've fired off a CI build now that just makes DM_I2C default y, lets see what still has a warning then.
This brings us to https://source.denx.de/u-boot/u-boot/-/jobs/244066 which shows sunxi throws an error...but I'll assume that's fixed in the video update that's basically pending already. Then a handful of needed migrations. I think a series that enables DM_I2C by default, disables it on the boards it fails on and cc's the board maintainers to get them to look (as I'm sure there's other migrations missing) would probably help make sure this is all taken care of before a v2022.04 deadline.
And I think v2022.04 is still right because the places this crops in are boards with other, sooner, migration deadlines. There's no missing driver migrations as best I can see. So if we say "you need to migrate this thing you've had 3 years notice on, and also please take of these other low-hanging quick migrations while you're here and testing on the hardware" is going to be better received I think than "and we also just added another super soon deadline too". And with enforcing some big migrations just around the corner there'll be plenty of other "now we can clean up and nuke the non-DM code that's not used for SPL/TPL" and so on.