Lines Matching +full:i2c +full:- +full:bus

2 Linux I2C slave interface description
5 by Wolfram Sang <wsa@sang-engineering.com> in 2014-15
7 Linux can also be an I2C slave if the I2C controller in use has slave
8 functionality. For that to work, one needs slave support in the bus driver plus
10 example for the latter is the slave-eeprom driver, which acts as a dual memory
11 driver. While another I2C master on the bus can access it like a regular
12 EEPROM, the Linux I2C slave can access the content via sysfs and handle data as
13 needed. The backend driver and the I2C bus driver communicate via events. Here
16 use a character device, be in-kernel only, or something completely different::
19 e.g. sysfs I2C slave events I/O registers
20 +-----------+ v +---------+ v +--------+ v +------------+
21 | Userspace +........+ Backend +-----------+ Driver +-----+ Controller |
22 +-----------+ +---------+ +--------+ +------------+
24 ----------------------------------------------------------------+-- I2C
25 --------------------------------------------------------------+---- Bus
27 Note: Technically, there is also the I2C core between the backend and the
34 I2C slave backends behave like standard I2C clients. So, you can instantiate
35 them as described in the document instantiating-devices.rst. The only
36 difference is that i2c slave backends have their own address space. So, you
38 instantiating the slave-eeprom driver from userspace at the 7 bit address 0x64
39 on bus 1::
41 # echo slave-24c02 0x1064 > /sys/bus/i2c/devices/i2c-1/new_device
50 First, the events which are used by the bus driver and the backend will be
51 described in detail. After that, some implementation hints for extending bus
55 I2C slave events
56 ----------------
58 The bus driver sends an event to the backend using the following function::
62 'client' describes the I2C slave device. 'event' is one of the special event
67 bus drivers and must be checked for by backend drivers.
77 Another I2C master wants to write data to us. This event should be sent once
79 there is nothing to process or return. After returning, the bus driver must
81 wakeup is done and further data may be received. If 'ret' is an errno, the bus
91 Another I2C master wants to read data from us. This event should be sent once
92 our own address and the read bit was detected. After returning, the bus driver
97 'val': bus driver delivers received byte
101 Another I2C master has sent a byte to us which needs to be set in 'val'. If 'ret'
102 is zero, the bus driver should ack this byte. If 'ret' is an errno, then the byte
111 The bus driver requests the next byte to be sent to another I2C master in
113 only means that the previous byte is shifted out to the bus! To ensure seamless
127 reset its state machine for I2C transfers to be able to receive new requests.
131 -----------------
140 Check the i2c-slave-eeprom driver as an example.
143 Bus driver support
144 ------------------
146 If you want to add slave support to the bus driver:
149 struct i2c_algorithm. When registering, you probably need to set the I2C
157 Note that most hardware supports being master _and_ slave on the same bus. So,
158 if you extend a bus driver, please make sure that the driver supports that as
162 Check the i2c-rcar driver as an example.
166 --------------
171 while the I2C specification is more loose on that. Most I2C controllers also
180 all I2C controllers have the possibility to report that event.
184 -------------
190 * Buffers should be opt-in and backend drivers will always have to support
191 byte-based transactions as the ultimate fallback anyhow because this is how
201 error-prone.