Hi Tomi, Andy, On Thu, 19 Jan 2023 14:39:09 +0200 Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx> wrote: > On 19/01/2023 10:21, Luca Ceresoli wrote: > > Hi Andy, > > > > On Wed, 18 Jan 2023 19:39:46 +0200 > > Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> wrote: > > > >> On Wed, Jan 18, 2023 at 06:17:53PM +0100, Luca Ceresoli wrote: > >>> On Wed, 18 Jan 2023 16:23:53 +0200 > >>> Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> wrote: > >> > >> ... > >> > >>>>> +A typical example follows. > >>>>> + > >>>>> +Topology:: > >>>>> + > >>>>> + Slave X @ 0x10 > >>>>> + .-----. | > >>>>> + .-----. | |---+---- B > >>>>> + | CPU |--A--| ATR | > >>>>> + `-----' | |---+---- C > >>>>> + `-----' | > >>>>> + Slave Y @ 0x10 > >>>>> + > >>>>> +Alias table: > >>>>> + > >>>>> +.. table:: > >>>>> + > >>>>> + ====== ===== > >>>>> + Client Alias > >>>>> + ====== ===== > >>>>> + X 0x20 > >>>>> + Y 0x30 > >>>>> + ====== ===== > >>>>> + > >>>>> +Transaction: > >>>>> + > >>>>> + - Slave X driver sends a transaction (on adapter B), slave address 0x10 > >>>>> + - ATR driver rewrites messages with address 0x20, forwards to adapter A > >>>>> + - Physical I2C transaction on bus A, slave address 0x20 > >>>>> + - ATR chip propagates transaction on bus B with address translated to 0x10 > >>>>> + - Slave X chip replies on bus B > >>>>> + - ATR chip forwards reply on bus A > >>>>> + - ATR driver rewrites messages with address 0x10 > >>>>> + - Slave X driver gets back the msgs[], with reply and address 0x10 > >>>> > >>>> I'm not sure I got the real / virtual status of the adapters. Are the B and C > >>>> virtual ones, while A is the real? > >>> > >>> Let me reply, as I wrote these docs back at the times and thus I feel > >>> guilty in case that's unclear. :) > >>> > >>> I don't like the word "virtual" in this situation. A, B and C are all > >>> physical busses, made of copper and run by electrons on PCBs. B and C > >>> are the "remote" or "downstream" busses (w.r.t. the CPU), where the i2c > >>> devices are and where transactions happen using the address that the > >>> chip responds to. A is the "local" or "upstream" bus that is driven > >>> directly by the CPU (*) and where address aliases are used. Using > >>> aliases there is necessary because using address 0x10 would be > >>> ambiguous as there are two 0x10 chips out there. > >>> > >>> (*) There could be more layers of course, but still A is "closer to the > >>> CPU than B and C", for the sake of completeness. > >> > >> Can the diagram and/or text be updated to elaborate this? > > > > Let's see whether the text below is better. I haven't changed the > > image, I don't think we can do much more in ASCII, but maybe we can > > replace it with an SVG [0]? > > > > [0] > > https://github.com/lucaceresoli/docs/blob/master/video-serdes-linux/images/i2c-ti.svg > > > > A typical example follows. > > > > Topology:: > > > > Slave X @ 0x10 > > .-----. | > > .-----. | |---+---- B > > | CPU |--A--| ATR | > > `-----' | |---+---- C > > `-----' | > > Slave Y @ 0x10 > > Slightly beside the point of this discussion, but one thing (I think) I > tried to highlight in some older cover letter was that we don't really > have the above structure. We have something like this (a quick edit, sorry): > > .------. Slave X @ 0x10 > .------. | FPDS | | > .-----. | FPDD |-F1-`------'---+---- B > | CPU |--A--| ATR | > `-----' | |-F2-.------.---+---- C > `------' | FPDS | | > `------' Slave Y @ 0x10 > > Where FPDD = Deserializer, FPDS = Serializer, F1/F2 = FPD-Link bus 1/2. > > So the ATR functionality is in the deserializer, but the actual remote > i2c bus is on the serializer. I'd rather say that the ATF functionality is in the sum of ser+des as they really cooperate. But this is kind of philosophical. :) What matters is that it's worth mentioning that the "ATR" box is actually an abstract visualization of a feature that is provided by two or more chips (in the known universe, at least). -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
