Re: [PATCH v7 0/5] Add support for MAX96714/F and MAX96717/F GMSL2 ser/des

[Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>]

On 06/06/2024 18:24, Laurent Pinchart wrote:
>> But if the i2c translation is used, it would mean that, say, the sensor
>> driver would need to use the "virtual" address, not the real one to
>> communicate with the sensor device, which doesn't sound right...
 >
> How so ? With FPD-Link, with ATR is enabled, doesn't the sensor driver
> also use the "virtual" (as in host-visible) I2C address instead of the
> real one (as in the address used on the bus physically connected to the
> sensor) ?

No. If we, say, have a sensor hardware that responds to address 0x30, we 
create a new "virtual" or "remote" i2c-bus (let's say i2c-10), on which 
there's the sensor with address 0x30. So for the driver and this 
i2c-bus, everything looks just like the sensor would be connected 
"normally" to the SoC's i2c bus.

So, we have i2c-10 bus with sensor@30. This is what the userspace sees, 
and how the driver sees it. And if we have, say, 2 identical cameras 
behind two links, we have i2c-10 with sensor@30 and i2c-11 with sensor@30.

When the sensor driver does an i2c transaction, the i2c-atr driver will 
catch that transaction before it goes to HW. It will replace the address 
30 in the message with the appropriate alias (say, 50), and issue a HW 
transaction on the SoC's i2c bus where the deserializer resides.

The deserializer sees a message to address 50, and knows that it's a 
message to link 0 with alias 30 (based on the programmed translation 
table). It takes the message, replaces 50 with 30, and sends it to the 
serializer on link 0. The serializer will then transmit that message on 
its i2c master, which will then be received by the sensor@30.

On a reply, the same happens but in reverse.

  Tomi