xiaomi-sm8450/android_kernel_xiaomi_sm8450
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

i2c: gpio: fault-injector: refactor incomplete transfer

Browse Source 
Make the incomplete_transfer routine reusable, so we can add other test
cases with different patterns later. Prepare the docs for that, too.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
This commit is contained in:
Wolfram Sang
2018-06-29 11:12:46 +02:00
committed by Wolfram Sang
parent d07bdbc02c
commit 16d55daa56
2 changed files with 41 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
Documentation/i2c/gpio-fault-injection
View File

@@ -34,21 +34,29 @@ I2C specification version 4, section 3.1.16) using the helpers of the Linux I2C
core (see 'struct bus_recovery_info'). However, the bus recovery will not
succeed because SDA is still pinned low until you manually release it again
with "echo 1 > sda". A test with an automatic release can be done with the
'incomplete_transfer' file.
following class of fault injectors.
"incomplete_transfer"
---------------------
Introduction to incomplete transfers
------------------------------------
The following fault injectors create situations where SDA will be held low by a
device. Bus recovery should be able to fix these situations. But please note:
there are I2C client devices which detect a stuck SDA on their side and release
it on their own after a few milliseconds. Also, there might be an external
device deglitching and monitoring the I2C bus. It could also detect a stuck SDA
and will init a bus recovery on its own. If you want to implement bus recovery
in a bus master driver, make sure you checked your hardware setup for such
devices before. And always verify with a scope or logic analyzer!
"incomplete_address_phase"
--------------------------
This file is write only and you need to write the address of an existing I2C
client device to it. Then, a transfer to this device will be started, but it
will stop at the ACK phase after the address of the client has been
client device to it. Then, a read transfer to this device will be started, but
it will stop at the ACK phase after the address of the client has been
transmitted. Because the device will ACK its presence, this results in SDA
being pulled low by the device while SCL is high. So, similar to the "sda" file
above, the bus master under test should detect this condition and try a bus
recovery. This time, however, it should succeed and the device should release
SDA after toggling SCL. Please note: there are I2C client devices which detect
a stuck SDA on their side and release it on their own after a few milliseconds.
Also, there are external devices deglitching and monitoring the I2C bus. They
can also detect a stuck SDA and will init a bus recovery on their own. If you
want to implement bus recovery in a bus master driver, make sure you checked
your hardware setup carefully before.
SDA after toggling SCL.