Re: [PATCH v8 4/4] drm/tidss: Add OLDI bridge support

[Aradhya Bhatia <aradhya.bhatia@linux.dev>]

Hi Michael,

On 28/05/25 13:57, Michael Walle wrote:
> 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.

I was not aware that deleting properties was not allowed/possible. So,
yes, seems like they are better left out of 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:

Not the DSS0 alone. DSS0 and DSS1 can each drive a single link OLDI
display simultaneously.

> 
>     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

-- 
Regards
Aradhya