Documentation/i2c/i2c-topology.rst

2 I2C muxes and complex topologies
5 There are a couple of reasons for building more complex I2C topologies
6 than a straight-forward I2C bus with one adapter and one or more devices.
14    from the I2C bus, at least most of the time, and sits behind a gate
20 These constructs are represented as I2C adapter trees by Linux, where
23 I2C transfers, and all adapters with a parent are part of an "i2c-mux"
27 an I2C transfer on one of its child adapters. The mux driver can
37 There are two variants of locking available to I2C muxes, they can be
48                           same I2C root adapter that they mux.
57                           by the same I2C root adapter that they mux.
86 select and/or deselect operations must use I2C transfers to complete
88 full transaction, unrelated I2C transfers may interleave the different
112      number (one, in most cases) of I2C transfers. Unrelated I2C transfers
115 ML4. If any non-I2C operation in the mux driver changes the I2C mux state,
118      behind the mux, when an unrelated I2C transfer is in flight during
119      the non-I2C mux-changing operation.
140  1. Someone issues an I2C transfer to D1.
143  4. M1 (presumably) does some I2C transfers as part of its select.
144     These transfers are normal I2C transfers that locks the parent
146  5. M1 feeds the I2C transfer from step 1 to its parent adapter as a
147     normal I2C transfer that locks the parent adapter.
162 has to ensure that any and all I2C transfers through that parent
163 adapter during the transaction are unlocked I2C transfers (using e.g.
172      and the parent mux issues I2C transfers as part of its select).
177      pinctrl, regmap or iio, it is essential that any I2C transfers
200  1.  Someone issues an I2C transfer to D1.
204  5.  If M1 does any I2C transfers (on this root adapter) as part of
205      its select, those transfers must be unlocked I2C transfers so
207  6.  M1 feeds the I2C transfer from step 1 to the root adapter as an
208      unlocked I2C transfer, so that it does not deadlock the parent
243 issues any unlocked I2C transfers on the root adapter that may leak
289 be no I2C transfers during its calls to ->select and ->deselect, and
291 as partial I2C transfers, i.e. garbage or worse. This might cause
296 prematurely, as might any I2C transfers part of M1->select.