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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 30 Dec 2021 19:11:11 +0200
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Nikita Yushchenko <nikita.yoush@...entembedded.com>
Cc:     Geert Uytterhoeven <geert+renesas@...der.be>,
        Magnus Damm <magnus.damm@...il.com>,
        Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Rob Herring <robh+dt@...nel.org>,
        dri-devel@...ts.freedesktop.org, linux-renesas-soc@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: 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:
> >> 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.

-- 
Regards,

Laurent Pinchart