Skip to content

Commit 6429883

Browse files
committed
Merge tag 'i2c-for-6.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c fixes from Wolfram Sang: "Only documentation and DT binding fixes and improvements" * tag 'i2c-for-6.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: dt-bindings: i2c: renesas,riic: Fix 'unevaluatedProperties' warnings docs: i2c: piix4: Fix typos, add markup, drop link docs: i2c: i2c-topology: reorder sections more logically docs: i2c: i2c-topology: fix incorrect heading docs: i2c: i2c-topology: fix typo
2 parents 2ccd450 + 4e2a2ed commit 6429883

File tree

3 files changed

+123
-107
lines changed

3 files changed

+123
-107
lines changed

Documentation/devicetree/bindings/i2c/renesas,riic.yaml

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -60,6 +60,9 @@ properties:
6060
power-domains:
6161
maxItems: 1
6262

63+
resets:
64+
maxItems: 1
65+
6366
required:
6467
- compatible
6568
- reg

Documentation/i2c/busses/i2c-piix4.rst

Lines changed: 5 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -64,7 +64,7 @@ correct address for this module, you could get in big trouble (read:
6464
crashes, data corruption, etc.). Try this only as a last resort (try BIOS
6565
updates first, for example), and backup first! An even more dangerous
6666
option is 'force_addr=<IOPORT>'. This will not only enable the PIIX4 like
67-
'force' foes, but it will also set a new base I/O port address. The SMBus
67+
'force' does, but it will also set a new base I/O port address. The SMBus
6868
parts of the PIIX4 needs a range of 8 of these addresses to function
6969
correctly. If these addresses are already reserved by some other device,
7070
you will get into big trouble! DON'T USE THIS IF YOU ARE NOT VERY SURE
@@ -86,15 +86,15 @@ If you own Force CPCI735 motherboard or other OSB4 based systems you may need
8686
to change the SMBus Interrupt Select register so the SMBus controller uses
8787
the SMI mode.
8888

89-
1) Use lspci command and locate the PCI device with the SMBus controller:
89+
1) Use ``lspci`` command and locate the PCI device with the SMBus controller:
9090
00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 4f)
9191
The line may vary for different chipsets. Please consult the driver source
92-
for all possible PCI ids (and lspci -n to match them). Lets assume the
92+
for all possible PCI ids (and ``lspci -n`` to match them). Let's assume the
9393
device is located at 00:0f.0.
9494
2) Now you just need to change the value in 0xD2 register. Get it first with
95-
command: lspci -xxx -s 00:0f.0
95+
command: ``lspci -xxx -s 00:0f.0``
9696
If the value is 0x3 then you need to change it to 0x1:
97-
setpci -s 00:0f.0 d2.b=1
97+
``setpci -s 00:0f.0 d2.b=1``
9898

9999
Please note that you don't need to do that in all cases, just when the SMBus is
100100
not working properly.
@@ -109,6 +109,3 @@ which can easily get corrupted due to a state machine bug. These are mostly
109109
Thinkpad laptops, but desktop systems may also be affected. We have no list
110110
of all affected systems, so the only safe solution was to prevent access to
111111
the SMBus on all IBM systems (detected using DMI data.)
112-
113-
For additional information, read:
114-
http://www.lm-sensors.org/browser/lm-sensors/trunk/README

Documentation/i2c/i2c-topology.rst

Lines changed: 115 additions & 99 deletions
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,8 @@ I2C muxes and complex topologies
55
There are a couple of reasons for building more complex I2C topologies
66
than a straight-forward I2C bus with one adapter and one or more devices.
77

8+
Some example use cases are:
9+
810
1. A mux may be needed on the bus to prevent address collisions.
911

1012
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.
1416
from the I2C bus, at least most of the time, and sits behind a gate
1517
that has to be operated before the device can be accessed.
1618

17-
Etc
18-
===
19+
Several types of hardware components such as I2C muxes, I2C gates and I2C
20+
arbitrators allow to handle such needs.
1921

20-
These constructs are represented as I2C adapter trees by Linux, where
22+
These components are represented as I2C adapter trees by Linux, where
2123
each adapter has a parent adapter (except the root adapter) and zero or
2224
more child adapters. The root adapter is the actual adapter that issues
2325
I2C transfers, and all adapters with a parent are part of an "i2c-mux"
@@ -35,46 +37,7 @@ Locking
3537
=======
3638

3739
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.
7841

7942

8043
Mux-locked muxes
@@ -89,40 +52,8 @@ full transaction, unrelated I2C transfers may interleave the different
8952
stages of the transaction. This has the benefit that the mux driver
9053
may be easier and cleaner to implement, but it has some caveats.
9154

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-
12355
Mux-locked Example
124-
------------------
125-
56+
~~~~~~~~~~~~~~~~~~
12657

12758
::
12859

@@ -153,6 +84,43 @@ This means that accesses to D2 are lockout out for the full duration
15384
of the entire operation. But accesses to D3 are possibly interleaved
15485
at any point.
15586

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+
156124

157125
Parent-locked muxes
158126
-------------------
@@ -161,28 +129,10 @@ Parent-locked muxes lock the parent adapter during the full select-
161129
transfer-deselect transaction. The implication is that the mux driver
162130
has to ensure that any and all I2C transfers through that parent
163131
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.
183133

184134
Parent-locked Example
185-
---------------------
135+
~~~~~~~~~~~~~~~~~~~~~
186136

187137
::
188138

@@ -212,10 +162,30 @@ When there is an access to D1, this happens:
212162
9. M1 unlocks its parent adapter.
213163
10. M1 unlocks muxes on its parent.
214164

215-
216165
This means that accesses to both D2 and D3 are locked out for the full
217166
duration of the entire operation.
218167

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+
219189

220190
Complex Examples
221191
================
@@ -261,8 +231,10 @@ This is a good topology::
261231
When device D1 is accessed, accesses to D2 are locked out for the
262232
full duration of the operation (muxes on the top child adapter of M1
263233
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.
266238

267239

268240
Mux-locked mux as parent of parent-locked mux
@@ -394,3 +366,47 @@ This is a good topology::
394366
When D1 or D2 are accessed, accesses to D3 and D4 are locked out while
395367
accesses to D5 may interleave. When D3 or D4 are accessed, accesses to
396368
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

Comments
 (0)