1I2C Bus Arbitration 2=================== 3 4While I2C supports multi-master buses this is difficult to get right. 5The implementation on the master side in software is quite complex. 6Clock-stretching and the arbitrary time that an I2C transaction can take 7make it difficult to share the bus fairly in the face of high traffic. 8When one or more masters can be reset independently part-way through a 9transaction it is hard to know the state of the bus. 10 11U-Boot provides a scheme based on two 'claim' GPIOs, one driven by the 12AP (Application Processor, meaning the main CPU) and one driven by the EC 13(Embedded Controller, a small CPU aimed at handling system tasks). With 14these they can communicate and reliably share the bus. This scheme has 15minimal overhead and involves very little code. The scheme can survive 16reboots by either side without difficulty. 17 18Since U-Boot runs on the AP, the terminology used is 'our' claim GPIO, 19meaning the AP's, and 'their' claim GPIO, meaning the EC's. This terminology 20is used by the device tree bindings in Linux also. 21 22The driver is implemented as an I2C mux, as it is in Linux. See 23i2c-arb-gpio-challenge for the implementation. 24 25GPIO lines are shared between the AP and EC to manage the bus. The AP and EC 26each have a 'bus claim' line, which is an output that the other can see. 27 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 30 31The basic algorithm is to assert your line when you want the bus, then make 32sure that the other side doesn't want it also. A detailed explanation is best 33done with an example. 34 35Let's say the AP wants to claim the bus. It: 36 371. Asserts AP_CLAIM 382. Waits a little bit for the other side to notice (slew time) 393. Checks EC_CLAIM. If this is not asserted, then the AP has the bus, and we 40 are done 414. Otherwise, wait for a few milliseconds (retry time) and see if EC_CLAIM is 42 released 435. If not, back off, release the claim and wait for a few more milliseconds 44 (retry time again) 456. Go back to 1 if things don't look wedged (wait time has expired) 467. Panic. The other side is hung with the CLAIM line set. 47 48The same algorithm applies on the EC. 49 50To release the bus, just de-assert the claim line. 51 52Typical delays are: 53- slew time 10 us 54- retry time 3 ms 55- wait time - 50ms 56 57In general the traffic is fairly light, and in particular the EC wants access 58to the bus quite rarely (maybe every 10s or 30s to check the battery). This 59scheme works very nicely with very low contention. There is only a 10 us 60wait for access to the bus assuming that the other side isn't using it. 61