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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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?

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?

Nikita



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux