On 1/1/25 11:36 PM, Laurent Pinchart wrote:
On Tue, Dec 31, 2024 at 10:10:51PM +0100, Marek Vasut wrote:
On 12/31/24 9:31 PM, Laurent Pinchart wrote:
Hi Marek,
Hi,
Thank you for the patch.
On Tue, Dec 31, 2024 at 08:28:48PM +0100, Marek Vasut wrote:
Add a flag meant purely to work around broken i.MX8MP DTs which enable
HDMI but do not contain the HDMI connector node. This flag allows such
DTs to work by creating the connector in the HDMI bridge driver. Do not
use this flag, do not proliferate this flag, please fix your DTs.
What's the rationale for this, what prevents fixing DT instead of using
this flag ? Adding such a flag will most likely open the door to
proliferation.
See the V2 series discussion, there are a few in-tree DTs which do not
have the HDMI connector node. The rationale is there might be more and
they might come from vendors, so this flag is necessary to work around
those DTs.
If you can't fix the DT on particular boards, patching it could be an
option. We had a similar problem on Renesas boards, which we fixed with
a DT overlay, see commit 81c0e3dd82927064 ("drm: rcar-du: Fix legacy DT
to create LVDS encoder nodes"). This made the workaround self-contained,
and allowed dropping it several kernel versions later (in commit
841281fe52a769fe, "drm: rcar-du: Drop LVDS device tree backward
compatibility").
Frankly, I would much rather fix the few in-tree DTs and mandate the
HDMI connector node in DT, which would keep the code simple, rather than
maintain a backward compatibility workaround for problem which might not
even exist.
The in-tree device tree sources should be converted as part of the
series, I don't see a point trying to maintain backward compatibility
for in-tree DT sources.
That's fine, that I can do.
For out-of-tree sources it depends on how likely the problem is. There's
no regression if nobody is affected. I personally like restricting
backward compatibility to the strict minimum, to ensure that all new DTs
will use proper bindings. Making the backward compatibility code
self-contained helps there, and we could also print a loud warning
(WARN_ON() seems appropriate) and set a date for the removal of the
workaround.
The other alternative would be to not add the workaround at all, and
wait if someone is going to complain about broken downstream DT. If so,
then it can be added. I would much rather prefer this simple option,
because I have this feeling there are not going to be (m)any broken
downstream DTs, but I might be wrong about that.
