hollalinux
/
linux-sg2042
mirror of https://github.com/sophgo/linux-riscv.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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>
This commit is contained in:
Luca Ceresoli 2020-01-29 16:19:46 +01:00 committed by Wolfram Sang
parent 4f71daf629
commit da9a80bf19
1 changed files with 60 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

109
Documentation/i2c/instantiating-devices.rst
View File

@ -9,14 +9,67 @@ reason, the kernel code must instantiate I2C devices explicitly. There are
several ways to achieve this, depending on the context and requirements. several ways to achieve this, depending on the context and requirements.
Method 1a: Declare the I2C devices by bus number Method 1: Declare the I2C devices statically
------------------------------------------------ --------------------------------------------
This method is appropriate when the I2C bus is a system bus as is the case This method is appropriate when the I2C bus is a system bus as is the case
for many embedded systems. On such systems, each I2C bus has a number for many embedded systems. On such systems, each I2C bus has a number which
which is known in advance. It is thus possible to pre-declare the I2C is known in advance. It is thus possible to pre-declare the I2C devices
devices which live on this bus. This is done with an array of struct which live on this bus.
i2c_board_info which is registered by calling i2c_register_board_info().
This information is provided to the kernel in a different way on different
architectures: device tree, ACPI or board files.
When the I2C bus in question is registered, the I2C devices will be
instantiated automatically by i2c-core. The devices will be automatically
unbound and destroyed when the I2C bus they sit on goes away (if ever).
Declare the I2C devices via devicetree
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On platforms using devicetree, the declaration of I2C devices is done in
subnodes of the master controller.
Example::
i2c1: i2c@400a0000 {
/* ... master properties skipped ... */
clock-frequency = <100000>;
flash@50 {
compatible = "atmel,24c256";
reg = <0x50>;
};
pca9532: gpio@60 {
compatible = "nxp,pca9532";
gpio-controller;
#gpio-cells = <2>;
reg = <0x60>;
};
};
Here, two devices are attached to the bus using a speed of 100kHz. For
additional properties which might be needed to set up the device, please refer
to its devicetree documentation in Documentation/devicetree/bindings/.
Declare the I2C devices via ACPI
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ACPI can also describe I2C devices. There is special documentation for this
which is currently located at :doc:`../firmware-guide/acpi/enumeration`.
Declare the I2C devices in board files
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In many embedded architectures, devicetree has replaced the old hardware
description based on board files, but the latter are still used in old
code. Instantiating I2C devices via board files is done with an array of
struct i2c_board_info which is registered by calling
i2c_register_board_info().
Example (from omap2 h4):: Example (from omap2 h4)::
@ -44,49 +97,7 @@ Example (from omap2 h4)::
} }
The above code declares 3 devices on I2C bus 1, including their respective The above code declares 3 devices on I2C bus 1, including their respective
addresses and custom data needed by their drivers. When the I2C bus in addresses and custom data needed by their drivers.
question is registered, the I2C devices will be instantiated automatically
by i2c-core.
The devices will be automatically unbound and destroyed when the I2C bus
they sit on goes away (if ever.)
Method 1b: Declare the I2C devices via devicetree
-------------------------------------------------
This method has the same implications as method 1a. The declaration of I2C
devices is here done via devicetree as subnodes of the master controller.
Example::
i2c1: i2c@400a0000 {
/* ... master properties skipped ... */
clock-frequency = <100000>;
flash@50 {
compatible = "atmel,24c256";
reg = <0x50>;
};
pca9532: gpio@60 {
compatible = "nxp,pca9532";
gpio-controller;
#gpio-cells = <2>;
reg = <0x60>;
};
};
Here, two devices are attached to the bus using a speed of 100kHz. For
additional properties which might be needed to set up the device, please refer
to its devicetree documentation in Documentation/devicetree/bindings/.
Method 1c: Declare the I2C devices via ACPI
-------------------------------------------
ACPI can also describe I2C devices. There is special documentation for this
which is currently located at :doc:`../firmware-guide/acpi/enumeration`.
Method 2: Instantiate the devices explicitly Method 2: Instantiate the devices explicitly