Hello Tomi, On Fri, 29 Nov 2024 15:31:45 +0200 Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx> wrote: > On 29/11/2024 13:53, Luca Ceresoli wrote: > > >> So strictly speaking it's not an ATR, but this achieves the same. > > > > Thanks for the extensive and very useful explanation. I had completely > > missed the GMSL serder and their different I2C handling, apologies. > > > > So, the "parent ATR" is the GMSL deser, which is not an ATR but > > implementing it using i2c-atr makes the implementation cleaner. That > > makes sense. > > Right. > > But, honestly, I can't make my mind if I like the use of ATR here or not =). Hehe, indeed, hardware designers use a lot of fantasy in stretching the I2C standard to its limits, perhaps more than actually needed. > So it's not an ATR, but I'm not quite sure what it is. It's not just > that we need to change the addresses of the serializers, we need to do > that in particular way, enabling one port at a time to do the change. > > If we forget about the init time hurdles, and consider the situation > after the serializers are been set up and all ports have been enabled, > we have: > > There's the main i2c bus, on which we have the deserializer. The > deserializer acts as a i2c repeater (for any transaction that's not > directed to the deser), sending the messages to all serializers. The > serializers catch transactions directed at the ser, and everything else > goes through ATR and to the remote bus. > > Do we have something that represents such a "i2c repeater"? I guess we > could just have an i2c bus, created by the deser, and all the sers would > be on that bus. So we'd somehow do the initial address change first, > then set up the i2c bus, and the serializer i2c clients would be added > to that bus. So you think about another thing, like i2c-repeater, in addition to i2c-mux and i2c-atr? Well, I think it would make sense, as it would generalize a feature that might be used by other chips. However at the moment we do have a working driver for the GMSL deser, and so I don't see the benefit of extracting the i2c-repeater functionality to a separate file, unless there are drivers for other chips being implemented: this would motivate extracting common features to a shared file. IOW, I'd not generalize something with a single user. [Interesting side note: the i2c-atr has been implemented with a single user, violating the above principle O:-) but I think that was due to the similarity with i2c-mux or something like that. Out of luck, another ATR user appeared after some time.] Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
