Re: [PATCH v7 1/7] i2c: add I2C Address Translator (ATR) support

Luca Ceresoli
2023-01-19T13:09:02Z

Hi Tomi, Andy,

On Thu, 19 Jan 2023 14:39:09 +0200
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> 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@intel.com> 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@intel.com> 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