1 ================================ 1 ================================
2 I2C muxes and complex topologies 2 I2C muxes and complex topologies
3 ================================ 3 ================================
4 4
5 There are a couple of reasons for building mor 5 There are a couple of reasons for building more complex I2C topologies
6 than a straight-forward I2C bus with one adapt 6 than a straight-forward I2C bus with one adapter and one or more devices.
7 7
8 Some example use cases are: <<
9 <<
10 1. A mux may be needed on the bus to prevent a 8 1. A mux may be needed on the bus to prevent address collisions.
11 9
12 2. The bus may be accessible from some externa 10 2. The bus may be accessible from some external bus master, and arbitration
13 may be needed to determine if it is ok to a 11 may be needed to determine if it is ok to access the bus.
14 12
15 3. A device (particularly RF tuners) may want 13 3. A device (particularly RF tuners) may want to avoid the digital noise
16 from the I2C bus, at least most of the time 14 from the I2C bus, at least most of the time, and sits behind a gate
17 that has to be operated before the device c 15 that has to be operated before the device can be accessed.
18 16
19 Several types of hardware components such as I !! 17 Etc
20 arbitrators allow to handle such needs. !! 18 ===
21 19
22 These components are represented as I2C adapte !! 20 These constructs are represented as I2C adapter trees by Linux, where
23 each adapter has a parent adapter (except the 21 each adapter has a parent adapter (except the root adapter) and zero or
24 more child adapters. The root adapter is the a 22 more child adapters. The root adapter is the actual adapter that issues
25 I2C transfers, and all adapters with a parent 23 I2C transfers, and all adapters with a parent are part of an "i2c-mux"
26 object (quoted, since it can also be an arbitr 24 object (quoted, since it can also be an arbitrator or a gate).
27 25
28 Depending of the particular mux driver, someth 26 Depending of the particular mux driver, something happens when there is
29 an I2C transfer on one of its child adapters. 27 an I2C transfer on one of its child adapters. The mux driver can
30 obviously operate a mux, but it can also do ar 28 obviously operate a mux, but it can also do arbitration with an external
31 bus master or open a gate. The mux driver has 29 bus master or open a gate. The mux driver has two operations for this,
32 select and deselect. select is called before t 30 select and deselect. select is called before the transfer and (the
33 optional) deselect is called after the transfe 31 optional) deselect is called after the transfer.
34 32
35 33
36 Locking 34 Locking
37 ======= 35 =======
38 36
39 There are two variants of locking available to 37 There are two variants of locking available to I2C muxes, they can be
40 mux-locked or parent-locked muxes. !! 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 ======================= =============================================
41 78
42 79
43 Mux-locked muxes 80 Mux-locked muxes
44 ---------------- 81 ----------------
45 82
46 Mux-locked muxes does not lock the entire pare 83 Mux-locked muxes does not lock the entire parent adapter during the
47 full select-transfer-deselect transaction, onl 84 full select-transfer-deselect transaction, only the muxes on the parent
48 adapter are locked. Mux-locked muxes are mostl 85 adapter are locked. Mux-locked muxes are mostly interesting if the
49 select and/or deselect operations must use I2C 86 select and/or deselect operations must use I2C transfers to complete
50 their tasks. Since the parent adapter is not f 87 their tasks. Since the parent adapter is not fully locked during the
51 full transaction, unrelated I2C transfers may 88 full transaction, unrelated I2C transfers may interleave the different
52 stages of the transaction. This has the benefi 89 stages of the transaction. This has the benefit that the mux driver
53 may be easier and cleaner to implement, but it 90 may be easier and cleaner to implement, but it has some caveats.
54 91
>> 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
55 Mux-locked Example 123 Mux-locked Example
56 ~~~~~~~~~~~~~~~~~~ !! 124 ------------------
>> 125
57 126
58 :: 127 ::
59 128
60 .----------. .--------. 129 .----------. .--------.
61 .--------. | mux- |-----| dev D1 | 130 .--------. | mux- |-----| dev D1 |
62 | root |--+--| locked | '--------' 131 | root |--+--| locked | '--------'
63 '--------' | | mux M1 |--. .--------. 132 '--------' | | mux M1 |--. .--------.
64 | '----------' '--| dev D2 | 133 | '----------' '--| dev D2 |
65 | .--------. '--------' 134 | .--------. '--------'
66 '--| dev D3 | 135 '--| dev D3 |
67 '--------' 136 '--------'
68 137
69 When there is an access to D1, this happens: 138 When there is an access to D1, this happens:
70 139
71 1. Someone issues an I2C transfer to D1. 140 1. Someone issues an I2C transfer to D1.
72 2. M1 locks muxes on its parent (the root ada 141 2. M1 locks muxes on its parent (the root adapter in this case).
73 3. M1 calls ->select to ready the mux. 142 3. M1 calls ->select to ready the mux.
74 4. M1 (presumably) does some I2C transfers as 143 4. M1 (presumably) does some I2C transfers as part of its select.
75 These transfers are normal I2C transfers t 144 These transfers are normal I2C transfers that locks the parent
76 adapter. 145 adapter.
77 5. M1 feeds the I2C transfer from step 1 to i 146 5. M1 feeds the I2C transfer from step 1 to its parent adapter as a
78 normal I2C transfer that locks the parent 147 normal I2C transfer that locks the parent adapter.
79 6. M1 calls ->deselect, if it has one. 148 6. M1 calls ->deselect, if it has one.
80 7. Same rules as in step 4, but for ->deselec 149 7. Same rules as in step 4, but for ->deselect.
81 8. M1 unlocks muxes on its parent. 150 8. M1 unlocks muxes on its parent.
82 151
83 This means that accesses to D2 are lockout out 152 This means that accesses to D2 are lockout out for the full duration
84 of the entire operation. But accesses to D3 ar 153 of the entire operation. But accesses to D3 are possibly interleaved
85 at any point. 154 at any point.
86 155
87 Mux-locked caveats <<
88 ~~~~~~~~~~~~~~~~~~ <<
89 <<
90 When using a mux-locked mux, be aware of the f <<
91 <<
92 [ML1] <<
93 If you build a topology with a mux-locked mu <<
94 of a parent-locked mux, this might break the <<
95 parent-locked mux that the root adapter is l <<
96 transaction. <<
97 <<
98 [ML2] <<
99 It is not safe to build arbitrary topologies <<
100 mux-locked muxes that are not siblings, when <<
101 collisions between the devices on the child <<
102 non-sibling muxes. <<
103 <<
104 I.e. the select-transfer-deselect transactio <<
105 address 0x42 behind mux-one may be interleav <<
106 operation targeting device address 0x42 behi <<
107 intent with such a topology would in this hy <<
108 be that mux-one and mux-two should not be se <<
109 but mux-locked muxes do not guarantee that i <<
110 <<
111 [ML3] <<
112 A mux-locked mux cannot be used by a driver <<
113 gates/muxes, i.e. something that closes auto <<
114 number (one, in most cases) of I2C transfers <<
115 may creep in and close prematurely. <<
116 <<
117 [ML4] <<
118 If any non-I2C operation in the mux driver c <<
119 the driver has to lock the root adapter duri <<
120 Otherwise garbage may appear on the bus as s <<
121 behind the mux, when an unrelated I2C transf <<
122 the non-I2C mux-changing operation. <<
123 <<
124 156
125 Parent-locked muxes 157 Parent-locked muxes
126 ------------------- 158 -------------------
127 159
128 Parent-locked muxes lock the parent adapter du 160 Parent-locked muxes lock the parent adapter during the full select-
129 transfer-deselect transaction. The implication 161 transfer-deselect transaction. The implication is that the mux driver
130 has to ensure that any and all I2C transfers t 162 has to ensure that any and all I2C transfers through that parent
131 adapter during the transaction are unlocked I2 163 adapter during the transaction are unlocked I2C transfers (using e.g.
132 __i2c_transfer), or a deadlock will follow. !! 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
133 183
134 Parent-locked Example 184 Parent-locked Example
135 ~~~~~~~~~~~~~~~~~~~~~ !! 185 ---------------------
136 186
137 :: 187 ::
138 188
139 .----------. .--------. 189 .----------. .--------.
140 .--------. | parent- |-----| dev D1 | 190 .--------. | parent- |-----| dev D1 |
141 | root |--+--| locked | '--------' 191 | root |--+--| locked | '--------'
142 '--------' | | mux M1 |--. .--------. 192 '--------' | | mux M1 |--. .--------.
143 | '----------' '--| dev D2 | 193 | '----------' '--| dev D2 |
144 | .--------. '--------' 194 | .--------. '--------'
145 '--| dev D3 | 195 '--| dev D3 |
146 '--------' 196 '--------'
147 197
148 When there is an access to D1, this happens: 198 When there is an access to D1, this happens:
149 199
150 1. Someone issues an I2C transfer to D1. 200 1. Someone issues an I2C transfer to D1.
151 2. M1 locks muxes on its parent (the root ad 201 2. M1 locks muxes on its parent (the root adapter in this case).
152 3. M1 locks its parent adapter. 202 3. M1 locks its parent adapter.
153 4. M1 calls ->select to ready the mux. 203 4. M1 calls ->select to ready the mux.
154 5. If M1 does any I2C transfers (on this roo 204 5. If M1 does any I2C transfers (on this root adapter) as part of
155 its select, those transfers must be unloc 205 its select, those transfers must be unlocked I2C transfers so
156 that they do not deadlock the root adapte 206 that they do not deadlock the root adapter.
157 6. M1 feeds the I2C transfer from step 1 to 207 6. M1 feeds the I2C transfer from step 1 to the root adapter as an
158 unlocked I2C transfer, so that it does no 208 unlocked I2C transfer, so that it does not deadlock the parent
159 adapter. 209 adapter.
160 7. M1 calls ->deselect, if it has one. 210 7. M1 calls ->deselect, if it has one.
161 8. Same rules as in step 5, but for ->desele 211 8. Same rules as in step 5, but for ->deselect.
162 9. M1 unlocks its parent adapter. 212 9. M1 unlocks its parent adapter.
163 10. M1 unlocks muxes on its parent. 213 10. M1 unlocks muxes on its parent.
164 214
>> 215
165 This means that accesses to both D2 and D3 are 216 This means that accesses to both D2 and D3 are locked out for the full
166 duration of the entire operation. 217 duration of the entire operation.
167 218
168 Parent-locked Caveats <<
169 ~~~~~~~~~~~~~~~~~~~~~ <<
170 <<
171 When using a parent-locked mux, be aware of th <<
172 <<
173 [PL1] <<
174 If you build a topology with a parent-locked <<
175 of another mux, this might break a possible <<
176 child mux that the root adapter is unused be <<
177 and the actual transfer (e.g. if the child m <<
178 and the parent mux issues I2C transfers as p <<
179 This is especially the case if the parent mu <<
180 it may also happen if the parent mux is pare <<
181 <<
182 [PL2] <<
183 If select/deselect calls out to other subsys <<
184 pinctrl, regmap or iio, it is essential that <<
185 caused by these subsystems are unlocked. Thi <<
186 accomplish, maybe even impossible if an acce <<
187 is sought. <<
188 <<
189 219
190 Complex Examples 220 Complex Examples
191 ================ 221 ================
192 222
193 Parent-locked mux as parent of parent-locked m 223 Parent-locked mux as parent of parent-locked mux
194 ---------------------------------------------- 224 ------------------------------------------------
195 225
196 This is a useful topology, but it can be bad:: 226 This is a useful topology, but it can be bad::
197 227
198 .----------. .--------- 228 .----------. .----------. .--------.
199 .--------. | parent- |-----| parent- 229 .--------. | parent- |-----| parent- |-----| dev D1 |
200 | root |--+--| locked | | locked 230 | root |--+--| locked | | locked | '--------'
201 '--------' | | mux M1 |--. | mux M2 231 '--------' | | mux M1 |--. | mux M2 |--. .--------.
202 | '----------' | '--------- 232 | '----------' | '----------' '--| dev D2 |
203 | .--------. | .--------. 233 | .--------. | .--------. '--------'
204 '--| dev D4 | '--| dev D3 | 234 '--| dev D4 | '--| dev D3 |
205 '--------' '--------' 235 '--------' '--------'
206 236
207 When any device is accessed, all other devices 237 When any device is accessed, all other devices are locked out for
208 the full duration of the operation (both muxes 238 the full duration of the operation (both muxes lock their parent,
209 and specifically when M2 requests its parent t 239 and specifically when M2 requests its parent to lock, M1 passes
210 the buck to the root adapter). 240 the buck to the root adapter).
211 241
212 This topology is bad if M2 is an auto-closing 242 This topology is bad if M2 is an auto-closing mux and M1->select
213 issues any unlocked I2C transfers on the root 243 issues any unlocked I2C transfers on the root adapter that may leak
214 through and be seen by the M2 adapter, thus cl 244 through and be seen by the M2 adapter, thus closing M2 prematurely.
215 245
216 246
217 Mux-locked mux as parent of mux-locked mux 247 Mux-locked mux as parent of mux-locked mux
218 ------------------------------------------ 248 ------------------------------------------
219 249
220 This is a good topology:: 250 This is a good topology::
221 251
222 .----------. .--------- 252 .----------. .----------. .--------.
223 .--------. | mux- |-----| mux- 253 .--------. | mux- |-----| mux- |-----| dev D1 |
224 | root |--+--| locked | | locked 254 | root |--+--| locked | | locked | '--------'
225 '--------' | | mux M1 |--. | mux M2 255 '--------' | | mux M1 |--. | mux M2 |--. .--------.
226 | '----------' | '--------- 256 | '----------' | '----------' '--| dev D2 |
227 | .--------. | .--------. 257 | .--------. | .--------. '--------'
228 '--| dev D4 | '--| dev D3 | 258 '--| dev D4 | '--| dev D3 |
229 '--------' '--------' 259 '--------' '--------'
230 260
231 When device D1 is accessed, accesses to D2 are 261 When device D1 is accessed, accesses to D2 are locked out for the
232 full duration of the operation (muxes on the t 262 full duration of the operation (muxes on the top child adapter of M1
233 are locked). But accesses to D3 and D4 are pos 263 are locked). But accesses to D3 and D4 are possibly interleaved at
234 any point. !! 264 any point. Accesses to D3 locks out D1 and D2, but accesses to D4
235 !! 265 are still possibly interleaved.
236 Accesses to D3 locks out D1 and D2, but access <<
237 interleaved. <<
238 266
239 267
240 Mux-locked mux as parent of parent-locked mux 268 Mux-locked mux as parent of parent-locked mux
241 --------------------------------------------- 269 ---------------------------------------------
242 270
243 This is probably a bad topology:: 271 This is probably a bad topology::
244 272
245 .----------. .--------- 273 .----------. .----------. .--------.
246 .--------. | mux- |-----| parent- 274 .--------. | mux- |-----| parent- |-----| dev D1 |
247 | root |--+--| locked | | locked 275 | root |--+--| locked | | locked | '--------'
248 '--------' | | mux M1 |--. | mux M2 276 '--------' | | mux M1 |--. | mux M2 |--. .--------.
249 | '----------' | '--------- 277 | '----------' | '----------' '--| dev D2 |
250 | .--------. | .--------. 278 | .--------. | .--------. '--------'
251 '--| dev D4 | '--| dev D3 | 279 '--| dev D4 | '--| dev D3 |
252 '--------' '--------' 280 '--------' '--------'
253 281
254 When device D1 is accessed, accesses to D2 and 282 When device D1 is accessed, accesses to D2 and D3 are locked out
255 for the full duration of the operation (M1 loc 283 for the full duration of the operation (M1 locks child muxes on the
256 root adapter). But accesses to D4 are possibly 284 root adapter). But accesses to D4 are possibly interleaved at any
257 point. 285 point.
258 286
259 This kind of topology is generally not suitabl 287 This kind of topology is generally not suitable and should probably
260 be avoided. The reason is that M2 probably ass 288 be avoided. The reason is that M2 probably assumes that there will
261 be no I2C transfers during its calls to ->sele 289 be no I2C transfers during its calls to ->select and ->deselect, and
262 if there are, any such transfers might appear 290 if there are, any such transfers might appear on the slave side of M2
263 as partial I2C transfers, i.e. garbage or wors 291 as partial I2C transfers, i.e. garbage or worse. This might cause
264 device lockups and/or other problems. 292 device lockups and/or other problems.
265 293
266 The topology is especially troublesome if M2 i 294 The topology is especially troublesome if M2 is an auto-closing
267 mux. In that case, any interleaved accesses to 295 mux. In that case, any interleaved accesses to D4 might close M2
268 prematurely, as might any I2C transfers part o 296 prematurely, as might any I2C transfers part of M1->select.
269 297
270 But if M2 is not making the above stated assum 298 But if M2 is not making the above stated assumption, and if M2 is not
271 auto-closing, the topology is fine. 299 auto-closing, the topology is fine.
272 300
273 301
274 Parent-locked mux as parent of mux-locked mux 302 Parent-locked mux as parent of mux-locked mux
275 --------------------------------------------- 303 ---------------------------------------------
276 304
277 This is a good topology:: 305 This is a good topology::
278 306
279 .----------. .--------- 307 .----------. .----------. .--------.
280 .--------. | parent- |-----| mux- 308 .--------. | parent- |-----| mux- |-----| dev D1 |
281 | root |--+--| locked | | locked 309 | root |--+--| locked | | locked | '--------'
282 '--------' | | mux M1 |--. | mux M2 310 '--------' | | mux M1 |--. | mux M2 |--. .--------.
283 | '----------' | '--------- 311 | '----------' | '----------' '--| dev D2 |
284 | .--------. | .--------. 312 | .--------. | .--------. '--------'
285 '--| dev D4 | '--| dev D3 | 313 '--| dev D4 | '--| dev D3 |
286 '--------' '--------' 314 '--------' '--------'
287 315
288 When D1 is accessed, accesses to D2 are locked 316 When D1 is accessed, accesses to D2 are locked out for the full
289 duration of the operation (muxes on the top ch 317 duration of the operation (muxes on the top child adapter of M1
290 are locked). Accesses to D3 and D4 are possibl 318 are locked). Accesses to D3 and D4 are possibly interleaved at
291 any point, just as is expected for mux-locked 319 any point, just as is expected for mux-locked muxes.
292 320
293 When D3 or D4 are accessed, everything else is 321 When D3 or D4 are accessed, everything else is locked out. For D3
294 accesses, M1 locks the root adapter. For D4 ac 322 accesses, M1 locks the root adapter. For D4 accesses, the root
295 adapter is locked directly. 323 adapter is locked directly.
296 324
297 325
298 Two mux-locked sibling muxes 326 Two mux-locked sibling muxes
299 ---------------------------- 327 ----------------------------
300 328
301 This is a good topology:: 329 This is a good topology::
302 330
303 .--------. 331 .--------.
304 .----------. .--| dev D1 | 332 .----------. .--| dev D1 |
305 | mux- |--' '--------' 333 | mux- |--' '--------'
306 .--| locked | .--------. 334 .--| locked | .--------.
307 | | mux M1 |-----| dev D2 | 335 | | mux M1 |-----| dev D2 |
308 | '----------' '--------' 336 | '----------' '--------'
309 | .----------. .--------. 337 | .----------. .--------.
310 .--------. | | mux- |-----| dev D3 | 338 .--------. | | mux- |-----| dev D3 |
311 | root |--+--| locked | '--------' 339 | root |--+--| locked | '--------'
312 '--------' | | mux M2 |--. .--------. 340 '--------' | | mux M2 |--. .--------.
313 | '----------' '--| dev D4 | 341 | '----------' '--| dev D4 |
314 | .--------. '--------' 342 | .--------. '--------'
315 '--| dev D5 | 343 '--| dev D5 |
316 '--------' 344 '--------'
317 345
318 When D1 is accessed, accesses to D2, D3 and D4 346 When D1 is accessed, accesses to D2, D3 and D4 are locked out. But
319 accesses to D5 may be interleaved at any time. 347 accesses to D5 may be interleaved at any time.
320 348
321 349
322 Two parent-locked sibling muxes 350 Two parent-locked sibling muxes
323 ------------------------------- 351 -------------------------------
324 352
325 This is a good topology:: 353 This is a good topology::
326 354
327 .--------. 355 .--------.
328 .----------. .--| dev D1 | 356 .----------. .--| dev D1 |
329 | parent- |--' '--------' 357 | parent- |--' '--------'
330 .--| locked | .--------. 358 .--| locked | .--------.
331 | | mux M1 |-----| dev D2 | 359 | | mux M1 |-----| dev D2 |
332 | '----------' '--------' 360 | '----------' '--------'
333 | .----------. .--------. 361 | .----------. .--------.
334 .--------. | | parent- |-----| dev D3 | 362 .--------. | | parent- |-----| dev D3 |
335 | root |--+--| locked | '--------' 363 | root |--+--| locked | '--------'
336 '--------' | | mux M2 |--. .--------. 364 '--------' | | mux M2 |--. .--------.
337 | '----------' '--| dev D4 | 365 | '----------' '--| dev D4 |
338 | .--------. '--------' 366 | .--------. '--------'
339 '--| dev D5 | 367 '--| dev D5 |
340 '--------' 368 '--------'
341 369
342 When any device is accessed, accesses to all o 370 When any device is accessed, accesses to all other devices are locked
343 out. 371 out.
344 372
345 373
346 Mux-locked and parent-locked sibling muxes 374 Mux-locked and parent-locked sibling muxes
347 ------------------------------------------ 375 ------------------------------------------
348 376
349 This is a good topology:: 377 This is a good topology::
350 378
351 .--------. 379 .--------.
352 .----------. .--| dev D1 | 380 .----------. .--| dev D1 |
353 | mux- |--' '--------' 381 | mux- |--' '--------'
354 .--| locked | .--------. 382 .--| locked | .--------.
355 | | mux M1 |-----| dev D2 | 383 | | mux M1 |-----| dev D2 |
356 | '----------' '--------' 384 | '----------' '--------'
357 | .----------. .--------. 385 | .----------. .--------.
358 .--------. | | parent- |-----| dev D3 | 386 .--------. | | parent- |-----| dev D3 |
359 | root |--+--| locked | '--------' 387 | root |--+--| locked | '--------'
360 '--------' | | mux M2 |--. .--------. 388 '--------' | | mux M2 |--. .--------.
361 | '----------' '--| dev D4 | 389 | '----------' '--| dev D4 |
362 | .--------. '--------' 390 | .--------. '--------'
363 '--| dev D5 | 391 '--| dev D5 |
364 '--------' 392 '--------'
365 393
366 When D1 or D2 are accessed, accesses to D3 and 394 When D1 or D2 are accessed, accesses to D3 and D4 are locked out while
367 accesses to D5 may interleave. When D3 or D4 a 395 accesses to D5 may interleave. When D3 or D4 are accessed, accesses to
368 all other devices are locked out. 396 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-locke <<
375 implementation. The following list was correct <<
376 <<
377 In drivers/i2c/muxes/: <<
378 <<
379 ====================== ==================== <<
380 i2c-arb-gpio-challenge Parent-locked <<
381 i2c-mux-gpio Normally parent-lock <<
382 all involved gpio pi <<
383 same I2C root adapte <<
384 i2c-mux-gpmux Normally parent-lock <<
385 specified in device- <<
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-lock <<
391 all involved pinctrl <<
392 by the same I2C root <<
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 ======================= ==================== <<
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.