Hi Nikita,
On Thu, Dec 30, 2021 at 08:30:43AM +0300, Nikita Yushchenko wrote:
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.
We could do this by adding a label to the port instead of the endpoint in the SoC .dtsi.
lvds0: lvds@.... { ...
ports { port@0 { lvds0_in: endpoint { remote-endpoint = <&du_out_lvds0>; }; };
lvds_out_panel_port: port@1 { }; };
It would however likely be better do add the label to port@1 in the board .dts though, as usage of a particular LVDS output is a board property, not an SoC property.
Then, in the overlay,
panel { port { panel_in: endpoint { remote_endpoint <&lvds_out_panel>; }; }; };
&lvds_out_panel_port { lvds_out_panel: endpoint { remote-endpoint = <&panel_in>; }; };
There's one caveat though: The LVDS DT nodes are disabled in the SoC .dtsi, so the overlay would need to have
&lvds0 { status = "okay"; };
and that would need to reference the correct lvds node. Without parameterized overlays, I don't think we can solve this issue neatly (especially given that panels will often have control GPIOs, or GPIO-controlled regulators, that could be wired to different SoC GPIOs on different boards).
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?
Someone to continue working on it I suppose :-)
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?
We could use a label for the port node as shown above. It's not a complete solution, but it may help. I'm not sure how to solve the enabling of the lvds encoder DT node though.