[PATCH v5 2/3] dt-bindings: display: ti: Add schema for AM625 OLDI Transmitter
Tomi Valkeinen
tomi.valkeinen at ideasonboard.com
Thu Feb 13 13:20:48 UTC 2025
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
More information about the dri-devel
mailing list