Re: [PATCH 2/3] arm64: dts: renesas: r8a77961: Add lvds0 device node

[Nikita Yushchenko <nikita.yoush@cogentembedded.com>]

>> I'd prefer to make each DT fragment to use only either entities defined in that fragment itself, or
>> defined "interface entities" between this and "neighbor" DT fragment.
>>
>> Such as:
>> - SoC's DT fragment defines a named port/endpoint to export video stream at
>> - board's DT fragment defines a named panel node corresponding to panel plugged into board's physical
>> connector, and connects endpoints with SoC's video export,
>> - panel's DT fragment extends the panel node from board with video mode information for this particular
>> panel.
>> ...
 >
> I agree it's annoying, but we'll have a similar problem, just the other
> way around, with an endpoint defined in the SoC dtsi. Many R-Car SoCs
> have two LVDS encoders, and you can attach a panel to either of them.
> Some boards use LVDS0, some boards use LVDS1, and some boards could even
> use both.

The case of "some boards use LVDS0, some boards use LVDS1" is directly addressed by what I'm trying to 
suggest. The per-board DT fragment can completely hide board's connection details, without a need for 
any new concept.

The case of "some boards could even use both" indeed needs a some way to parametrize panel's DT 
fragment, and perhaps load two instances of it with different parameters. To some extent this is doable 
via preprocessor magic and multiple includes, although this approach has obvious disadvantages.

> A real solution for this problem will require a new concept. The "DT
> connector" proposal is related to this problem space. There's also a
> proprietary implementation in the Rapsberry Pi boot loader of a
> mechanism to support parametrized overlays ([2] and [3], or [4] for an
> example of how a panel reset or backlight GPIO can be parametrized).

So the problem is already recognized for years...  what stops from wider adoption of this or similar 
solutions?

And - if/while that is not being done - can't we at least try to follow more portable DT coding pattern 
while staying within existing concepts?

Nikita