Luca Ceresoli | f6fcefa | 2020-01-29 16:19:51 +0100 | [diff] [blame] | 1 | ================================ |
| 2 | I2C muxes and complex topologies |
| 3 | ================================ |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 4 | |
Luca Ceresoli | 2f07c05 | 2020-01-29 16:19:29 +0100 | [diff] [blame] | 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. |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 7 | |
Luca Ceresoli | 12c035a | 2022-08-24 10:31:03 +0200 | [diff] [blame] | 8 | Some example use cases are: |
| 9 | |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 10 | 1. A mux may be needed on the bus to prevent address collisions. |
| 11 | |
| 12 | 2. The bus may be accessible from some external bus master, and arbitration |
| 13 | may be needed to determine if it is ok to access the bus. |
| 14 | |
| 15 | 3. A device (particularly RF tuners) may want to avoid the digital noise |
Luca Ceresoli | 2f07c05 | 2020-01-29 16:19:29 +0100 | [diff] [blame] | 16 | from the I2C bus, at least most of the time, and sits behind a gate |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 17 | that has to be operated before the device can be accessed. |
| 18 | |
Luca Ceresoli | 92d5d64 | 2022-08-24 10:31:04 +0200 | [diff] [blame] | 19 | Several types of hardware components such as I2C muxes, I2C gates and I2C |
| 20 | arbitrators allow to handle such needs. |
| 21 | |
| 22 | These components are represented as I2C adapter trees by Linux, where |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 23 | each adapter has a parent adapter (except the root adapter) and zero or |
| 24 | more child adapters. The root adapter is the actual adapter that issues |
Luca Ceresoli | 2f07c05 | 2020-01-29 16:19:29 +0100 | [diff] [blame] | 25 | I2C transfers, and all adapters with a parent are part of an "i2c-mux" |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 26 | object (quoted, since it can also be an arbitrator or a gate). |
| 27 | |
| 28 | Depending of the particular mux driver, something happens when there is |
Luca Ceresoli | 2f07c05 | 2020-01-29 16:19:29 +0100 | [diff] [blame] | 29 | an I2C transfer on one of its child adapters. The mux driver can |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 30 | obviously operate a mux, but it can also do arbitration with an external |
| 31 | bus master or open a gate. The mux driver has two operations for this, |
| 32 | select and deselect. select is called before the transfer and (the |
| 33 | optional) deselect is called after the transfer. |
| 34 | |
| 35 | |
| 36 | Locking |
| 37 | ======= |
| 38 | |
Luca Ceresoli | 2f07c05 | 2020-01-29 16:19:29 +0100 | [diff] [blame] | 39 | There are two variants of locking available to I2C muxes, they can be |
Luca Ceresoli | 92d5d64 | 2022-08-24 10:31:04 +0200 | [diff] [blame] | 40 | mux-locked or parent-locked muxes. |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 41 | |
| 42 | |
| 43 | Mux-locked muxes |
| 44 | ---------------- |
| 45 | |
| 46 | Mux-locked muxes does not lock the entire parent adapter during the |
| 47 | full select-transfer-deselect transaction, only the muxes on the parent |
| 48 | adapter are locked. Mux-locked muxes are mostly interesting if the |
Luca Ceresoli | 2f07c05 | 2020-01-29 16:19:29 +0100 | [diff] [blame] | 49 | select and/or deselect operations must use I2C transfers to complete |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 50 | their tasks. Since the parent adapter is not fully locked during the |
Luca Ceresoli | 2f07c05 | 2020-01-29 16:19:29 +0100 | [diff] [blame] | 51 | full transaction, unrelated I2C transfers may interleave the different |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 52 | stages of the transaction. This has the benefit that the mux driver |
| 53 | may be easier and cleaner to implement, but it has some caveats. |
| 54 | |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 55 | Mux-locked Example |
Luca Ceresoli | 92d5d64 | 2022-08-24 10:31:04 +0200 | [diff] [blame] | 56 | ~~~~~~~~~~~~~~~~~~ |
Mauro Carvalho Chehab | ccf988b | 2019-07-26 09:51:16 -0300 | [diff] [blame] | 57 | |
| 58 | :: |
| 59 | |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 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 | |
Luca Ceresoli | 48ca3b7 | 2020-01-29 16:19:31 +0100 | [diff] [blame] | 71 | 1. Someone issues an I2C transfer to D1. |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 72 | 2. M1 locks muxes on its parent (the root adapter in this case). |
| 73 | 3. M1 calls ->select to ready the mux. |
Luca Ceresoli | 48ca3b7 | 2020-01-29 16:19:31 +0100 | [diff] [blame] | 74 | 4. M1 (presumably) does some I2C transfers as part of its select. |
| 75 | These transfers are normal I2C transfers that locks the parent |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 76 | adapter. |
Luca Ceresoli | 48ca3b7 | 2020-01-29 16:19:31 +0100 | [diff] [blame] | 77 | 5. M1 feeds the I2C transfer from step 1 to its parent adapter as a |
| 78 | normal I2C transfer that locks the parent adapter. |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 79 | 6. M1 calls ->deselect, if it has one. |
| 80 | 7. Same rules as in step 4, but for ->deselect. |
| 81 | 8. M1 unlocks muxes on its parent. |
| 82 | |
| 83 | This means that accesses to D2 are lockout out for the full duration |
| 84 | of the entire operation. But accesses to D3 are possibly interleaved |
| 85 | at any point. |
| 86 | |
Luca Ceresoli | 92d5d64 | 2022-08-24 10:31:04 +0200 | [diff] [blame] | 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 | |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 124 | |
| 125 | Parent-locked muxes |
| 126 | ------------------- |
| 127 | |
| 128 | Parent-locked muxes lock the parent adapter during the full select- |
| 129 | transfer-deselect transaction. The implication is that the mux driver |
Luca Ceresoli | 2f07c05 | 2020-01-29 16:19:29 +0100 | [diff] [blame] | 130 | has to ensure that any and all I2C transfers through that parent |
| 131 | adapter during the transaction are unlocked I2C transfers (using e.g. |
Luca Ceresoli | 92d5d64 | 2022-08-24 10:31:04 +0200 | [diff] [blame] | 132 | __i2c_transfer), or a deadlock will follow. |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 133 | |
| 134 | Parent-locked Example |
Luca Ceresoli | 92d5d64 | 2022-08-24 10:31:04 +0200 | [diff] [blame] | 135 | ~~~~~~~~~~~~~~~~~~~~~ |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 136 | |
Mauro Carvalho Chehab | ccf988b | 2019-07-26 09:51:16 -0300 | [diff] [blame] | 137 | :: |
| 138 | |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 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 | |
Luca Ceresoli | 48ca3b7 | 2020-01-29 16:19:31 +0100 | [diff] [blame] | 150 | 1. Someone issues an I2C transfer to D1. |
Mauro Carvalho Chehab | ccf988b | 2019-07-26 09:51:16 -0300 | [diff] [blame] | 151 | 2. M1 locks muxes on its parent (the root adapter in this case). |
| 152 | 3. M1 locks its parent adapter. |
| 153 | 4. M1 calls ->select to ready the mux. |
Luca Ceresoli | 48ca3b7 | 2020-01-29 16:19:31 +0100 | [diff] [blame] | 154 | 5. If M1 does any I2C transfers (on this root adapter) as part of |
| 155 | its select, those transfers must be unlocked I2C transfers so |
Mauro Carvalho Chehab | ccf988b | 2019-07-26 09:51:16 -0300 | [diff] [blame] | 156 | that they do not deadlock the root adapter. |
Luca Ceresoli | 48ca3b7 | 2020-01-29 16:19:31 +0100 | [diff] [blame] | 157 | 6. M1 feeds the I2C transfer from step 1 to the root adapter as an |
| 158 | unlocked I2C transfer, so that it does not deadlock the parent |
Mauro Carvalho Chehab | ccf988b | 2019-07-26 09:51:16 -0300 | [diff] [blame] | 159 | adapter. |
| 160 | 7. M1 calls ->deselect, if it has one. |
| 161 | 8. Same rules as in step 5, but for ->deselect. |
| 162 | 9. M1 unlocks its parent adapter. |
| 163 | 10. M1 unlocks muxes on its parent. |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 164 | |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 165 | This means that accesses to both D2 and D3 are locked out for the full |
| 166 | duration of the entire operation. |
| 167 | |
Luca Ceresoli | 92d5d64 | 2022-08-24 10:31:04 +0200 | [diff] [blame] | 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 | |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 189 | |
| 190 | Complex Examples |
| 191 | ================ |
| 192 | |
| 193 | Parent-locked mux as parent of parent-locked mux |
| 194 | ------------------------------------------------ |
| 195 | |
Mauro Carvalho Chehab | ccf988b | 2019-07-26 09:51:16 -0300 | [diff] [blame] | 196 | This is a useful topology, but it can be bad:: |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 197 | |
| 198 | .----------. .----------. .--------. |
| 199 | .--------. | parent- |-----| parent- |-----| dev D1 | |
| 200 | | root |--+--| locked | | locked | '--------' |
| 201 | '--------' | | mux M1 |--. | mux M2 |--. .--------. |
| 202 | | '----------' | '----------' '--| dev D2 | |
| 203 | | .--------. | .--------. '--------' |
| 204 | '--| dev D4 | '--| dev D3 | |
| 205 | '--------' '--------' |
| 206 | |
| 207 | When any device is accessed, all other devices are locked out for |
| 208 | the full duration of the operation (both muxes lock their parent, |
| 209 | and specifically when M2 requests its parent to lock, M1 passes |
| 210 | the buck to the root adapter). |
| 211 | |
| 212 | This topology is bad if M2 is an auto-closing mux and M1->select |
Luca Ceresoli | 2f07c05 | 2020-01-29 16:19:29 +0100 | [diff] [blame] | 213 | issues any unlocked I2C transfers on the root adapter that may leak |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 214 | through and be seen by the M2 adapter, thus closing M2 prematurely. |
| 215 | |
| 216 | |
| 217 | Mux-locked mux as parent of mux-locked mux |
| 218 | ------------------------------------------ |
| 219 | |
Mauro Carvalho Chehab | ccf988b | 2019-07-26 09:51:16 -0300 | [diff] [blame] | 220 | This is a good topology:: |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 221 | |
| 222 | .----------. .----------. .--------. |
| 223 | .--------. | mux- |-----| mux- |-----| dev D1 | |
| 224 | | root |--+--| locked | | locked | '--------' |
| 225 | '--------' | | mux M1 |--. | mux M2 |--. .--------. |
| 226 | | '----------' | '----------' '--| dev D2 | |
| 227 | | .--------. | .--------. '--------' |
| 228 | '--| dev D4 | '--| dev D3 | |
| 229 | '--------' '--------' |
| 230 | |
| 231 | When device D1 is accessed, accesses to D2 are locked out for the |
| 232 | full duration of the operation (muxes on the top child adapter of M1 |
| 233 | are locked). But accesses to D3 and D4 are possibly interleaved at |
Luca Ceresoli | 92d5d64 | 2022-08-24 10:31:04 +0200 | [diff] [blame] | 234 | any point. |
| 235 | |
| 236 | Accesses to D3 locks out D1 and D2, but accesses to D4 are still possibly |
| 237 | interleaved. |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 238 | |
| 239 | |
| 240 | Mux-locked mux as parent of parent-locked mux |
| 241 | --------------------------------------------- |
| 242 | |
Mauro Carvalho Chehab | ccf988b | 2019-07-26 09:51:16 -0300 | [diff] [blame] | 243 | This is probably a bad topology:: |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 244 | |
| 245 | .----------. .----------. .--------. |
| 246 | .--------. | mux- |-----| parent- |-----| dev D1 | |
| 247 | | root |--+--| locked | | locked | '--------' |
| 248 | '--------' | | mux M1 |--. | mux M2 |--. .--------. |
| 249 | | '----------' | '----------' '--| dev D2 | |
| 250 | | .--------. | .--------. '--------' |
| 251 | '--| dev D4 | '--| dev D3 | |
| 252 | '--------' '--------' |
| 253 | |
| 254 | When device D1 is accessed, accesses to D2 and D3 are locked out |
| 255 | for the full duration of the operation (M1 locks child muxes on the |
| 256 | root adapter). But accesses to D4 are possibly interleaved at any |
| 257 | point. |
| 258 | |
| 259 | This kind of topology is generally not suitable and should probably |
| 260 | be avoided. The reason is that M2 probably assumes that there will |
Luca Ceresoli | 2f07c05 | 2020-01-29 16:19:29 +0100 | [diff] [blame] | 261 | be no I2C transfers during its calls to ->select and ->deselect, and |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 262 | if there are, any such transfers might appear on the slave side of M2 |
Luca Ceresoli | 2f07c05 | 2020-01-29 16:19:29 +0100 | [diff] [blame] | 263 | as partial I2C transfers, i.e. garbage or worse. This might cause |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 264 | device lockups and/or other problems. |
| 265 | |
| 266 | The topology is especially troublesome if M2 is an auto-closing |
| 267 | mux. In that case, any interleaved accesses to D4 might close M2 |
Luca Ceresoli | 48ca3b7 | 2020-01-29 16:19:31 +0100 | [diff] [blame] | 268 | prematurely, as might any I2C transfers part of M1->select. |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 269 | |
| 270 | But if M2 is not making the above stated assumption, and if M2 is not |
| 271 | auto-closing, the topology is fine. |
| 272 | |
| 273 | |
| 274 | Parent-locked mux as parent of mux-locked mux |
| 275 | --------------------------------------------- |
| 276 | |
Mauro Carvalho Chehab | ccf988b | 2019-07-26 09:51:16 -0300 | [diff] [blame] | 277 | This is a good topology:: |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 278 | |
| 279 | .----------. .----------. .--------. |
| 280 | .--------. | parent- |-----| mux- |-----| dev D1 | |
| 281 | | root |--+--| locked | | locked | '--------' |
| 282 | '--------' | | mux M1 |--. | mux M2 |--. .--------. |
| 283 | | '----------' | '----------' '--| dev D2 | |
| 284 | | .--------. | .--------. '--------' |
| 285 | '--| dev D4 | '--| dev D3 | |
| 286 | '--------' '--------' |
| 287 | |
| 288 | When D1 is accessed, accesses to D2 are locked out for the full |
| 289 | duration of the operation (muxes on the top child adapter of M1 |
| 290 | are locked). Accesses to D3 and D4 are possibly interleaved at |
| 291 | any point, just as is expected for mux-locked muxes. |
| 292 | |
| 293 | When D3 or D4 are accessed, everything else is locked out. For D3 |
| 294 | accesses, M1 locks the root adapter. For D4 accesses, the root |
| 295 | adapter is locked directly. |
| 296 | |
| 297 | |
| 298 | Two mux-locked sibling muxes |
| 299 | ---------------------------- |
| 300 | |
Mauro Carvalho Chehab | ccf988b | 2019-07-26 09:51:16 -0300 | [diff] [blame] | 301 | This is a good topology:: |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 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 are locked out. But |
| 319 | accesses to D5 may be interleaved at any time. |
| 320 | |
| 321 | |
| 322 | Two parent-locked sibling muxes |
| 323 | ------------------------------- |
| 324 | |
Mauro Carvalho Chehab | ccf988b | 2019-07-26 09:51:16 -0300 | [diff] [blame] | 325 | This is a good topology:: |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 326 | |
Peter Rosin | f10a59e | 2016-11-10 15:03:21 +0100 | [diff] [blame] | 327 | .--------. |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 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 other devices are locked |
| 343 | out. |
| 344 | |
| 345 | |
| 346 | Mux-locked and parent-locked sibling muxes |
| 347 | ------------------------------------------ |
| 348 | |
Mauro Carvalho Chehab | ccf988b | 2019-07-26 09:51:16 -0300 | [diff] [blame] | 349 | This is a good topology:: |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 350 | |
Peter Rosin | f10a59e | 2016-11-10 15:03:21 +0100 | [diff] [blame] | 351 | .--------. |
Peter Rosin | 2254d24 | 2016-05-04 22:15:30 +0200 | [diff] [blame] | 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 D4 are locked out while |
| 367 | accesses to D5 may interleave. When D3 or D4 are accessed, accesses to |
| 368 | all other devices are locked out. |
Luca Ceresoli | 92d5d64 | 2022-08-24 10:31:04 +0200 | [diff] [blame] | 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 | ======================= ============================================= |