Messages in this thread | | | Date | Thu, 3 Nov 2022 14:32:02 +0200 | Subject | Re: [PATCH v4 3/8] dt-bindings: media: add bindings for TI DS90UB960 | From | Tomi Valkeinen <> |
| |
On 03/11/2022 14:13, Vaittinen, Matti wrote: > On 11/3/22 13:50, Tomi Valkeinen wrote: >> Hi Rob, >> >> On 02/11/2022 19:26, Rob Herring wrote: >>> On Tue, Nov 01, 2022 at 03:20:27PM +0200, Tomi Valkeinen wrote: >>>> + >>>> + i2c-alias-pool: >>> >>> Something common or could be? If not, then needs a vendor prefix. >> >> I'll have to think about this. It is related to the i2c-atr, so I think >> it might be a common thing. > > I'd say this should be common. Where the i2c-atr properties should live > is another question though. If the I2C-atr stays as a genericly usable > component - then these bindings should be in a file that can be > referenced by other I2C-atr users (like the UB960 here).
Yep. All the links, link, serializer and alias nodes/properties are new things here, and I guess these could be used by other deser-ser systems. That said, I don't have any experience with other systems.
> // snip > >>>> + >>>> + i2c-alias: >>> >>> Vendor prefix. >>> >>>> + description: | >>>> + The i2c address used for the serializer. Transactions >>>> to this >>>> + address on the i2c bus where the deserializer resides are >>>> + forwarded to the serializer. >>>> + >>>> + rx-mode: >>> >>> Vendor prefix. And so on... > >> Yes, I totally missed these. > > > I think the i2c-alias might need to be common as well?
Perhaps...
I was also thinking that the serializer addresses could be taken from the i2c-alias-pool. But maybe that's not a good idea, as the serializer-access and remote-peripheral-access are a bit different (e.g. no ATR when accessing the serializer).
And I was thinking that, at least here, the alias addresses can be "anything", so they could be reserved dynamically at runtime, without any predefined aliases. But that might be a bit confusing to the user.
Tomi
| |