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

[Michael Walle <mwalle@kernel.org>]

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