Hi,
On 13/02/2025 14:33, Aradhya Bhatia wrote:
+ ti,companion-oldi:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to companion OLDI transmitter. This property is
mandatory for the
+ primarty OLDI TX if the OLDI TXes are expected to work either
in dual-lvds
+ mode or in clone mode. This property should point to the
secondary OLDI
+ TX.
+
+ ti,secondary-oldi:
+ type: boolean
+ description:
+ Boolean property to mark the OLDI transmitter as the secondary
one, when the
+ OLDI hardware is expected to run as a companion HW, in cases of
dual-lvds
+ mode or clone mode. The primary OLDI hardware is responsible
for all the
+ hardware configuration.
I think these work, but I'm wondering if we would ever need to check
something from the main oldi from the secondary oldi. In that case
"crossed phandles" would be better, i.e. something like:
(in the first oldi:)
ti,slave-oldi = <phandle-to-second-oldi>
(in the second oldi:)
ti,master-oldi = <phandle-to-first-oldi>
When I had first designed the code and the devicetree for OLDI, it was
done so with the belief that we wouldn't reqiure a bridge instance for
the secondary OLDI, at all.
While that idea holds true for dual-lvds configuration, it doesn't so
for the clone mode configuration. For clone mode, as you pointed out, we
will require a 2nd bridge instance to configure any of the bridges and
panels that come after the 2nd OLDI.
Then again, if we ever need that, even with these bindings the driver
could find the first oldi, but needs to go via the dss's node.
While it is possible to do it this way, it might not be the cleanest
one. And _if_ there is a ever a DSS in future with more than 2 OLDI
TXes, say 4, then the decipher logic may get too complicated.
While I cannot think of any case where the secondary OLDI bridge DT
might need to access the primary OLDI bridge at the moment, I wonder if
we should play it safer and have this option anyway.
Maybe something like this?
(primary OLDI)
ti,primary-oldi;
ti,companion-oldi = <phandle-to-secondary-oldi>;
(secondary OLDI)
ti,secondary-oldi;
ti,companion-oldi = <phandle-to-primary-oldi>;
How is this different than my proposal, except a bit more verbose?
If you're thinking about a 4-OLDI hardware, how would this work there?
(but I want to say that even if it's good to plan for the future, we
shouldn't plan too much based on imaginary hardware =).
Tomi
