Lines Matching refs:are
5 There are a couple of reasons for building more complex I2C topologies
20 These constructs are represented as I2C adapter trees by Linux, where
23 I2C transfers, and all adapters with a parent are part of an "i2c-mux"
37 There are two variants of locking available to I2C muxes, they can be
47 all involved gpio pins are controlled by the
56 all involved pinctrl devices are controlled
85 adapter are locked. Mux-locked muxes are mostly interesting if the
99 mux-locked muxes that are not siblings, when there are address
144 These transfers are normal I2C transfers that locks the parent
152 This means that accesses to D2 are lockout out for the full duration
153 of the entire operation. But accesses to D3 are possibly interleaved
163 adapter during the transaction are unlocked I2C transfers (using e.g.
164 __i2c_transfer), or a deadlock will follow. There are a couple of
178 caused by these subsystems are unlocked. This can be convoluted to
216 This means that accesses to both D2 and D3 are locked out for the full
237 When any device is accessed, all other devices are locked out for
261 When device D1 is accessed, accesses to D2 are locked out for the
263 are locked). But accesses to D3 and D4 are possibly interleaved at
265 are still possibly interleaved.
282 When device D1 is accessed, accesses to D2 and D3 are locked out
284 root adapter). But accesses to D4 are possibly interleaved at any
290 if there are, any such transfers might appear on the slave side of M2
316 When D1 is accessed, accesses to D2 are locked out for the full
318 are locked). Accesses to D3 and D4 are possibly interleaved at
321 When D3 or D4 are accessed, everything else is locked out. For D3
346 When D1 is accessed, accesses to D2, D3 and D4 are locked out. But
370 When any device is accessed, accesses to all other devices are locked
394 When D1 or D2 are accessed, accesses to D3 and D4 are locked out while
395 accesses to D5 may interleave. When D3 or D4 are accessed, accesses to
396 all other devices are locked out.