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
