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 <[email protected]> wrote: >> >>> On 02/12/2025 11:44, Kory Maincent wrote: >>>> On Tue, 2 Dec 2025 11:28:55 +0100 >>>> Krzysztof Kozlowski <[email protected]> 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
