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
