@@ -5,6 +5,8 @@ I2C muxes and complex topologies
55There are a couple of reasons for building more complex I2C topologies
66than a straight-forward I2C bus with one adapter and one or more devices.
77
8+ Some example use cases are:
9+
8101. A mux may be needed on the bus to prevent address collisions.
911
10122. The bus may be accessible from some external bus master, and arbitration
@@ -14,10 +16,10 @@ than a straight-forward I2C bus with one adapter and one or more devices.
1416 from the I2C bus, at least most of the time, and sits behind a gate
1517 that has to be operated before the device can be accessed.
1618
17- Etc
18- ===
19+ Several types of hardware components such as I2C muxes, I2C gates and I2C
20+ arbitrators allow to handle such needs.
1921
20- These constructs are represented as I2C adapter trees by Linux, where
22+ These components are represented as I2C adapter trees by Linux, where
2123each adapter has a parent adapter (except the root adapter) and zero or
2224more child adapters. The root adapter is the actual adapter that issues
2325I2C transfers, and all adapters with a parent are part of an "i2c-mux"
@@ -35,46 +37,7 @@ Locking
3537=======
3638
3739There are two variants of locking available to I2C muxes, they can be
38- mux-locked or parent-locked muxes. As is evident from below, it can be
39- useful to know if a mux is mux-locked or if it is parent-locked. The
40- following list was correct at the time of writing:
41-
42- In drivers/i2c/muxes/:
43-
44- ====================== =============================================
45- i2c-arb-gpio-challenge Parent-locked
46- i2c-mux-gpio Normally parent-locked, mux-locked iff
47- all involved gpio pins are controlled by the
48- same I2C root adapter that they mux.
49- i2c-mux-gpmux Normally parent-locked, mux-locked iff
50- specified in device-tree.
51- i2c-mux-ltc4306 Mux-locked
52- i2c-mux-mlxcpld Parent-locked
53- i2c-mux-pca9541 Parent-locked
54- i2c-mux-pca954x Parent-locked
55- i2c-mux-pinctrl Normally parent-locked, mux-locked iff
56- all involved pinctrl devices are controlled
57- by the same I2C root adapter that they mux.
58- i2c-mux-reg Parent-locked
59- ====================== =============================================
60-
61- In drivers/iio/:
62-
63- ====================== =============================================
64- gyro/mpu3050 Mux-locked
65- imu/inv_mpu6050/ Mux-locked
66- ====================== =============================================
67-
68- In drivers/media/:
69-
70- ======================= =============================================
71- dvb-frontends/lgdt3306a Mux-locked
72- dvb-frontends/m88ds3103 Parent-locked
73- dvb-frontends/rtl2830 Parent-locked
74- dvb-frontends/rtl2832 Mux-locked
75- dvb-frontends/si2168 Mux-locked
76- usb/cx231xx/ Parent-locked
77- ======================= =============================================
40+ mux-locked or parent-locked muxes.
7841
7942
8043Mux-locked muxes
@@ -89,40 +52,8 @@ full transaction, unrelated I2C transfers may interleave the different
8952stages of the transaction. This has the benefit that the mux driver
9053may be easier and cleaner to implement, but it has some caveats.
9154
92- ==== =====================================================================
93- ML1. If you build a topology with a mux-locked mux being the parent
94- of a parent-locked mux, this might break the expectation from the
95- parent-locked mux that the root adapter is locked during the
96- transaction.
97-
98- ML2. It is not safe to build arbitrary topologies with two (or more)
99- mux-locked muxes that are not siblings, when there are address
100- collisions between the devices on the child adapters of these
101- non-sibling muxes.
102-
103- I.e. the select-transfer-deselect transaction targeting e.g. device
104- address 0x42 behind mux-one may be interleaved with a similar
105- operation targeting device address 0x42 behind mux-two. The
106- intension with such a topology would in this hypothetical example
107- be that mux-one and mux-two should not be selected simultaneously,
108- but mux-locked muxes do not guarantee that in all topologies.
109-
110- ML3. A mux-locked mux cannot be used by a driver for auto-closing
111- gates/muxes, i.e. something that closes automatically after a given
112- number (one, in most cases) of I2C transfers. Unrelated I2C transfers
113- may creep in and close prematurely.
114-
115- ML4. If any non-I2C operation in the mux driver changes the I2C mux state,
116- the driver has to lock the root adapter during that operation.
117- Otherwise garbage may appear on the bus as seen from devices
118- behind the mux, when an unrelated I2C transfer is in flight during
119- the non-I2C mux-changing operation.
120- ==== =====================================================================
121-
122-
12355Mux-locked Example
124- ------------------
125-
56+ ~~~~~~~~~~~~~~~~~~
12657
12758::
12859
@@ -153,6 +84,43 @@ This means that accesses to D2 are lockout out for the full duration
15384of the entire operation. But accesses to D3 are possibly interleaved
15485at any point.
15586
87+ Mux-locked caveats
88+ ~~~~~~~~~~~~~~~~~~
89+
90+ When using a mux-locked mux, be aware of the following restrictions:
91+
92+ [ML1]
93+ If you build a topology with a mux-locked mux being the parent
94+ of a parent-locked mux, this might break the expectation from the
95+ parent-locked mux that the root adapter is locked during the
96+ transaction.
97+
98+ [ML2]
99+ It is not safe to build arbitrary topologies with two (or more)
100+ mux-locked muxes that are not siblings, when there are address
101+ collisions between the devices on the child adapters of these
102+ non-sibling muxes.
103+
104+ I.e. the select-transfer-deselect transaction targeting e.g. device
105+ address 0x42 behind mux-one may be interleaved with a similar
106+ operation targeting device address 0x42 behind mux-two. The
107+ intent with such a topology would in this hypothetical example
108+ be that mux-one and mux-two should not be selected simultaneously,
109+ but mux-locked muxes do not guarantee that in all topologies.
110+
111+ [ML3]
112+ A mux-locked mux cannot be used by a driver for auto-closing
113+ gates/muxes, i.e. something that closes automatically after a given
114+ number (one, in most cases) of I2C transfers. Unrelated I2C transfers
115+ may creep in and close prematurely.
116+
117+ [ML4]
118+ If any non-I2C operation in the mux driver changes the I2C mux state,
119+ the driver has to lock the root adapter during that operation.
120+ Otherwise garbage may appear on the bus as seen from devices
121+ behind the mux, when an unrelated I2C transfer is in flight during
122+ the non-I2C mux-changing operation.
123+
156124
157125Parent-locked muxes
158126-------------------
@@ -161,28 +129,10 @@ Parent-locked muxes lock the parent adapter during the full select-
161129transfer-deselect transaction. The implication is that the mux driver
162130has to ensure that any and all I2C transfers through that parent
163131adapter during the transaction are unlocked I2C transfers (using e.g.
164- __i2c_transfer), or a deadlock will follow. There are a couple of
165- caveats.
166-
167- ==== ====================================================================
168- PL1. If you build a topology with a parent-locked mux being the child
169- of another mux, this might break a possible assumption from the
170- child mux that the root adapter is unused between its select op
171- and the actual transfer (e.g. if the child mux is auto-closing
172- and the parent mux issues I2C transfers as part of its select).
173- This is especially the case if the parent mux is mux-locked, but
174- it may also happen if the parent mux is parent-locked.
175-
176- PL2. If select/deselect calls out to other subsystems such as gpio,
177- pinctrl, regmap or iio, it is essential that any I2C transfers
178- caused by these subsystems are unlocked. This can be convoluted to
179- accomplish, maybe even impossible if an acceptably clean solution
180- is sought.
181- ==== ====================================================================
182-
132+ __i2c_transfer), or a deadlock will follow.
183133
184134Parent-locked Example
185- ---------------------
135+ ~~~~~~~~~~~~~~~~~~~~~
186136
187137::
188138
@@ -212,10 +162,30 @@ When there is an access to D1, this happens:
212162 9. M1 unlocks its parent adapter.
213163 10. M1 unlocks muxes on its parent.
214164
215-
216165This means that accesses to both D2 and D3 are locked out for the full
217166duration of the entire operation.
218167
168+ Parent-locked Caveats
169+ ~~~~~~~~~~~~~~~~~~~~~
170+
171+ When using a parent-locked mux, be aware of the following restrictions:
172+
173+ [PL1]
174+ If you build a topology with a parent-locked mux being the child
175+ of another mux, this might break a possible assumption from the
176+ child mux that the root adapter is unused between its select op
177+ and the actual transfer (e.g. if the child mux is auto-closing
178+ and the parent mux issues I2C transfers as part of its select).
179+ This is especially the case if the parent mux is mux-locked, but
180+ it may also happen if the parent mux is parent-locked.
181+
182+ [PL2]
183+ If select/deselect calls out to other subsystems such as gpio,
184+ pinctrl, regmap or iio, it is essential that any I2C transfers
185+ caused by these subsystems are unlocked. This can be convoluted to
186+ accomplish, maybe even impossible if an acceptably clean solution
187+ is sought.
188+
219189
220190Complex Examples
221191================
@@ -261,8 +231,10 @@ This is a good topology::
261231When device D1 is accessed, accesses to D2 are locked out for the
262232full duration of the operation (muxes on the top child adapter of M1
263233are locked). But accesses to D3 and D4 are possibly interleaved at
264- any point. Accesses to D3 locks out D1 and D2, but accesses to D4
265- are still possibly interleaved.
234+ any point.
235+
236+ Accesses to D3 locks out D1 and D2, but accesses to D4 are still possibly
237+ interleaved.
266238
267239
268240Mux-locked mux as parent of parent-locked mux
@@ -394,3 +366,47 @@ This is a good topology::
394366When D1 or D2 are accessed, accesses to D3 and D4 are locked out while
395367accesses to D5 may interleave. When D3 or D4 are accessed, accesses to
396368all other devices are locked out.
369+
370+
371+ Mux type of existing device drivers
372+ ===================================
373+
374+ Whether a device is mux-locked or parent-locked depends on its
375+ implementation. The following list was correct at the time of writing:
376+
377+ In drivers/i2c/muxes/:
378+
379+ ====================== =============================================
380+ i2c-arb-gpio-challenge Parent-locked
381+ i2c-mux-gpio Normally parent-locked, mux-locked iff
382+ all involved gpio pins are controlled by the
383+ same I2C root adapter that they mux.
384+ i2c-mux-gpmux Normally parent-locked, mux-locked iff
385+ specified in device-tree.
386+ i2c-mux-ltc4306 Mux-locked
387+ i2c-mux-mlxcpld Parent-locked
388+ i2c-mux-pca9541 Parent-locked
389+ i2c-mux-pca954x Parent-locked
390+ i2c-mux-pinctrl Normally parent-locked, mux-locked iff
391+ all involved pinctrl devices are controlled
392+ by the same I2C root adapter that they mux.
393+ i2c-mux-reg Parent-locked
394+ ====================== =============================================
395+
396+ In drivers/iio/:
397+
398+ ====================== =============================================
399+ gyro/mpu3050 Mux-locked
400+ imu/inv_mpu6050/ Mux-locked
401+ ====================== =============================================
402+
403+ In drivers/media/:
404+
405+ ======================= =============================================
406+ dvb-frontends/lgdt3306a Mux-locked
407+ dvb-frontends/m88ds3103 Parent-locked
408+ dvb-frontends/rtl2830 Parent-locked
409+ dvb-frontends/rtl2832 Mux-locked
410+ dvb-frontends/si2168 Mux-locked
411+ usb/cx231xx/ Parent-locked
412+ ======================= =============================================
0 commit comments