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

[Rob Herring <robh@kernel.org>]

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