Back-port I2C ATR (Address translator) #2536
Conversation
An ATR is a device that looks similar to an i2c-mux: it has an I2C slave "upstream" port and N master "downstream" ports, and forwards transactions from upstream to the appropriate downstream port. But it is different in that the forwarded transaction has a different slave address. The address used on the upstream bus is called the "alias" and is (potentially) different from the physical slave address of the downstream chip. Add a helper file (just like i2c-mux.c for a mux or switch) to allow implementing ATR features in a device driver. The helper takes care or adapter creation/destruction and translates addresses at each transaction. Signed-off-by: Luca Ceresoli <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Acked-by: Wolfram Sang <[email protected]>
btogorean
requested review from
nunojsa,
mhennerich,
dbogdan,
chegbeli,
buha,
amiclaus,
rbolboac,
danmois,
CiprianRegus and
machschmitt
as code owners
| return -ENXIO; | ||
| } | ||
| if (!c2a) | ||
| continue; |
There was a problem hiding this comment.
Well, the expected question from me is this a valid usecase that should be upstreamed?
There was a problem hiding this comment.
I think this has been upstreamed and this is a backport, or?
There was a problem hiding this comment.
If it is, I would expect a cherry-pick which would include additional sign-offs and so I would not question :). Note that I'm speaking about the second patch.
There was a problem hiding this comment.
Yes, this has not been upstreamed yet. The usecase is that on the same I2C bus of the deserializer you can have multiple serializers (which need the ATR to be able to setup individual communication by changing their address) and then another ATR for the serializer since they need to do address translation for the connected cameras. The serializer ATR provides the final translation of the cameras, and an unknown I2C address reaches this deserializer code, which we just want to pass through.
There was a problem hiding this comment.
If it is, I would expect a cherry-pick which would include additional sign-offs and so I would not question :). Note that I'm speaking about the second patch.
oh; my bad;
apologies for the noise;
i need to re-adapt to reading these kernel patches
There was a problem hiding this comment.
Yes, this has not been upstreamed yet. The usecase is that on the same I2C bus of the deserializer you can have multiple serializers (which need the ATR to be able to setup individual communication by changing their address) and then another ATR for the serializer since they need to do address translation for the connected cameras. The serializer ATR provides the final translation of the cameras, and an unknown I2C address reaches this deserializer code, which we just want to pass through.
I see... I won't opinate much about the patch. Maybe a dev_warn() or dev_dbg() would make sense. Other option would be some DT property to mark an i2c as "pass through" instead of just continuing and ignoring the lack of mapping (if it makes any sense) .
Anyways, most important thing (as you already know :)) is that this is sent upstream.
PR Description
Back-port I2C address translator functionality. This is required for ADI GMSL drivers
PR Type
PR Checklist