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
