[PATCH v3] dm: i2c: Add a migration method for I2C

[Simon Glass]

Hi Tom,

On Fri, 26 Mar 2021 at 13:14, Tom Rini <trini at konsulko.com> wrote:
>
> 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 at 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 at 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 at 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 at 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
> > > > >
> > > > > https://pastebin.com/Wq8vgtSx
> > > >
> > > > 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.

OK...will take a look.

Regards,
Simon