Message-ID: <cd62bf21-adad-4422-8fac-ebd20e8b39a5@ideasonboard.com>
Date: Thu, 13 Feb 2025 15:20:48 +0200
From: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To: Aradhya Bhatia <aradhya.bhatia@...ux.dev>
Cc: 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>,
 DRI Development List <dri-devel@...ts.freedesktop.org>,
 Devicetree List <devicetree@...r.kernel.org>,
 Linux Kernel List <linux-kernel@...r.kernel.org>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Jyri Sarha <jyri.sarha@....fi>
Subject: Re: [PATCH v5 2/3] dt-bindings: display: ti: Add schema for AM625
 OLDI Transmitter

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

Powered by blists - more mailing lists