linux-kernel - Re: [PATCH v5 2/3] dt-bindings: display: ti: Add schema for AM625 OLDI Transmitter

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: <20250219142042.GA2436009-robh@kernel.org>
Date: Wed, 19 Feb 2025 08:20:42 -0600
From: Rob Herring <robh@...nel.org>
To: Aradhya Bhatia <aradhya.bhatia@...ux.dev>
Cc: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
	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>,
	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

On Fri, Feb 14, 2025 at 06:11:11PM +0530, Aradhya Bhatia wrote:
> 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.

I prefer the data in the DT be the minimum needed. Parsing the DT 
doesn't need to be particularly fast because you should only do it once. 
There's even a function already to find occurrences of a property name 
all over the tree.

Rob