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
