Message-ID: <112178ce-189e-4437-b6ae-d54b36b59bb8@kernel.org>
Date: Tue, 2 Dec 2025 13:20:26 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
 Kory Maincent <kory.maincent@...tlin.com>
Cc: Markus Schneider-Pargmann <msp@...libre.com>,
 Luca Ceresoli <luca.ceresoli@...tlin.com>,
 Louis Chauvet <louis.chauvet@...tlin.com>,
 Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
 Miguel Gazquez <miguel.gazquez@...tlin.com>,
 dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-omap@...r.kernel.org, Jyri Sarha <jyri.sarha@....fi>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Russell King <linux@...linux.org.uk>,
 Bartosz Golaszewski <brgl@...ev.pl>, Tony Lindgren <tony@...mide.com>,
 Andrzej Hajda <andrzej.hajda@...el.com>,
 Neil Armstrong <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>,
 Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
 Jonas Karlman <jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>
Subject: Re: [PATCH 05/21] ARM: dts: omap: Bind panel to panel-dpi instead of
 ti,tilcdc,panel driver

On 02/12/2025 12:51, Tomi Valkeinen wrote:
> Hi Kory,
> 
> On 02/12/2025 13:18, Kory Maincent wrote:
>> On Tue, 2 Dec 2025 11:47:40 +0100
>> Krzysztof Kozlowski <krzk@...nel.org> wrote:
>>
>>> On 02/12/2025 11:44, Kory Maincent wrote:
>>>> On Tue, 2 Dec 2025 11:28:55 +0100
>>>> Krzysztof Kozlowski <krzk@...nel.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.
> 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.

Exactly.

> 
> And how does this sync with u-boot? It also has code for at least for a
> few of these boards.

+1

> 
> Are there even users for these boards? If not, maybe they can be just
> removed? I'm personally not familiar with these boards, so I have no
> idea of their age or distribution.
> 
> One trick that can be done is to modify the loaded DTB at boot time,
> detecting the old format, converting it to the new one, so that when the
> drivers are probed they only see the new DTB.

Best regards,
Krzysztof

Powered by blists - more mailing lists