Thread (46 messages) 46 messages, 5 authors, 2025-12-11

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

From: Krzysztof Kozlowski <krzk@kernel.org>
Date: 2025-12-02 12:19:16
Also in: dri-devel, linux-devicetree, linux-omap, lkml

On 02/12/2025 12:18, Kory Maincent wrote:
On Tue, 2 Dec 2025 11:47:40 +0100
Krzysztof Kozlowski [off-list ref] wrote:
quoted
On 02/12/2025 11:44, Kory Maincent wrote:
quoted
On Tue, 2 Dec 2025 11:28:55 +0100
Krzysztof Kozlowski [off-list ref] wrote:
  
quoted
On 02/12/2025 10:42, Kory Maincent wrote:  
quoted
     
quoted
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.
 
quoted
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.
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.

Best regards,
Krzysztof
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help