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

[Krzysztof Kozlowski]

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 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.
> 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