[PATCH 1/2] opos6uldev: make the LCD work again

[Tom Rini]

On Wed, Feb 28, 2024 at 07:44:42PM +0530, Sumit Garg wrote:
> + Shawn, Krzysztof, Conor
> 
> Hi Tom,
> 
> On Wed, 28 Feb 2024 at 18:40, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Wed, Feb 28, 2024 at 10:09:13AM +0300, Dan Carpenter wrote:
> > > On Tue, Feb 27, 2024 at 04:40:01PM +0100, Sébastien Szymanski wrote:
> > > > Commit 5d7a95f49999 ("imx6ul/imx6ull: synchronise device trees with
> > > > linux") removed the display timings from the board device tree whereas
> > > > they are still needed by the mxsfb driver.
> > > > Add the timings back (the correct ones) in the
> > > > imx6ul-opos6uldev-u-boot.dtsi file and remove them from the
> > > > opos6uldev.env file.
> > > >
> > > > Update the opos6uldev_defconfig file so that the LCD turns on at boot.
> > > >
> > > > Fixes: 5d7a95f49999 ("imx6ul/imx6ull: synchronise device trees with linux")
> > > > Signed-off-by: Sébastien Szymanski <sebastien.szymanski at armadeus.com>
> > >
> > > Huh.  This is the commit that did that upstream.
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d9aa4d4fca67823838fe9861456201430c545e69
> > >
> > > It's interesting how the timings in linux were always slightly different
> > > from in u-boot.
> >
> > Thanks for tracking that down, Dan. I'm adding in Sumit and Rob here
> > because this is a recent (rather than ancient) example of one of the
> > concerns about OF_UPSTREAM.
> 
> I rather think about this as an opportunity to improve with
> OF_UPSTREAM. We can feed these kinds of DT ABI breakages to
> corresponding Linux kernel sub-arch maintainers. Especially once we
> move to OF_UPSTREAM and a sub-arch maintainer profile in Linux kernel
> to keep them aware that U-Boot should be considered too.

Yes, a more extensive check around when removing information from dts
files would be good.

> > I think the commit in question can be
> > summarized as "remove a bunch of explicit HW information because there's
> > now a Linux Kernel driver that determines that dynamically". What do we
> > do next? The old information is in a presumably valid binding still, can
> > we just put it back and comment that consumers outside of Linux use this
> > still so it's not removed again later? Or am I just missing where we can
> > instead get this information from the DT still and not need to come up
> > with a new driver and subsystems?
> 
> I can see following two paths forward:
> 
> 1) Partially revert the Linux kernel commit to add back the display
> timings in DT.
> 2) Extend drivers/video/simple_panel.c in U-Boot to add support for
> compatible: "armadeus,st0700-adapt".
> 
> If possible then I would be in favour of (2) rather than the current
> patch to do this properly.

Well, looking at the kernel drivers/gpu/drm/panel/panel-simple.c driver
and then our drivers/video/simple_panel.c it sure would be nice if it's
just a matter of adding a compatible but I wouldn't be surprised if it
ends up needing more information being passed along too? And I'm going
assume there's good reasons for the design change in how the drivers
work in Linux now and note that it might make things more challenging
for us when we do care about space.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20240228/8d957fed/attachment.sig>