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

[Laurent Pinchart]

Hi Nikito,

On Thu, Dec 30, 2021 at 12:12:04AM +0300, Nikita Yushchenko wrote:
>   Endpoints are meant to model a link between two ports, so an endpoint
> > shouldn't exist in isolation. The issue with creating named endpoints in
> > SoC files is that you can't tell there what remote devices may exist, so
> > the endpoint may or may not match the actual hardware design of a board.
> > I think it's better to create endpoints on both sides together in
> > overlays.
> > 
> > https://lore.kernel.org/linux-renesas-soc/20211229193135.28767-2-laurent.pinchart+renesas@ideasonboard.com/T/#t
> 
> What I don't like here is: details of particular SoC (such as "panel gets video from port at 1 of &lvds1) 
> leak into per-panel DT fragment.
> 
> This limits possibilities to share DT fragments between different use cases. In the patch pointed by the 
> above URL, you have to reference both board and panel in the dts file name.
>
> 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.
> 
> And similar for backlight, power, and whatever else exposed on the physical panel connector.
> 
> So for the board's physical connector there is a set of board-DT-provided entities for use by DT 
> fragment of whatever component plugged to the connector, without direct references to final SoC 
> interfaces. And possibility to reuse DT fragments between boards, and probably have a library of DT 
> fragments for hardware currently available in the market, usable with different boards where that 
> hardware can be connected.

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.

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

[1] https://lwn.net/Articles/689783/
[2] https://www.raspberrypi.com/documentation/computers/configuration.html#part3
[3] https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README#L122
[4] https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README#L312

-- 
Regards,

Laurent Pinchart