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
