Message-ID: <062b78a3-7e83-4202-a753-4e7bd43e8bc2@linux.dev>
Date: Fri, 14 Feb 2025 18:11:11 +0530
From: Aradhya Bhatia <aradhya.bhatia@...ux.dev>
To: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
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 Tomi,


On 13/02/25 18:50, Tomi Valkeinen wrote:
> 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?

That's all the difference there is. Just an alternative to what you
suggested.

> 
> If you're thinking about a 4-OLDI hardware, how would this work there?

I didn't mean that my alternative would be more helpful. I meant that
passing phandles would be a simpler way for 4-OLDI hardware in general.

We'd have to sift through a max of 4 OLDI nodes to find the right
primary OLDI for a given secondary OLDI - if we try to find it via the
dss and oldi-transmitter parent DT nodes. Passing phandles directly
would save on all that logic.


> (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 =).
> 

That's, of course, true too! =)
It's been tricky enough dealing with the hardware combinations as they
are today!

I will add one more reason though, which made me get along with the idea
of passing phandles. And then I will defer to you to make the call,
since I don't have the strongest of feelings either way.


Passing phandles would allow for _that_ condition to get dropped; making
the bindings slightly more flexible to accommodate for any future
surprises (especially around the clone mode lvds configuration).

(That condition being where the bindings either allow a companion-oldi
phandle OR allow the secondary-oldi boolean (but not both)).

I could drop that condition without any other changes too, making the
companion-oldi property optional for secondary-oldi - but this feels
incomplete.

Hence, the addition of the primary-oldi boolean. The companion-oldi
phandle property will be conditionally required when any one of the
boolean properties is present.


-- 
Regards
Aradhya

Powered by blists - more mailing lists