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

[Kory Maincent]

On Tue, 2 Dec 2025 11:47:40 +0100
Krzysztof Kozlowski <krzk at kernel.org> wrote:

> On 02/12/2025 11:44, Kory Maincent wrote:
> > On Tue, 2 Dec 2025 11:28:55 +0100
> > Krzysztof Kozlowski <krzk at kernel.org> wrote:
> >   
> >> On 02/12/2025 10:42, Kory Maincent wrote:  
> >>>      
> >>>> Stuffing DTS change in the middle of the driver change tries to hide
> >>>> impact, which is not nice on its own.    
> >>>
> >>> As it needs driver change before the removal for not breaking things it
> >>> can't be done at the beginning of the series.    
> >>
> >> And that is the problem which should stop you there and rethink how to
> >> organize it without impacting users. DTS cannot go via DRM. If that was
> >> your intention, that's my:
> >>
> >> NAK  
> > 
> > My intention was to raise discussion over the ugly and legacy tilcdc-panel
> > binding and what to do with it. But it seems you don't want to, that's a
> > shame.  
> 
> I don't see how you get to these conclusions. I comment that putting
> here DTS in the middle without any explanation of the impact is not
> correct and this one alone I disagree with.

Because you didn't replied to the first line of my answer:
"Yes, I know this but I still wanted to try and begin a discussion on this, as I
really thought it is not a good idea to add and maintain an new non-standard
panel driver solely for this tilcdc panel binding."

But indeed you are right, I should have put more explanation on why there is DTS
and binding change in the middle of the series. Sorry for that.
 
> From that you claim I don't want to fix things...
> 
> 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.

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com