Re: [PATCH v2 2/3] i2c: atr: Allow unmapped addresses from nested ATRs

[Luca Ceresoli <luca.ceresoli@bootlin.com>]

Hello Tomi,

On Fri, 29 Nov 2024 15:31:45 +0200
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> 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