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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7313e3a4-24bf-42be-901d-e85eb260cc0f@linux.dev>
Date: Wed, 28 May 2025 17:26:35 +0530
From: Aradhya Bhatia <aradhya.bhatia@...ux.dev>
To: Michael Walle <mwalle@...nel.org>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
 Jyri Sarha <jyri.sarha@....fi>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Thomas Zimmermann <tzimmermann@...e.de>, Maxime Ripard <mripard@...nel.org>,
 David Airlie <airlied@...il.com>,
 Laurent Pinchart <laurent.pinchart@...asonboard.com>,
 Simona Vetter <simona@...ll.ch>, Nishanth Menon <nm@...com>,
 Vignesh Raghavendra <vigneshr@...com>, Devarsh Thakkar <devarsht@...com>,
 Praneeth Bajjuri <praneeth@...com>, Udit Kumar <u-kumar1@...com>,
 Jayesh Choudhary <j-choudhary@...com>,
 Francesco Dolcini <francesco@...cini.it>,
 Alexander Sverdlin <alexander.sverdlin@...mens.com>,
 DRI Development List <dri-devel@...ts.freedesktop.org>,
 Devicetree List <devicetree@...r.kernel.org>,
 Linux Kernel List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v8 4/4] drm/tidss: Add OLDI bridge support

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