diff options
| author | Vadim Bendebury <vbendeb@chromium.org> | 2018-08-31 16:10:16 -0700 |
|---|---|---|
| committer | chrome-bot <chrome-bot@chromium.org> | 2018-09-20 11:39:53 -0700 |
| commit | c7ecee85c7448707ea80d35794a9d6834c1aa684 (patch) | |
| tree | 9eb3f190e55400f089a4d3b62f943618be0e3127 /third_party | |
| parent | dd818f7e1b80611f8a6ccf3a79f46e1b952db742 (diff) | |
| download | chrome-ec-c7ecee85c7448707ea80d35794a9d6834c1aa684.tar.gz | |
g: fix i2cm NACK processing
When g i2c master controller encounters a NACK it seems to stop
processing instruction set included in the INST register and leaves
SCL low holding up the bus.
Issuing an explicit STOP request in this situation makes sure that the
controller completes the NACKed access cycle.
BRANCH=cr50, cr50-mp
BUG=b:112283593, b:113906660
TEST=verified that when running i2cscan the NACKed cycles complete
properly, and the command could be ram multiple times. On
dragonegg:
> i2csc
Scanning 0 master.................................................
0x60................
0x80.
0x82.
0x84.
0x86.............
0xa0...............................................
> i2csc
Scanning 0 master.................................................
0x60................
0x80.
0x82.
0x84.
0x86.............
0xa0...............................................
>
Change-Id: I7ffff5f32c9f57eb2672318fc8ebd9f74441445d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1200078
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Diffstat (limited to 'third_party')
0 files changed, 0 insertions, 0 deletions