1*b725dc45SSimon GlassI2C Bus Arbitration 2*b725dc45SSimon Glass=================== 3*b725dc45SSimon Glass 4*b725dc45SSimon GlassWhile I2C supports multi-master buses this is difficult to get right. 5*b725dc45SSimon GlassThe implementation on the master side in software is quite complex. 6*b725dc45SSimon GlassClock-stretching and the arbitrary time that an I2C transaction can take 7*b725dc45SSimon Glassmake it difficult to share the bus fairly in the face of high traffic. 8*b725dc45SSimon GlassWhen one or more masters can be reset independently part-way through a 9*b725dc45SSimon Glasstransaction it is hard to know the state of the bus. 10*b725dc45SSimon Glass 11*b725dc45SSimon GlassU-Boot provides a scheme based on two 'claim' GPIOs, one driven by the 12*b725dc45SSimon GlassAP (Application Processor, meaning the main CPU) and one driven by the EC 13*b725dc45SSimon Glass(Embedded Controller, a small CPU aimed at handling system tasks). With 14*b725dc45SSimon Glassthese they can communicate and reliably share the bus. This scheme has 15*b725dc45SSimon Glassminimal overhead and involves very little code. The scheme can survive 16*b725dc45SSimon Glassreboots by either side without difficulty. 17*b725dc45SSimon Glass 18*b725dc45SSimon GlassSince U-Boot runs on the AP, the terminology used is 'our' claim GPIO, 19*b725dc45SSimon Glassmeaning the AP's, and 'their' claim GPIO, meaning the EC's. This terminology 20*b725dc45SSimon Glassis used by the device tree bindings in Linux also. 21*b725dc45SSimon Glass 22*b725dc45SSimon GlassThe driver is implemented as an I2C mux, as it is in Linux. See 23*b725dc45SSimon Glassi2c-arb-gpio-challenge for the implementation. 24*b725dc45SSimon Glass 25*b725dc45SSimon GlassGPIO lines are shared between the AP and EC to manage the bus. The AP and EC 26*b725dc45SSimon Glasseach have a 'bus claim' line, which is an output that the other can see. 27*b725dc45SSimon Glass 28*b725dc45SSimon Glass- AP_CLAIM: output from AP, signalling to the EC that the AP wants the bus 29*b725dc45SSimon Glass- EC_CLAIM: output from EC, signalling to the AP that the EC wants the bus 30*b725dc45SSimon Glass 31*b725dc45SSimon GlassThe basic algorithm is to assert your line when you want the bus, then make 32*b725dc45SSimon Glasssure that the other side doesn't want it also. A detailed explanation is best 33*b725dc45SSimon Glassdone with an example. 34*b725dc45SSimon Glass 35*b725dc45SSimon GlassLet's say the AP wants to claim the bus. It: 36*b725dc45SSimon Glass 37*b725dc45SSimon Glass1. Asserts AP_CLAIM 38*b725dc45SSimon Glass2. Waits a little bit for the other side to notice (slew time) 39*b725dc45SSimon Glass3. Checks EC_CLAIM. If this is not asserted, then the AP has the bus, and we 40*b725dc45SSimon Glass are done 41*b725dc45SSimon Glass4. Otherwise, wait for a few milliseconds (retry time) and see if EC_CLAIM is 42*b725dc45SSimon Glass released 43*b725dc45SSimon Glass5. If not, back off, release the claim and wait for a few more milliseconds 44*b725dc45SSimon Glass (retry time again) 45*b725dc45SSimon Glass6. Go back to 1 if things don't look wedged (wait time has expired) 46*b725dc45SSimon Glass7. Panic. The other side is hung with the CLAIM line set. 47*b725dc45SSimon Glass 48*b725dc45SSimon GlassThe same algorithm applies on the EC. 49*b725dc45SSimon Glass 50*b725dc45SSimon GlassTo release the bus, just de-assert the claim line. 51*b725dc45SSimon Glass 52*b725dc45SSimon GlassTypical delays are: 53*b725dc45SSimon Glass- slew time 10 us 54*b725dc45SSimon Glass- retry time 3 ms 55*b725dc45SSimon Glass- wait time - 50ms 56*b725dc45SSimon Glass 57*b725dc45SSimon GlassIn general the traffic is fairly light, and in particular the EC wants access 58*b725dc45SSimon Glassto the bus quite rarely (maybe every 10s or 30s to check the battery). This 59*b725dc45SSimon Glassscheme works very nicely with very low contention. There is only a 10 us 60*b725dc45SSimon Glasswait for access to the bus assuming that the other side isn't using it. 61