tjh.dev
Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
docs: i2c: instantiating-devices: rearrange static instatiation
Among the "static" instantiation methods the "board file" method is
described first. Move it as last, since it is being replaced by the other
methods.
Also fix subsubsection heading syntax and remove the "Method 1[abc]"
prefix as the subsubsection structure clarifies the logical hierarchy.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
authored by
Luca Ceresoli
and committed by
Wolfram Sang
da9a80bf
4f71daf6
+60
-49
+60
-49
Documentation/i2c/instantiating-devices.rst
+60
-49
Documentation/i2c/instantiating-devices.rst
···
9
9
several ways to achieve this, depending on the context and requirements.
10
10
11
11
12
-
Method 1a: Declare the I2C devices by bus number
13
-
------------------------------------------------
12
+
Method 1: Declare the I2C devices statically
13
+
--------------------------------------------
14
14
15
15
This method is appropriate when the I2C bus is a system bus as is the case
16
-
for many embedded systems. On such systems, each I2C bus has a number
17
-
which is known in advance. It is thus possible to pre-declare the I2C
18
-
devices which live on this bus. This is done with an array of struct
19
-
i2c_board_info which is registered by calling i2c_register_board_info().
16
+
for many embedded systems. On such systems, each I2C bus has a number which
17
+
is known in advance. It is thus possible to pre-declare the I2C devices
18
+
which live on this bus.
19
+
20
+
This information is provided to the kernel in a different way on different
21
+
architectures: device tree, ACPI or board files.
22
+
23
+
When the I2C bus in question is registered, the I2C devices will be
24
+
instantiated automatically by i2c-core. The devices will be automatically
25
+
unbound and destroyed when the I2C bus they sit on goes away (if ever).
26
+
27
+
28
+
Declare the I2C devices via devicetree
29
+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
30
+
31
+
On platforms using devicetree, the declaration of I2C devices is done in
32
+
subnodes of the master controller.
33
+
34
+
Example::
35
+
36
+
i2c1: i2c@400a0000 {
37
+
/* ... master properties skipped ... */
38
+
clock-frequency = <100000>;
39
+
40
+
flash@50 {
41
+
compatible = "atmel,24c256";
42
+
reg = <0x50>;
43
+
};
44
+
45
+
pca9532: gpio@60 {
46
+
compatible = "nxp,pca9532";
47
+
gpio-controller;
48
+
#gpio-cells = <2>;
49
+
reg = <0x60>;
50
+
};
51
+
};
52
+
53
+
Here, two devices are attached to the bus using a speed of 100kHz. For
54
+
additional properties which might be needed to set up the device, please refer
55
+
to its devicetree documentation in Documentation/devicetree/bindings/.
56
+
57
+
58
+
Declare the I2C devices via ACPI
59
+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
60
+
61
+
ACPI can also describe I2C devices. There is special documentation for this
62
+
which is currently located at :doc:`../firmware-guide/acpi/enumeration`.
63
+
64
+
65
+
Declare the I2C devices in board files
66
+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
67
+
68
+
In many embedded architectures, devicetree has replaced the old hardware
69
+
description based on board files, but the latter are still used in old
70
+
code. Instantiating I2C devices via board files is done with an array of
71
+
struct i2c_board_info which is registered by calling
72
+
i2c_register_board_info().
20
73
21
74
Example (from omap2 h4)::
22
75
···
97
44
}
98
45
99
46
The above code declares 3 devices on I2C bus 1, including their respective
100
-
addresses and custom data needed by their drivers. When the I2C bus in
101
-
question is registered, the I2C devices will be instantiated automatically
102
-
by i2c-core.
103
-
104
-
The devices will be automatically unbound and destroyed when the I2C bus
105
-
they sit on goes away (if ever.)
106
-
107
-
108
-
Method 1b: Declare the I2C devices via devicetree
109
-
-------------------------------------------------
110
-
111
-
This method has the same implications as method 1a. The declaration of I2C
112
-
devices is here done via devicetree as subnodes of the master controller.
113
-
114
-
Example::
115
-
116
-
i2c1: i2c@400a0000 {
117
-
/* ... master properties skipped ... */
118
-
clock-frequency = <100000>;
119
-
120
-
flash@50 {
121
-
compatible = "atmel,24c256";
122
-
reg = <0x50>;
123
-
};
124
-
125
-
pca9532: gpio@60 {
126
-
compatible = "nxp,pca9532";
127
-
gpio-controller;
128
-
#gpio-cells = <2>;
129
-
reg = <0x60>;
130
-
};
131
-
};
132
-
133
-
Here, two devices are attached to the bus using a speed of 100kHz. For
134
-
additional properties which might be needed to set up the device, please refer
135
-
to its devicetree documentation in Documentation/devicetree/bindings/.
136
-
137
-
138
-
Method 1c: Declare the I2C devices via ACPI
139
-
-------------------------------------------
140
-
141
-
ACPI can also describe I2C devices. There is special documentation for this
142
-
which is currently located at :doc:`../firmware-guide/acpi/enumeration`.
47
+
addresses and custom data needed by their drivers.
143
48
144
49
145
50
Method 2: Instantiate the devices explicitly