lkml.org 
[lkml]   [2019]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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?

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2019-09-10 20:49    [W:0.115 / U:0.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site