[PATCH] arm: sunxi: disable obsolete VIDEO config

[Maxime Ripard]

On Mon, Oct 19, 2020 at 10:50:49AM -0400, Tom Rini wrote:
> On Mon, Oct 19, 2020 at 11:17:54AM +0200, Maxime Ripard wrote:
> > On Sun, Oct 18, 2020 at 09:18:15PM +0200, Anatolij Gustschin wrote:
> > > DM_VIDEO conversion deadline has passed, disable VIDEO config
> > > option by default. Boards should convert to DM_VIDEO if they
> > > need video console support.
> > > 
> > > Signed-off-by: Anatolij Gustschin <agust at denx.de>
> > > Cc: Jagan Teki <jagan at amarulasolutions.com>
> > > Cc: Maxime Ripard <mripard at kernel.org>
> > > ---
> > >  arch/arm/mach-sunxi/Kconfig | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > > index be0822bfb7..f672bb8b4e 100644
> > > --- a/arch/arm/mach-sunxi/Kconfig
> > > +++ b/arch/arm/mach-sunxi/Kconfig
> > > @@ -760,7 +760,7 @@ config VIDEO_SUNXI
> > >  	depends on !MACH_SUN50I_H6
> > >  	select VIDEO
> > >  	imply VIDEO_DT_SIMPLEFB
> > > -	default y
> > > +	default n
> > 
> > default n is the default with Kconfig iirc
> > 
> > Otherwise, I can't say that I agree with the forced conversion strategy
> > to the DM in general. We're struggling to keep U-Boot working from one
> > release to the other, so adding pressure to convert drivers feels a bit
> > too much.
> > 
> > I can see where you're coming from though, so I guess that's a
> > reluctantly-acked-by ? :)
> 
> Can you please elaborate on your struggles?

I'm sure that the fact that we don't have a lot of time is part of that
reason really, but it seems that the forced (or at least strongly
encouraged) conversion to Kconfig and the device model created a lot of
reworks that in turn created some regressions.

Even though they are to be expected in every patch, it looks to me that
the forced conversion encouraged people to create patches that were not
properly tested on every platform. So we ended up with more patches, and
a higher probability of breakage.

For example, I've recently discovered that since at least 2020.01 we
have a regression in our musb setup, where we used to be able to just
use a USB gadget right away, but it looks like now we have to use usb
reset. I haven't had the time to look into why yet.

Some boards also have lost ethernet for a while too because it turns out
that the generic PHY reset bindings aren't supported by the the
designware net driver and when we changed for those bindings, and then
sync'd the DTS between linux and u-boot, then the PHY wasn't reset
properly anymore (I do have a patch for that one though).

It feels like almost every release is broken in some new way, and it's
hard to just keep up.

Ultimately, I think that this is mostly due to us not having enough time
to test and debug each release. If someone with some knowledge of
Allwinner SoCs was willing to step up and take over my seat, then I'd be
more than happy to help with the transition.

> The only thing right now keeping me from having some sunxi target in
> my HW CI loop is I didn't have anything that wasn't leaking in power
> via UART, even, seemingly. Thanks!

Yeah, the older one especially are pretty bad for that. Which one do you
have?

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20201027/99054b38/attachment.sig>