| Simon Glass | e6346b0 | 2015-08-03 08:19:22 -0600 | [diff] [blame] | 1 | I2C Bus Arbitration |
| 2 | =================== |
| 3 | |
| 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 |
| 7 | make it difficult to share the bus fairly in the face of high traffic. |
| 8 | When one or more masters can be reset independently part-way through a |
| 9 | transaction it is hard to know the state of the bus. |
| 10 | |
| 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 |
| 14 | these they can communicate and reliably share the bus. This scheme has |
| 15 | minimal overhead and involves very little code. The scheme can survive |
| 16 | reboots by either side without difficulty. |
| 17 | |
| 18 | Since U-Boot runs on the AP, the terminology used is 'our' claim GPIO, |
| 19 | meaning the AP's, and 'their' claim GPIO, meaning the EC's. This terminology |
| 20 | is used by the device tree bindings in Linux also. |
| 21 | |
| 22 | The driver is implemented as an I2C mux, as it is in Linux. See |
| 23 | i2c-arb-gpio-challenge for the implementation. |
| 24 | |
| 25 | GPIO lines are shared between the AP and EC to manage the bus. The AP and EC |
| 26 | each 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 | |
| 31 | The basic algorithm is to assert your line when you want the bus, then make |
| 32 | sure that the other side doesn't want it also. A detailed explanation is best |
| 33 | done with an example. |
| 34 | |
| 35 | Let's say the AP wants to claim the bus. It: |
| 36 | |
| 37 | 1. Asserts AP_CLAIM |
| 38 | 2. Waits a little bit for the other side to notice (slew time) |
| 39 | 3. Checks EC_CLAIM. If this is not asserted, then the AP has the bus, and we |
| 40 | are done |
| 41 | 4. Otherwise, wait for a few milliseconds (retry time) and see if EC_CLAIM is |
| 42 | released |
| 43 | 5. If not, back off, release the claim and wait for a few more milliseconds |
| 44 | (retry time again) |
| 45 | 6. Go back to 1 if things don't look wedged (wait time has expired) |
| 46 | 7. Panic. The other side is hung with the CLAIM line set. |
| 47 | |
| 48 | The same algorithm applies on the EC. |
| 49 | |
| 50 | To release the bus, just de-assert the claim line. |
| 51 | |
| 52 | Typical delays are: |
| 53 | - slew time 10 us |
| 54 | - retry time 3 ms |
| 55 | - wait time - 50ms |
| 56 | |
| 57 | In general the traffic is fairly light, and in particular the EC wants access |
| 58 | to the bus quite rarely (maybe every 10s or 30s to check the battery). This |
| 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. |