u-boot/doc/README.i2c

4 While I2C supports multi-master buses this is difficult to get right.
5 The implementation on the master side in software is quite complex.
6 Clock-stretching and the arbitrary time that an I2C transaction can take
8 When one or more masters can be reset independently part-way through a
11 U-Boot provides a scheme based on two 'claim' GPIOs, one driven by the
12 AP (Application Processor, meaning the main CPU) and one driven by the EC
13 (Embedded Controller, a small CPU aimed at handling system tasks). With
16 reboots by either side without difficulty.
18 Since U-Boot runs on the AP, the terminology used is 'our' claim GPIO,
23 i2c-arb-gpio-challenge for the implementation.
26 each have a 'bus claim' line, which is an output that the other can see.
28 - AP_CLAIM: output from AP, signalling to the EC that the AP wants the bus
29 - EC_CLAIM: output from EC, signalling to the AP that the EC wants the bus
32 sure that the other side doesn't want it also. A detailed explanation is best
38 2. Waits a little bit for the other side to notice (slew time)
41 4. Otherwise, wait for a few milliseconds (retry time) and see if EC_CLAIM is
43 5. If not, back off, release the claim and wait for a few more milliseconds
46 7. Panic. The other side is hung with the CLAIM line set.
50 To release the bus, just de-assert the claim line.
53 - slew time 10 us
54 - retry time 3 ms
55 - wait time - 50ms
59 scheme works very nicely with very low contention. There is only a 10 us
60 wait for access to the bus assuming that the other side isn't using it.