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] [thread-next>] [day] [month] [year] [list]

Message-ID: <fc5f6000fbe1f01223f8a28a952b40ea@kernel.org>
Date: Wed, 28 May 2025 10:27:04 +0200
From: Michael Walle <mwalle@...nel.org>
To: Aradhya Bhatia <aradhya.bhatia@...ux.dev>
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 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.

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

     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