Re: [PATCH v5 2/3] dt-bindings: display: ti: Add schema for AM625 OLDI Transmitter

[Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>]

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