Lines Matching +full:wakeup +full:- +full:event +full:- +full:action

5 by Wolfram Sang <wsa@sang-engineering.com> in 2014-15
10 example for the latter is the slave-eeprom driver, which acts as a dual memory
16 use a character device, be in-kernel only, or something completely different::
20   +-----------+   v    +---------+     v     +--------+  v  +------------+
21   | Userspace +........+ Backend +-----------+ Driver +-----+ Controller |
22   +-----------+        +---------+           +--------+     +------------+
24   ----------------------------------------------------------------+--  I2C
25   --------------------------------------------------------------+----  Bus
35 them as described in the document instantiating-devices.rst. The only
38 instantiating the slave-eeprom driver from userspace at the 7 bit address 0x64
41   # echo slave-24c02 0x1064 > /sys/bus/i2c/devices/i2c-1/new_device
56 ----------------
58 The bus driver sends an event to the backend using the following function::
60 	ret = i2c_slave_event(client, event, &val)
62 'client' describes the I2C slave device. 'event' is one of the special event
65 provided even if val is not used for an event, i.e. don't use NULL here. 'ret'
69 Event types:
77 Another I2C master wants to write data to us. This event should be sent once
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
131 -----------------
140 Check the i2c-slave-eeprom driver as an example.
144 ------------------
162 Check the i2c-rcar driver as an example.
166 --------------
176 Currently, there is no slave event to report if the master did ACK or NACK a
177 byte when it reads from us. We could make this an optional event if the need
179 to send STOP after that and we have an event for that. Also, keep in mind not
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
195   because after each byte written an action should be immediately triggered.
201   error-prone.