Date:   Thu, 30 Dec 2021 00:19:31 +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 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@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

Powered by blists - more mailing lists