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@xxxxxxxxxxxxxxxx/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
