1*4882a593SmuzhiyunI2C Bus Arbitration 2*4882a593Smuzhiyun=================== 3*4882a593Smuzhiyun 4*4882a593SmuzhiyunWhile I2C supports multi-master buses this is difficult to get right. 5*4882a593SmuzhiyunThe implementation on the master side in software is quite complex. 6*4882a593SmuzhiyunClock-stretching and the arbitrary time that an I2C transaction can take 7*4882a593Smuzhiyunmake it difficult to share the bus fairly in the face of high traffic. 8*4882a593SmuzhiyunWhen one or more masters can be reset independently part-way through a 9*4882a593Smuzhiyuntransaction it is hard to know the state of the bus. 10*4882a593Smuzhiyun 11*4882a593SmuzhiyunU-Boot provides a scheme based on two 'claim' GPIOs, one driven by the 12*4882a593SmuzhiyunAP (Application Processor, meaning the main CPU) and one driven by the EC 13*4882a593Smuzhiyun(Embedded Controller, a small CPU aimed at handling system tasks). With 14*4882a593Smuzhiyunthese they can communicate and reliably share the bus. This scheme has 15*4882a593Smuzhiyunminimal overhead and involves very little code. The scheme can survive 16*4882a593Smuzhiyunreboots by either side without difficulty. 17*4882a593Smuzhiyun 18*4882a593SmuzhiyunSince U-Boot runs on the AP, the terminology used is 'our' claim GPIO, 19*4882a593Smuzhiyunmeaning the AP's, and 'their' claim GPIO, meaning the EC's. This terminology 20*4882a593Smuzhiyunis used by the device tree bindings in Linux also. 21*4882a593Smuzhiyun 22*4882a593SmuzhiyunThe driver is implemented as an I2C mux, as it is in Linux. See 23*4882a593Smuzhiyuni2c-arb-gpio-challenge for the implementation. 24*4882a593Smuzhiyun 25*4882a593SmuzhiyunGPIO lines are shared between the AP and EC to manage the bus. The AP and EC 26*4882a593Smuzhiyuneach have a 'bus claim' line, which is an output that the other can see. 27*4882a593Smuzhiyun 28*4882a593Smuzhiyun- AP_CLAIM: output from AP, signalling to the EC that the AP wants the bus 29*4882a593Smuzhiyun- EC_CLAIM: output from EC, signalling to the AP that the EC wants the bus 30*4882a593Smuzhiyun 31*4882a593SmuzhiyunThe basic algorithm is to assert your line when you want the bus, then make 32*4882a593Smuzhiyunsure that the other side doesn't want it also. A detailed explanation is best 33*4882a593Smuzhiyundone with an example. 34*4882a593Smuzhiyun 35*4882a593SmuzhiyunLet's say the AP wants to claim the bus. It: 36*4882a593Smuzhiyun 37*4882a593Smuzhiyun1. Asserts AP_CLAIM 38*4882a593Smuzhiyun2. Waits a little bit for the other side to notice (slew time) 39*4882a593Smuzhiyun3. Checks EC_CLAIM. If this is not asserted, then the AP has the bus, and we 40*4882a593Smuzhiyun are done 41*4882a593Smuzhiyun4. Otherwise, wait for a few milliseconds (retry time) and see if EC_CLAIM is 42*4882a593Smuzhiyun released 43*4882a593Smuzhiyun5. If not, back off, release the claim and wait for a few more milliseconds 44*4882a593Smuzhiyun (retry time again) 45*4882a593Smuzhiyun6. Go back to 1 if things don't look wedged (wait time has expired) 46*4882a593Smuzhiyun7. Panic. The other side is hung with the CLAIM line set. 47*4882a593Smuzhiyun 48*4882a593SmuzhiyunThe same algorithm applies on the EC. 49*4882a593Smuzhiyun 50*4882a593SmuzhiyunTo release the bus, just de-assert the claim line. 51*4882a593Smuzhiyun 52*4882a593SmuzhiyunTypical delays are: 53*4882a593Smuzhiyun- slew time 10 us 54*4882a593Smuzhiyun- retry time 3 ms 55*4882a593Smuzhiyun- wait time - 50ms 56*4882a593Smuzhiyun 57*4882a593SmuzhiyunIn general the traffic is fairly light, and in particular the EC wants access 58*4882a593Smuzhiyunto the bus quite rarely (maybe every 10s or 30s to check the battery). This 59*4882a593Smuzhiyunscheme works very nicely with very low contention. There is only a 10 us 60*4882a593Smuzhiyunwait for access to the bus assuming that the other side isn't using it. 61