From: Luca Ceresoli <luca.ceresoli@bootlin.com>
To: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: "Tomi Valkeinen" <tomi.valkeinen@ideasonboard.com>,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org,
"Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Wolfram Sang" <wsa@kernel.org>,
"Matti Vaittinen" <Matti.Vaittinen@fi.rohmeurope.com>,
"Laurent Pinchart" <laurent.pinchart+renesas@ideasonboard.com>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Peter Rosin" <peda@axentia.se>,
"Liam Girdwood" <lgirdwood@gmail.com>,
"Mark Brown" <broonie@kernel.org>,
"Sakari Ailus" <sakari.ailus@linux.intel.com>,
"Michael Tretter" <m.tretter@pengutronix.de>,
"Shawn Tu" <shawnx.tu@intel.com>,
"Hans Verkuil" <hverkuil@xs4all.nl>,
"Mike Pagano" <mpagano@gentoo.org>,
"Krzysztof Hałasa" <khalasa@piap.pl>,
"Marek Vasut" <marex@denx.de>,
"Luca Ceresoli" <luca@lucaceresoli.net>
Subject: Re: [PATCH v7 1/7] i2c: add I2C Address Translator (ATR) support
Date: Thu, 19 Jan 2023 09:21:15 +0100 [thread overview]
Message-ID: <20230119092115.02cbbab3@booty> (raw)
In-Reply-To: <Y8gu4mlXUlyiFKZD@smile.fi.intel.com>
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
Alias table:
A, B and C are three physical I2C busses, electrically independent from
each other. The ATR receives the transactions initiated on bus A and
propagates them on bus B or bus C or none depending on the device address
in the transaction and based on the alias table.
Alias table:
.. table::
=============== =====
Client Alias
=============== =====
X (bus B, 0x10) 0x20
Y (bus C, 0x10) 0x30
=============== =====
Transaction:
- Slave X driver sends a transaction (on adapter B), slave address 0x10
- ATR driver finds slave X is on bus B and has alias 0x20, rewrites
messages with address 0x20, forwards to adapter A
- Physical I2C transaction on bus A, slave address 0x20
- ATR chip detects transaction on address 0x20, finds it in table,
propagates transaction on bus B with address translated to 0x10,
keeps clock streched on bus A waiting for reply
- Slave X chip (on bus B) detects transaction at its own physical
address 0x10 and replies normally
- ATR chip stops clock stretching and forwards reply on bus A,
with address translated back to 0x20
- ATR driver receives the reply, rewrites messages with address 0x10
as they were initially
- Slave X driver gets back the msgs[], with reply and address 0x10
Let me know whether this sounds better. And perhaps Tomi can further
improve it.
> > > > +void i2c_atr_set_driver_data(struct i2c_atr *atr, void *data)
> > > > +{
> > > > + atr->priv = data;
> > > > +}
> > > > +EXPORT_SYMBOL_NS_GPL(i2c_atr_set_driver_data, I2C_ATR);
> > > > +
> > > > +void *i2c_atr_get_driver_data(struct i2c_atr *atr)
> > > > +{
> > > > + return atr->priv;
> > > > +}
> > > > +EXPORT_SYMBOL_NS_GPL(i2c_atr_get_driver_data, I2C_ATR);
> > >
> > > Just to be sure: Is it really _driver_ data and not _device instance_ data?
> >
> > It is device instance data indeed. I don't remember why this got
> > changed, but in v3 it was i2c_atr_set_clientdata().
>
> It's me who was and is against calling it clientdata due to possible
> confusion with i2c_set/get_clientdata() that is about *driver data*.
> I missed that time the fact that this is about device instance data.
> I dunno which name would be better in this case, i2c_atr_set/get_client_priv() ?
Not sure I'm following you here. The i2c_atr_set_clientdata() name was
given for similarity with i2c_set_clientdata(). The latter wraps
dev_set_drvdata(), which sets `struct device`->driver_data. There is
one driver_data per each `struct device` instance, not per each driver.
The same goes for i2c_atr_set_driver_data(): there is one priv pointer
per each `struct i2c_atr` instance.
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2023-01-19 8:21 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-18 12:40 [PATCH v7 0/7] i2c-atr and FPDLink Tomi Valkeinen
2023-01-18 12:40 ` [PATCH v7 1/7] i2c: add I2C Address Translator (ATR) support Tomi Valkeinen
2023-01-18 14:23 ` Andy Shevchenko
2023-01-18 17:17 ` Luca Ceresoli
2023-01-18 17:39 ` Andy Shevchenko
2023-01-19 8:21 ` Luca Ceresoli [this message]
2023-01-19 10:09 ` Tomi Valkeinen
2023-01-19 11:35 ` Luca Ceresoli
2023-01-19 12:22 ` Tomi Valkeinen
2023-01-19 13:00 ` Luca Ceresoli
2023-01-20 9:55 ` Laurent Pinchart
2023-01-20 13:58 ` Luca Ceresoli
2023-01-19 12:39 ` Tomi Valkeinen
2023-01-19 13:08 ` Luca Ceresoli
2023-01-19 10:01 ` Tomi Valkeinen
2023-01-20 15:58 ` Andy Shevchenko
2023-01-20 16:00 ` Tomi Valkeinen
2023-01-18 12:40 ` [PATCH v7 2/7] dt-bindings: media: add TI DS90UB913 FPD-Link III Serializer Tomi Valkeinen
2023-01-18 12:40 ` [PATCH v7 3/7] dt-bindings: media: add TI DS90UB953 " Tomi Valkeinen
2023-01-18 12:40 ` [PATCH v7 4/7] dt-bindings: media: add TI DS90UB960 FPD-Link III Deserializer Tomi Valkeinen
2023-01-19 23:24 ` Laurent Pinchart
2023-01-18 12:40 ` [PATCH v7 5/7] media: i2c: add DS90UB960 driver Tomi Valkeinen
2023-01-18 15:48 ` Andy Shevchenko
2023-01-19 16:27 ` Tomi Valkeinen
2023-01-19 23:19 ` Laurent Pinchart
2023-01-20 16:47 ` Andy Shevchenko
2023-01-25 11:15 ` Tomi Valkeinen
2023-01-25 12:10 ` Andy Shevchenko
2023-01-25 13:33 ` Tomi Valkeinen
2023-01-25 14:49 ` Andy Shevchenko
2023-01-25 15:14 ` Tomi Valkeinen
2023-01-25 15:27 ` Andy Shevchenko
2023-01-26 8:41 ` Tomi Valkeinen
2023-01-26 10:21 ` Andy Shevchenko
2023-01-26 10:51 ` Laurent Pinchart
2023-01-27 8:24 ` Tomi Valkeinen
2023-01-27 9:15 ` Andy Shevchenko
2023-02-08 15:10 ` Tomi Valkeinen
2023-02-09 10:54 ` Laurent Pinchart
2023-01-18 12:40 ` [PATCH v7 6/7] media: i2c: add DS90UB913 driver Tomi Valkeinen
2023-01-20 0:03 ` Laurent Pinchart
2023-01-20 7:04 ` Tomi Valkeinen
2023-01-20 9:06 ` Laurent Pinchart
2023-01-18 12:40 ` [PATCH v7 7/7] media: i2c: add DS90UB953 driver Tomi Valkeinen
2023-01-20 0:34 ` Laurent Pinchart
2023-01-20 8:13 ` Tomi Valkeinen
2023-01-20 9:23 ` Laurent Pinchart
2023-01-18 16:01 ` [PATCH v7 0/7] i2c-atr and FPDLink Andy Shevchenko
2023-01-18 17:28 ` Tomi Valkeinen
2023-01-18 17:43 ` Andy Shevchenko
2023-01-19 8:43 ` Luca Ceresoli
2023-01-19 12:40 ` Tomi Valkeinen
2023-01-19 13:19 ` Luca Ceresoli
2023-01-20 16:00 ` Andy Shevchenko
2023-01-20 16:17 ` Luca Ceresoli
2023-01-20 16:20 ` Tomi Valkeinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230119092115.02cbbab3@booty \
--to=luca.ceresoli@bootlin.com \
--cc=Matti.Vaittinen@fi.rohmeurope.com \
--cc=andriy.shevchenko@intel.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=hverkuil@xs4all.nl \
--cc=khalasa@piap.pl \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=lgirdwood@gmail.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=luca@lucaceresoli.net \
--cc=m.tretter@pengutronix.de \
--cc=marex@denx.de \
--cc=mchehab@kernel.org \
--cc=mpagano@gentoo.org \
--cc=peda@axentia.se \
--cc=robh+dt@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=shawnx.tu@intel.com \
--cc=tomi.valkeinen@ideasonboard.com \
--cc=wsa@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.