Hi Aradhya,
Something like this.
&oldi0 {
// primary oldi
ti,companion-oldi = <&oldi1>;
};
&oldi1 {
// secondary oldi
ti,secondary-oldi = true;
ti,companion-oldi = <&oldi0>;
};
If there is no companion for any OLDI dt node, then the OLDI TX will
be
deemed as acting by itself, and in a single-link mode.
And it's possible to still have these properties and treat them as
two distinct transmitters? I'm wondering if it's possible to have
the companion-oldi and secondary-oldi property inside the generic
SoC dtsi, so you don't have to repeat it in every board dts.
If I read the code correctly, the panel has to have the even and odd
pixel properties to be detected as dual-link. Correct? Thus it would
be possible to have
oldi0: oldi@0 {
ti,companion-oldi = <&oldi1>;
};
oldi1: oldi@1 {
ti,secondary-oldi;
ti,companion-oldi = <&oldi0>;
};
in the soc.dtsi and in a board dts:
panel {
port {
remote-endpoint = <&oldi0>;
};
};
In this case, the secondary OLDI (oldi1) would remain disabled from
soc.dtsi.
I gave this a quick try. Turns out, of_parse_phandle() is not able to
return an error when primary OLDI tries to find a companion -- which is
important for the driver to detect an absence of any secondary OLDI.
Since the driver code registers a companion for primary OLDI, and
further does not find the "dual-lvds-{odd,even}-pixels" properties,
the driver ends up trying for a Clone Mode.
So, for single-link , we'd have to actively delete the "companion-oldi"
property, in the board.dts/panel.dtso.
Last time I've checked you cannot delete nodes or properties in DT
overlays. So maybe it's better to make that a board property and don't
set it by default in the soc dtsi.
But, say, the disabled-node's phandle parse is circumvented, somehow,
and we don't need to delete the property explicitly.
There would still be one concern, I am afraid.
In AM67A DSS (future scope at the moment), the 2 OLDIs can act
independently. Like a 2x Independent Single-Link. Both the OLDI dt
nodes
will be enabled.
The first DSS0 can drive two single link displays? Reading your
downstream
AM67A DSS patches, thats not particular clear:
The DSS0 HW supports one each of video pipeline (vid) and video-lite
pipeline (vidl1). It outputs OLDI signals on one video port (vp1)
and
DPI signals on another (vp2). The video ports are connected to the
pipelines via 2 identical overlay managers (ovr1 and ovr2).
The TRM also doesn't tell much (or I just didn't find it yet).
So, if the soc.dtsi has them already connected, then the
board.dts/panel.dtso would still need to explicitly delete those
properties to get the 2 OLDI TXes to work independently.
Yeah looks like that should really be a board property.
-michael
