aboutsummaryrefslogtreecommitdiff
path: root/Documentation/i2c
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/i2c')
-rw-r--r--Documentation/i2c/busses/i2c-i8014
-rw-r--r--Documentation/i2c/busses/i2c-parport2
-rw-r--r--Documentation/i2c/busses/i2c-parport-light2
-rw-r--r--Documentation/i2c/busses/i2c-piix42
-rw-r--r--Documentation/i2c/busses/i2c-taos-evm2
-rw-r--r--Documentation/i2c/busses/i2c-viapro2
-rw-r--r--Documentation/i2c/fault-codes3
-rw-r--r--Documentation/i2c/functionality2
-rw-r--r--Documentation/i2c/i2c-protocol35
-rw-r--r--Documentation/i2c/instantiating-devices41
10 files changed, 68 insertions, 27 deletions
diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801
index d29dea0f323..adf5e33e831 100644
--- a/Documentation/i2c/busses/i2c-i801
+++ b/Documentation/i2c/busses/i2c-i801
@@ -25,6 +25,8 @@ Supported adapters:
* Intel Avoton (SOC)
* Intel Wellsburg (PCH)
* Intel Coleto Creek (PCH)
+ * Intel Wildcat Point-LP (PCH)
+ * Intel BayTrail (SOC)
Datasheets: Publicly available at the Intel website
On Intel Patsburg and later chipsets, both the normal host SMBus controller
@@ -32,7 +34,7 @@ and the additional 'Integrated Device Function' controllers are supported.
Authors:
Mark Studebaker <mdsxyz123@yahoo.com>
- Jean Delvare <khali@linux-fr.org>
+ Jean Delvare <jdelvare@suse.de>
Module Parameters
diff --git a/Documentation/i2c/busses/i2c-parport b/Documentation/i2c/busses/i2c-parport
index 2461c7b53b2..0e2d17b460f 100644
--- a/Documentation/i2c/busses/i2c-parport
+++ b/Documentation/i2c/busses/i2c-parport
@@ -1,6 +1,6 @@
Kernel driver i2c-parport
-Author: Jean Delvare <khali@linux-fr.org>
+Author: Jean Delvare <jdelvare@suse.de>
This is a unified driver for several i2c-over-parallel-port adapters,
such as the ones made by Philips, Velleman or ELV. This driver is
diff --git a/Documentation/i2c/busses/i2c-parport-light b/Documentation/i2c/busses/i2c-parport-light
index c22ee063e1e..7071b8ba0af 100644
--- a/Documentation/i2c/busses/i2c-parport-light
+++ b/Documentation/i2c/busses/i2c-parport-light
@@ -1,6 +1,6 @@
Kernel driver i2c-parport-light
-Author: Jean Delvare <khali@linux-fr.org>
+Author: Jean Delvare <jdelvare@suse.de>
This driver is a light version of i2c-parport. It doesn't depend
on the parport driver, and uses direct I/O access instead. This might be
diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4
index c097e0f020f..aa959fd2245 100644
--- a/Documentation/i2c/busses/i2c-piix4
+++ b/Documentation/i2c/busses/i2c-piix4
@@ -13,7 +13,7 @@ Supported adapters:
* AMD SP5100 (SB700 derivative found on some server mainboards)
Datasheet: Publicly available at the AMD website
http://support.amd.com/us/Embedded_TechDocs/44413.pdf
- * AMD Hudson-2, CZ
+ * AMD Hudson-2, ML, CZ
Datasheet: Not publicly available
* Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge
Datasheet: Publicly available at the SMSC website http://www.smsc.com
diff --git a/Documentation/i2c/busses/i2c-taos-evm b/Documentation/i2c/busses/i2c-taos-evm
index 63f62bcbf59..60299555dcf 100644
--- a/Documentation/i2c/busses/i2c-taos-evm
+++ b/Documentation/i2c/busses/i2c-taos-evm
@@ -1,6 +1,6 @@
Kernel driver i2c-taos-evm
-Author: Jean Delvare <khali@linux-fr.org>
+Author: Jean Delvare <jdelvare@suse.de>
This is a driver for the evaluation modules for TAOS I2C/SMBus chips.
The modules include an SMBus master with limited capabilities, which can
diff --git a/Documentation/i2c/busses/i2c-viapro b/Documentation/i2c/busses/i2c-viapro
index b88f91ae580..ab64ce21c25 100644
--- a/Documentation/i2c/busses/i2c-viapro
+++ b/Documentation/i2c/busses/i2c-viapro
@@ -28,7 +28,7 @@ Supported adapters:
Authors:
Kyösti Mälkki <kmalkki@cc.hut.fi>,
Mark D. Studebaker <mdsxyz123@yahoo.com>,
- Jean Delvare <khali@linux-fr.org>
+ Jean Delvare <jdelvare@suse.de>
Module Parameters
-----------------
diff --git a/Documentation/i2c/fault-codes b/Documentation/i2c/fault-codes
index 045765c0b9b..47c25abb7d5 100644
--- a/Documentation/i2c/fault-codes
+++ b/Documentation/i2c/fault-codes
@@ -64,9 +64,6 @@ EINVAL
detected before any I/O operation was started. Use a more
specific fault code when you can.
- One example would be a driver trying an SMBus Block Write
- with block size outside the range of 1-32 bytes.
-
EIO
This rather vague error means something went wrong when
performing an I/O operation. Use a more specific fault
diff --git a/Documentation/i2c/functionality b/Documentation/i2c/functionality
index b0ff2ab596c..4556a3eb87c 100644
--- a/Documentation/i2c/functionality
+++ b/Documentation/i2c/functionality
@@ -46,7 +46,7 @@ A few combinations of the above flags are also defined for your convenience:
and write_block_data commands
I2C_FUNC_SMBUS_I2C_BLOCK Handles the SMBus read_i2c_block_data
and write_i2c_block_data commands
- I2C_FUNC_SMBUS_EMUL Handles all SMBus commands than can be
+ I2C_FUNC_SMBUS_EMUL Handles all SMBus commands that can be
emulated by a real I2C adapter (using
the transparent emulation layer)
diff --git a/Documentation/i2c/i2c-protocol b/Documentation/i2c/i2c-protocol
index 0b3e62d1f77..ff6d6cee6c7 100644
--- a/Documentation/i2c/i2c-protocol
+++ b/Documentation/i2c/i2c-protocol
@@ -6,8 +6,8 @@ Key to symbols
S (1 bit) : Start bit
P (1 bit) : Stop bit
Rd/Wr (1 bit) : Read/Write bit. Rd equals 1, Wr equals 0.
-A, NA (1 bit) : Accept and reverse accept bit.
-Addr (7 bits): I2C 7 bit address. Note that this can be expanded as usual to
+A, NA (1 bit) : Accept and reverse accept bit.
+Addr (7 bits): I2C 7 bit address. Note that this can be expanded as usual to
get a 10 bit I2C address.
Comm (8 bits): Command byte, a data byte which often selects a register on
the device.
@@ -49,11 +49,20 @@ a byte read, followed by a byte write:
Modified transactions
=====================
-The following modifications to the I2C protocol can also be generated,
-with the exception of I2C_M_NOSTART these are usually only needed to
-work around device issues:
+The following modifications to the I2C protocol can also be generated by
+setting these flags for i2c messages. With the exception of I2C_M_NOSTART, they
+are usually only needed to work around device issues:
- Flag I2C_M_NOSTART:
+I2C_M_IGNORE_NAK:
+ Normally message is interrupted immediately if there is [NA] from the
+ client. Setting this flag treats any [NA] as [A], and all of
+ message is sent.
+ These messages may still fail to SCL lo->hi timeout.
+
+I2C_M_NO_RD_ACK:
+ In a read message, master A/NA bit is skipped.
+
+I2C_M_NOSTART:
In a combined transaction, no 'S Addr Wr/Rd [A]' is generated at some
point. For example, setting I2C_M_NOSTART on the second partial message
generates something like:
@@ -67,17 +76,13 @@ work around device issues:
I2C device but may also be used between direction changes by some
rare devices.
- Flags I2C_M_REV_DIR_ADDR
+I2C_M_REV_DIR_ADDR:
This toggles the Rd/Wr flag. That is, if you want to do a write, but
need to emit an Rd instead of a Wr, or vice versa, you set this
flag. For example:
S Addr Rd [A] Data [A] Data [A] ... [A] Data [A] P
- Flags I2C_M_IGNORE_NAK
- Normally message is interrupted immediately if there is [NA] from the
- client. Setting this flag treats any [NA] as [A], and all of
- message is sent.
- These messages may still fail to SCL lo->hi timeout.
-
- Flags I2C_M_NO_RD_ACK
- In a read message, master A/NA bit is skipped.
+I2C_M_STOP:
+ Force a stop condition (P) after the message. Some I2C related protocols
+ like SCCB require that. Normally, you really don't want to get interrupted
+ between the messages of one transfer.
diff --git a/Documentation/i2c/instantiating-devices b/Documentation/i2c/instantiating-devices
index c70e7a7638d..0d85ac1935b 100644
--- a/Documentation/i2c/instantiating-devices
+++ b/Documentation/i2c/instantiating-devices
@@ -8,8 +8,8 @@ reason, the kernel code must instantiate I2C devices explicitly. There are
several ways to achieve this, depending on the context and requirements.
-Method 1: Declare the I2C devices by bus number
------------------------------------------------
+Method 1a: Declare the I2C devices by bus number
+------------------------------------------------
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
@@ -51,6 +51,43 @@ 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 Documentation/acpi/enumeration.txt.
+
+
Method 2: Instantiate the devices explicitly
--------------------------------------------
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2025-11-04 21:52:04 +0000