@@ -5,6 +5,8 @@ I2C muxes and complex topologies
5
5
There are a couple of reasons for building more complex I2C topologies
6
6
than a straight-forward I2C bus with one adapter and one or more devices.
7
7
8
+ Some example use cases are:
9
+
8
10
1. A mux may be needed on the bus to prevent address collisions.
9
11
10
12
2. 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.
14
16
from the I2C bus, at least most of the time, and sits behind a gate
15
17
that has to be operated before the device can be accessed.
16
18
17
- Etc
18
- ===
19
+ Several types of hardware components such as I2C muxes, I2C gates and I2C
20
+ arbitrators allow to handle such needs.
19
21
20
- These constructs are represented as I2C adapter trees by Linux, where
22
+ These components are represented as I2C adapter trees by Linux, where
21
23
each adapter has a parent adapter (except the root adapter) and zero or
22
24
more child adapters. The root adapter is the actual adapter that issues
23
25
I2C transfers, and all adapters with a parent are part of an "i2c-mux"
@@ -35,46 +37,7 @@ Locking
35
37
=======
36
38
37
39
There 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.
78
41
79
42
80
43
Mux-locked muxes
@@ -89,40 +52,8 @@ full transaction, unrelated I2C transfers may interleave the different
89
52
stages of the transaction. This has the benefit that the mux driver
90
53
may be easier and cleaner to implement, but it has some caveats.
91
54
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
-
123
55
Mux-locked Example
124
- ------------------
125
-
56
+ ~~~~~~~~~~~~~~~~~~
126
57
127
58
::
128
59
@@ -153,6 +84,43 @@ This means that accesses to D2 are lockout out for the full duration
153
84
of the entire operation. But accesses to D3 are possibly interleaved
154
85
at any point.
155
86
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
+
156
124
157
125
Parent-locked muxes
158
126
-------------------
@@ -161,28 +129,10 @@ Parent-locked muxes lock the parent adapter during the full select-
161
129
transfer-deselect transaction. The implication is that the mux driver
162
130
has to ensure that any and all I2C transfers through that parent
163
131
adapter 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.
183
133
184
134
Parent-locked Example
185
- ---------------------
135
+ ~~~~~~~~~~~~~~~~~~~~~
186
136
187
137
::
188
138
@@ -212,10 +162,30 @@ When there is an access to D1, this happens:
212
162
9. M1 unlocks its parent adapter.
213
163
10. M1 unlocks muxes on its parent.
214
164
215
-
216
165
This means that accesses to both D2 and D3 are locked out for the full
217
166
duration of the entire operation.
218
167
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
+
219
189
220
190
Complex Examples
221
191
================
@@ -261,8 +231,10 @@ This is a good topology::
261
231
When device D1 is accessed, accesses to D2 are locked out for the
262
232
full duration of the operation (muxes on the top child adapter of M1
263
233
are 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.
266
238
267
239
268
240
Mux-locked mux as parent of parent-locked mux
@@ -394,3 +366,47 @@ This is a good topology::
394
366
When D1 or D2 are accessed, accesses to D3 and D4 are locked out while
395
367
accesses to D5 may interleave. When D3 or D4 are accessed, accesses to
396
368
all 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