1 ================================
2 I2C muxes and complex topologies
3 ================================
4
5 There are a couple of reasons for building mor
6 than a straight-forward I2C bus with one adapt
7
8 Some example use cases are:
9
10 1. A mux may be needed on the bus to prevent a
11
12 2. The bus may be accessible from some externa
13 may be needed to determine if it is ok to a
14
15 3. A device (particularly RF tuners) may want
16 from the I2C bus, at least most of the time
17 that has to be operated before the device c
18
19 Several types of hardware components such as I
20 arbitrators allow to handle such needs.
21
22 These components are represented as I2C adapte
23 each adapter has a parent adapter (except the
24 more child adapters. The root adapter is the a
25 I2C transfers, and all adapters with a parent
26 object (quoted, since it can also be an arbitr
27
28 Depending of the particular mux driver, someth
29 an I2C transfer on one of its child adapters.
30 obviously operate a mux, but it can also do ar
31 bus master or open a gate. The mux driver has
32 select and deselect. select is called before t
33 optional) deselect is called after the transfe
34
35
36 Locking
37 =======
38
39 There are two variants of locking available to
40 mux-locked or parent-locked muxes.
41
42
43 Mux-locked muxes
44 ----------------
45
46 Mux-locked muxes does not lock the entire pare
47 full select-transfer-deselect transaction, onl
48 adapter are locked. Mux-locked muxes are mostl
49 select and/or deselect operations must use I2C
50 their tasks. Since the parent adapter is not f
51 full transaction, unrelated I2C transfers may
52 stages of the transaction. This has the benefi
53 may be easier and cleaner to implement, but it
54
55 Mux-locked Example
56 ~~~~~~~~~~~~~~~~~~
57
58 ::
59
60 .----------. .--------.
61 .--------. | mux- |-----| dev D1 |
62 | root |--+--| locked | '--------'
63 '--------' | | mux M1 |--. .--------.
64 | '----------' '--| dev D2 |
65 | .--------. '--------'
66 '--| dev D3 |
67 '--------'
68
69 When there is an access to D1, this happens:
70
71 1. Someone issues an I2C transfer to D1.
72 2. M1 locks muxes on its parent (the root ada
73 3. M1 calls ->select to ready the mux.
74 4. M1 (presumably) does some I2C transfers as
75 These transfers are normal I2C transfers t
76 adapter.
77 5. M1 feeds the I2C transfer from step 1 to i
78 normal I2C transfer that locks the parent
79 6. M1 calls ->deselect, if it has one.
80 7. Same rules as in step 4, but for ->deselec
81 8. M1 unlocks muxes on its parent.
82
83 This means that accesses to D2 are lockout out
84 of the entire operation. But accesses to D3 ar
85 at any point.
86
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
125 Parent-locked muxes
126 -------------------
127
128 Parent-locked muxes lock the parent adapter du
129 transfer-deselect transaction. The implication
130 has to ensure that any and all I2C transfers t
131 adapter during the transaction are unlocked I2
132 __i2c_transfer), or a deadlock will follow.
133
134 Parent-locked Example
135 ~~~~~~~~~~~~~~~~~~~~~
136
137 ::
138
139 .----------. .--------.
140 .--------. | parent- |-----| dev D1 |
141 | root |--+--| locked | '--------'
142 '--------' | | mux M1 |--. .--------.
143 | '----------' '--| dev D2 |
144 | .--------. '--------'
145 '--| dev D3 |
146 '--------'
147
148 When there is an access to D1, this happens:
149
150 1. Someone issues an I2C transfer to D1.
151 2. M1 locks muxes on its parent (the root ad
152 3. M1 locks its parent adapter.
153 4. M1 calls ->select to ready the mux.
154 5. If M1 does any I2C transfers (on this roo
155 its select, those transfers must be unloc
156 that they do not deadlock the root adapte
157 6. M1 feeds the I2C transfer from step 1 to
158 unlocked I2C transfer, so that it does no
159 adapter.
160 7. M1 calls ->deselect, if it has one.
161 8. Same rules as in step 5, but for ->desele
162 9. M1 unlocks its parent adapter.
163 10. M1 unlocks muxes on its parent.
164
165 This means that accesses to both D2 and D3 are
166 duration of the entire operation.
167
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
190 Complex Examples
191 ================
192
193 Parent-locked mux as parent of parent-locked m
194 ----------------------------------------------
195
196 This is a useful topology, but it can be bad::
197
198 .----------. .---------
199 .--------. | parent- |-----| parent-
200 | root |--+--| locked | | locked
201 '--------' | | mux M1 |--. | mux M2
202 | '----------' | '---------
203 | .--------. | .--------.
204 '--| dev D4 | '--| dev D3 |
205 '--------' '--------'
206
207 When any device is accessed, all other devices
208 the full duration of the operation (both muxes
209 and specifically when M2 requests its parent t
210 the buck to the root adapter).
211
212 This topology is bad if M2 is an auto-closing
213 issues any unlocked I2C transfers on the root
214 through and be seen by the M2 adapter, thus cl
215
216
217 Mux-locked mux as parent of mux-locked mux
218 ------------------------------------------
219
220 This is a good topology::
221
222 .----------. .---------
223 .--------. | mux- |-----| mux-
224 | root |--+--| locked | | locked
225 '--------' | | mux M1 |--. | mux M2
226 | '----------' | '---------
227 | .--------. | .--------.
228 '--| dev D4 | '--| dev D3 |
229 '--------' '--------'
230
231 When device D1 is accessed, accesses to D2 are
232 full duration of the operation (muxes on the t
233 are locked). But accesses to D3 and D4 are pos
234 any point.
235
236 Accesses to D3 locks out D1 and D2, but access
237 interleaved.
238
239
240 Mux-locked mux as parent of parent-locked mux
241 ---------------------------------------------
242
243 This is probably a bad topology::
244
245 .----------. .---------
246 .--------. | mux- |-----| parent-
247 | root |--+--| locked | | locked
248 '--------' | | mux M1 |--. | mux M2
249 | '----------' | '---------
250 | .--------. | .--------.
251 '--| dev D4 | '--| dev D3 |
252 '--------' '--------'
253
254 When device D1 is accessed, accesses to D2 and
255 for the full duration of the operation (M1 loc
256 root adapter). But accesses to D4 are possibly
257 point.
258
259 This kind of topology is generally not suitabl
260 be avoided. The reason is that M2 probably ass
261 be no I2C transfers during its calls to ->sele
262 if there are, any such transfers might appear
263 as partial I2C transfers, i.e. garbage or wors
264 device lockups and/or other problems.
265
266 The topology is especially troublesome if M2 i
267 mux. In that case, any interleaved accesses to
268 prematurely, as might any I2C transfers part o
269
270 But if M2 is not making the above stated assum
271 auto-closing, the topology is fine.
272
273
274 Parent-locked mux as parent of mux-locked mux
275 ---------------------------------------------
276
277 This is a good topology::
278
279 .----------. .---------
280 .--------. | parent- |-----| mux-
281 | root |--+--| locked | | locked
282 '--------' | | mux M1 |--. | mux M2
283 | '----------' | '---------
284 | .--------. | .--------.
285 '--| dev D4 | '--| dev D3 |
286 '--------' '--------'
287
288 When D1 is accessed, accesses to D2 are locked
289 duration of the operation (muxes on the top ch
290 are locked). Accesses to D3 and D4 are possibl
291 any point, just as is expected for mux-locked
292
293 When D3 or D4 are accessed, everything else is
294 accesses, M1 locks the root adapter. For D4 ac
295 adapter is locked directly.
296
297
298 Two mux-locked sibling muxes
299 ----------------------------
300
301 This is a good topology::
302
303 .--------.
304 .----------. .--| dev D1 |
305 | mux- |--' '--------'
306 .--| locked | .--------.
307 | | mux M1 |-----| dev D2 |
308 | '----------' '--------'
309 | .----------. .--------.
310 .--------. | | mux- |-----| dev D3 |
311 | root |--+--| locked | '--------'
312 '--------' | | mux M2 |--. .--------.
313 | '----------' '--| dev D4 |
314 | .--------. '--------'
315 '--| dev D5 |
316 '--------'
317
318 When D1 is accessed, accesses to D2, D3 and D4
319 accesses to D5 may be interleaved at any time.
320
321
322 Two parent-locked sibling muxes
323 -------------------------------
324
325 This is a good topology::
326
327 .--------.
328 .----------. .--| dev D1 |
329 | parent- |--' '--------'
330 .--| locked | .--------.
331 | | mux M1 |-----| dev D2 |
332 | '----------' '--------'
333 | .----------. .--------.
334 .--------. | | parent- |-----| dev D3 |
335 | root |--+--| locked | '--------'
336 '--------' | | mux M2 |--. .--------.
337 | '----------' '--| dev D4 |
338 | .--------. '--------'
339 '--| dev D5 |
340 '--------'
341
342 When any device is accessed, accesses to all o
343 out.
344
345
346 Mux-locked and parent-locked sibling muxes
347 ------------------------------------------
348
349 This is a good topology::
350
351 .--------.
352 .----------. .--| dev D1 |
353 | mux- |--' '--------'
354 .--| locked | .--------.
355 | | mux M1 |-----| dev D2 |
356 | '----------' '--------'
357 | .----------. .--------.
358 .--------. | | parent- |-----| dev D3 |
359 | root |--+--| locked | '--------'
360 '--------' | | mux M2 |--. .--------.
361 | '----------' '--| dev D4 |
362 | .--------. '--------'
363 '--| dev D5 |
364 '--------'
365
366 When D1 or D2 are accessed, accesses to D3 and
367 accesses to D5 may interleave. When D3 or D4 a
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-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.