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

2 Linux I2C fault injection
5 The GPIO based I2C bus master driver can be configured to provide fault
6 injection capabilities. It is then meant to be connected to another I2C bus
7 which is driven by the I2C bus master driver under test. The GPIO fault
8 injection driver can create special states on the bus which the other I2C bus
12 'i2c-fault-injector' subdirectory in the Kernel debugfs filesystem, usually
14 driven I2C bus. Each subdirectory will contain files to trigger the fault
15 injection. They will be described now along with their intended use-cases.
21 -----
26 because the bus master under test will not be able to clock. It should detect
31 -----
35 "echo 0 > sda" you force SDA low and thus, data cannot be transmitted. The bus
36 master under test should detect this condition and trigger a bus recovery (see
37 I2C specification version 4, section 3.1.16) using the helpers of the Linux I2C
38 core (see 'struct bus_recovery_info'). However, the bus recovery will not
47 device. Bus recovery should be able to fix these situations. But please note:
48 there are I2C client devices which detect a stuck SDA on their side and release
50 device deglitching and monitoring the I2C bus. It could also detect a stuck SDA
51 and will init a bus recovery on its own. If you want to implement bus recovery
52 in a bus master driver, make sure you checked your hardware setup for such
56 --------------------------
58 This file is write only and you need to write the address of an existing I2C
63 above, the bus master under test should detect this condition and try a bus
68 -----------------------
71 an existing I2C client device to it.
82 This is why bus recovery (up to 9 clock pulses) must either check SDA or send
83 additional STOP conditions to ensure the bus has been released. Otherwise
90 bus arbitration against another master in a multi-master setup.
93 ------------------
97 and wait for the next bus clock. The process is interruptible, though.
100 test and then pulling SDA low for some time. So, the I2C address sent out
107 idle bus is::
110   # i2cget -y <bus_to_test> 0x3f
116 started a transfer. This usually means that the state machine of the bus master
117 driver will be ungracefully interrupted and the bus may end up in an unusual
122 --------------
126 The calling process will then sleep and wait for the next bus clock. The
133   # i2cget -y <bus_to_test> <some_address>