[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190910184653.GB5581@kunai>
Date: Tue, 10 Sep 2019 19:46:53 +0100
From: Wolfram Sang <wsa@...-dreams.de>
To: Luca Ceresoli <luca@...aceresoli.net>
Cc: Peter Rosin <peda@...ntia.se>, jacopo mondi <jacopo@...ndi.org>,
"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Hans Verkuil <hverkuil-cisco@...all.nl>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Kieran Bingham <kieran.bingham@...asonboard.com>,
Vladimir Zapolskiy <vz@...ia.com>
Subject: Re: [RFC,v2 2/6] i2c: add I2C Address Translator (ATR) support
> 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?
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists