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

Hi Nikita,

On Thu, Dec 30, 2021 at 08:30:43AM +0300, Nikita Yushchenko wrote:

quoted

quoted

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.
...

 >

quoted

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.

quoted

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.

-- 
Regards,

Laurent Pinchart