From: Wolfram Sang <wsa@the-dreams.de>
To: Luca Ceresoli <luca@lucaceresoli.net>
Cc: Peter Rosin <peda@axentia.se>, jacopo mondi <jacopo@jmondi.org>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Hans Verkuil <hverkuil-cisco@xs4all.nl>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Kieran Bingham <kieran.bingham@ideasonboard.com>,
Vladimir Zapolskiy <vz@mleia.com>
Subject: Re: [RFC,v2 2/6] i2c: add I2C Address Translator (ATR) support
Date: Tue, 10 Sep 2019 19:46:53 +0100 [thread overview]
Message-ID: <20190910184653.GB5581@kunai> (raw)
In-Reply-To: <2d770b36-9521-820d-726a-bc9b52048ef8@lucaceresoli.net>
[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]
> I still have to examine in depth all of the problems in the i2c-mux
> documented in Documentation/i2c/i2c-topology (thanks for having written
> those docs!), but at first sight it looks like the ATR is not going to
> introduce big problems because of how it works.
Assuming we are using the previously discussed NEEDS_ATR flag for the adapter
instead of the attach/detach callbacks:
Can't we then simply understand an ATR as a generic 1:1 mapping device
which can be setup when registering an adapter?
When we add an adapter using i2c_add_adapter, we have:
.-----. Slave X @ 0x10
.-----. | | |
| CPU |--A--| ATR |---+---- B
`-----' | |
`-----'
When we use i2c_add_mux_adapter, we have:
Slave X @ 0x10
.-----. .-----. |
.-----. | |---| ATR |---+---- B
| CPU |--A--| MUX | '-----'
`-----' | | .-----.
| |---| ATR |---+---- C
`-----' '-----' |
Slave Y @ 0x10
That way we could keep the topology handling solely to the mux-core.
Am I overlooking something?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-09-10 18:46 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-23 20:37 [RFC,v2 0/6] TI camera serdes and I2C address translation Luca Ceresoli
2019-07-23 20:37 ` [RFC,v2 1/6] i2c: core: let adapters be notified of client attach/detach Luca Ceresoli
2019-07-23 20:37 ` [RFC,v2 2/6] i2c: add I2C Address Translator (ATR) support Luca Ceresoli
2019-09-01 14:31 ` jacopo mondi
2019-09-03 7:31 ` Luca Ceresoli
2019-09-03 7:37 ` Wolfram Sang
2019-09-04 8:09 ` Peter Rosin
2019-09-08 19:40 ` Luca Ceresoli
2019-09-10 18:46 ` Wolfram Sang [this message]
2019-09-08 20:45 ` Vladimir Zapolskiy
2019-09-09 4:56 ` Vladimir Zapolskiy
2019-09-10 17:40 ` Luca Ceresoli
2019-09-09 7:22 ` Wolfram Sang
2019-09-09 15:10 ` Vladimir Zapolskiy
2019-09-09 17:48 ` Luca Ceresoli
2019-09-10 17:16 ` Wolfram Sang
2019-09-02 20:42 ` Wolfram Sang
2019-09-03 8:48 ` Luca Ceresoli
2019-09-03 9:06 ` Wolfram Sang
2019-07-23 20:37 ` [RFC,v2 3/6] media: dt-bindings: add DS90UB954-Q1 video deserializer Luca Ceresoli
2019-08-13 15:44 ` Rob Herring
2019-08-19 22:41 ` Luca Ceresoli
2019-08-20 15:44 ` Rob Herring
2019-08-21 21:50 ` Luca Ceresoli
2019-09-02 20:48 ` Wolfram Sang
2019-09-03 9:09 ` Luca Ceresoli
2019-09-03 9:34 ` Wolfram Sang
2019-09-03 11:03 ` Luca Ceresoli
2019-09-03 14:16 ` Wolfram Sang
2019-09-10 9:43 ` Sakari Ailus
2019-09-10 15:02 ` Luca Ceresoli
2019-07-23 20:37 ` [RFC,v2 4/6] media: dt-bindings: add DS90UB953-Q1 video serializer Luca Ceresoli
2019-07-23 20:37 ` [RFC,v2 5/6] media: ds90ub954: new driver for TI DS90UB954-Q1 video deserializer Luca Ceresoli
2019-07-23 20:37 ` [RFC,v2 6/6] media: ds90ub953: new driver for TI DS90UB953-Q1 video serializer Luca Ceresoli
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=20190910184653.GB5581@kunai \
--to=wsa@the-dreams.de \
--cc=devicetree@vger.kernel.org \
--cc=hverkuil-cisco@xs4all.nl \
--cc=jacopo@jmondi.org \
--cc=kieran.bingham@ideasonboard.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=luca@lucaceresoli.net \
--cc=mark.rutland@arm.com \
--cc=mchehab@kernel.org \
--cc=peda@axentia.se \
--cc=robh+dt@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=vz@mleia.com \
/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.