diff options
Diffstat (limited to 'kernel/Documentation/i2c')
| -rw-r--r-- | kernel/Documentation/i2c/busses/i2c-i801 | 3 | ||||
| -rw-r--r-- | kernel/Documentation/i2c/busses/i2c-parport | 1 | ||||
| -rw-r--r-- | kernel/Documentation/i2c/slave-interface | 34 | ||||
| -rw-r--r-- | kernel/Documentation/i2c/ten-bit-addresses | 4 |
4 files changed, 29 insertions, 13 deletions
diff --git a/kernel/Documentation/i2c/busses/i2c-i801 b/kernel/Documentation/i2c/busses/i2c-i801 index 82f48f774..1bba38dd2 100644 --- a/kernel/Documentation/i2c/busses/i2c-i801 +++ b/kernel/Documentation/i2c/busses/i2c-i801 @@ -30,6 +30,9 @@ Supported adapters: * Intel BayTrail (SOC) * Intel Sunrise Point-H (PCH) * Intel Sunrise Point-LP (PCH) + * Intel DNV (SOC) + * Intel Broxton (SOC) + * Intel Lewisburg (PCH) Datasheets: Publicly available at the Intel website On Intel Patsburg and later chipsets, both the normal host SMBus controller diff --git a/kernel/Documentation/i2c/busses/i2c-parport b/kernel/Documentation/i2c/busses/i2c-parport index 0e2d17b46..c3dbb3bfd 100644 --- a/kernel/Documentation/i2c/busses/i2c-parport +++ b/kernel/Documentation/i2c/busses/i2c-parport @@ -20,6 +20,7 @@ It currently supports the following devices: * (type=5) Analog Devices evaluation boards: ADM1025, ADM1030, ADM1031 * (type=6) Barco LPT->DVI (K5800236) adapter * (type=7) One For All JP1 parallel port adapter + * (type=8) VCT-jig These devices use different pinout configurations, so you have to tell the driver what you have, using the type module parameter. There is no diff --git a/kernel/Documentation/i2c/slave-interface b/kernel/Documentation/i2c/slave-interface index b228ca54b..61ed05cd9 100644 --- a/kernel/Documentation/i2c/slave-interface +++ b/kernel/Documentation/i2c/slave-interface @@ -3,16 +3,16 @@ Linux I2C slave interface description by Wolfram Sang <wsa@sang-engineering.com> in 2014-15 -Linux can also be an I2C slave in case I2C controllers have slave support. -Besides this HW requirement, one also needs a software backend providing the -actual functionality. An example for this is the slave-eeprom driver, which -acts as a dual memory driver. While another I2C master on the bus can access it -like a regular EEPROM, the Linux I2C slave can access the content via sysfs and -retrieve/provide information as needed. The software backend driver and the I2C -bus driver communicate via events. Here is a small graph visualizing the data -flow and the means by which data is transported. The dotted line marks only one -example. The backend could also use e.g. a character device, be in-kernel -only, or something completely different: +Linux can also be an I2C slave if the I2C controller in use has slave +functionality. For that to work, one needs slave support in the bus driver plus +a hardware independent software backend providing the actual functionality. An +example for the latter is the slave-eeprom driver, which acts as a dual memory +driver. While another I2C master on the bus can access it like a regular +EEPROM, the Linux I2C slave can access the content via sysfs and handle data as +needed. The backend driver and the I2C bus driver communicate via events. Here +is a small graph visualizing the data flow and the means by which data is +transported. The dotted line marks only one example. The backend could also +use a character device, be in-kernel only, or something completely different: e.g. sysfs I2C slave events I/O registers @@ -31,10 +31,13 @@ User manual =========== I2C slave backends behave like standard I2C clients. So, you can instantiate -them as described in the document 'instantiating-devices'. A quick example for -instantiating the slave-eeprom driver from userspace at address 0x64 on bus 1: +them as described in the document 'instantiating-devices'. The only difference +is that i2c slave backends have their own address space. So, you have to add +0x1000 to the address you would originally request. An example for +instantiating the slave-eeprom driver from userspace at the 7 bit address 0x64 +on bus 1: - # echo slave-24c02 0x64 > /sys/bus/i2c/devices/i2c-1/new_device + # echo slave-24c02 0x1064 > /sys/bus/i2c/devices/i2c-1/new_device Each backend should come with separate documentation to describe its specific behaviour and setup. @@ -43,6 +46,11 @@ behaviour and setup. Developer manual ================ +First, the events which are used by the bus driver and the backend will be +described in detail. After that, some implementation hints for extending bus +drivers and writing backends will be given. + + I2C slave events ---------------- diff --git a/kernel/Documentation/i2c/ten-bit-addresses b/kernel/Documentation/i2c/ten-bit-addresses index cdfe13901..7b2d11e53 100644 --- a/kernel/Documentation/i2c/ten-bit-addresses +++ b/kernel/Documentation/i2c/ten-bit-addresses @@ -2,6 +2,10 @@ The I2C protocol knows about two kinds of device addresses: normal 7 bit addresses, and an extended set of 10 bit addresses. The sets of addresses do not intersect: the 7 bit address 0x10 is not the same as the 10 bit address 0x10 (though a single device could respond to both of them). +To avoid ambiguity, the user sees 10 bit addresses mapped to a different +address space, namely 0xa000-0xa3ff. The leading 0xa (= 10) represents the +10 bit mode. This is used for creating device names in sysfs. It is also +needed when instantiating 10 bit devices via the new_device file in sysfs. I2C messages to and from 10-bit address devices have a different format. See the I2C specification for the details. |