[J-u-boot.git] / doc / README.i2c

I2C Bus Arbitration
===================

While I2C supports multi-master buses this is difficult to get right.
The implementation on the master side in software is quite complex.
Clock-stretching and the arbitrary time that an I2C transaction can take
make it difficult to share the bus fairly in the face of high traffic.
When one or more masters can be reset independently part-way through a
transaction it is hard to know the state of the bus.

U-Boot provides a scheme based on two 'claim' GPIOs, one driven by the
AP (Application Processor, meaning the main CPU) and one driven by the EC
(Embedded Controller, a small CPU aimed at handling system tasks). With
these they can communicate and reliably share the bus. This scheme has
minimal overhead and involves very little code. The scheme can survive
reboots by either side without difficulty.

Since U-Boot runs on the AP, the terminology used is 'our' claim GPIO,
meaning the AP's, and 'their' claim GPIO, meaning the EC's. This terminology
is used by the device tree bindings in Linux also.

The driver is implemented as an I2C mux, as it is in Linux. See
i2c-arb-gpio-challenge for the implementation.

GPIO lines are shared between the AP and EC to manage the bus. The AP and EC
each have a 'bus claim' line, which is an output that the other can see.

- AP_CLAIM: output from AP, signalling to the EC that the AP wants the bus
- EC_CLAIM: output from EC, signalling to the AP that the EC wants the bus

The basic algorithm is to assert your line when you want the bus, then make
sure that the other side doesn't want it also. A detailed explanation is best
done with an example.

Let's say the AP wants to claim the bus. It:

1. Asserts AP_CLAIM
2. Waits a little bit for the other side to notice (slew time)
3. Checks EC_CLAIM. If this is not asserted, then the AP has the bus, and we
   are done
4. Otherwise, wait for a few milliseconds (retry time) and see if EC_CLAIM is
   released
5. If not, back off, release the claim and wait for a few more milliseconds
  (retry time again)
6. Go back to 1 if things don't look wedged (wait time has expired)
7. Panic. The other side is hung with the CLAIM line set.

The same algorithm applies on the EC.

To release the bus, just de-assert the claim line.

Typical delays are:
- slew time 10 us
- retry time 3 ms
- wait time - 50ms

In general the traffic is fairly light, and in particular the EC wants access
to the bus quite rarely (maybe every 10s or 30s to check the battery). This
scheme works very nicely with very low contention. There is only a 10 us
wait for access to the bus assuming that the other side isn't using it.
Commit	Line	Data
b725dc45 SG	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.