Re: [PATCH v4 3/8] dt-bindings: media: add bindings for TI DS90UB960

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Luca,

On 11/11/2022 18:26, Luca Ceresoli wrote:
Hello Tomi, Matti, Wolfram,

On Thu, 3 Nov 2022 14:32:02 +0200
Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx> wrote:

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.

The i2c-alias-pool was discussed during the RFC,v2 review [1] and it
was agreed that it should be generic. The same principle should apply
to the other ATR properties.

That said, at some point it was also decided that the alias pool should
just be ditched in favor of an automatic selection of an unused address
by the i2c core [2] [3]. Maybe that idea has changed, definitely some
i2c core things needed to be omdified for it to happen, but overall I'm
still convinced automatic assignment without a pool was a good idea.

Yes, the serializer and the remote peripheral i2c aliases can be dynamically reserved at runtime, so the i2c-alias-pool and the i2c-alias are, in that sense, not needed.

I haven't looked at this in depth yet, but reading the references you gave, it sounds like it's not quite clear what addresses are available and what are not.

On the other hand, is dynamic i2c address reservation something that the users expect to happen? All i2c devices I have used have always had a fixed address in the DT, even if at times the devices may support choosing between a few different addresses.

Keeping with that tradition, would it be best to just use fixed i2c aliases, defined in the DT, for the serializers and the remote peripherals? In the current series this is already the case for serializers (with i2c-alias property), but we could do something similar for the remote peripherals.

 Tomi




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux