Re: [PATCH 05/21] ARM: dts: omap: Bind panel to panel-dpi instead of ti,tilcdc,panel driver

[Krzysztof Kozlowski <krzk@kernel.org>]

On Tue, Dec 02, 2025 at 01:56:05PM +0100, Kory Maincent wrote:
> On Tue, 2 Dec 2025 13:51:59 +0200
> Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> wrote:
> 
> > Hi Kory,
> > 
> > On 02/12/2025 13:18, Kory Maincent wrote:
> > > On Tue, 2 Dec 2025 11:47:40 +0100
> > > Krzysztof Kozlowski <krzk@kernel.org> wrote:
> 
> > I will not NAK, removing bindings and breaking users is under some
> > conditions acceptable. You just need to come with the reasons and impact.
> > 
> > Reason "is ugly" is usually not good enough. Especially if things were
> > working.
> 
> Thanks for you reply.
> 
> > >>
> > >> DTS cannot go to drm, which means you either need to separate the change
> > >> and make entire work bisectable and backwards compatible for some time
> > >> OR at least document clearly the impact as we always ask.  
> > > 
> > > The thing is, if I split it, it has to be in 3. One for the of DRM bus flags
> > > support, a second for the the devicetree and binding change and a third for
> > > the whole tilcdc and tda998x cleaning stuff. I think I will go for one
> > > series, with better documentation.
> > > 
> > > Now, what is your point of view on my question. Will you nak any binding
> > > removal even if the binding is ugly and legacy and imply maintaining an
> > > non-standard tilcdc panel driver? I know it breaks DTB compatibility but
> > > there is several argument to not keep it. See patch 6.  
> > The binding being ugly and having to maintain non-standard tilcdc panel
> > driver may be nice things for us, the users don't care. The users care
> > if their board no longer works.
> 
> Yes I understand but then I have another question. At what cost should we
> continue to support legacy binding?

That's mostly question to platform maintainers and users. Extrapolating
kernel rule - we never break the user-space - we never break the users,
thus we take significant cost.

And that significant cost can be the cost of making the transition
smooth or smoother.

> 
> Just figured out this case already happened, ti,tilcdc,slave binding was
> removed from the tilcdc driver:
> 739acd85ffdb7 ("drm/tilcdc: Remove obsolete "ti,tilcdc,slave" dts binding
> support")
> 
> Even if there is still one mainline device tree that uses it:
> am335x-base0033.dts. :/

If that commit broke existing users, it is a good argument for your
changes, but you need to explicitly use that argument in commit msg.

> 
> > And how does this sync with u-boot? It also has code for at least for a
> > few of these boards.
> 
> U-boot has indeed a driver for the ti,tilcdc,panel binding.
> Changing this devicetree would beak display for these board in U-boot as it
> currently does not support the "panel-dpi" binding.

Thanks for checking, regardless of decision this also should be in
commit msg.

Maybe things were not working correctly for long time, so there is a
choice of fixing Linux side while breaking U-boot and not fixing, but
keeping bootloader working.


Best regards,
Krzysztof