diff options
| author | Simon Glass <sjg@chromium.org> | 2015-08-03 14:19:22 (GMT) |
|---|---|---|
| committer | Simon Glass <sjg@chromium.org> | 2015-08-06 03:06:10 (GMT) |
| commit | b725dc458f9db44957d4f541d05defe178dda7b5 (patch) | |
| tree | 88b56e188c909220101857a941b2ef721cc29e02 /drivers/i2c/muxes/Kconfig | |
| parent | 3d1957f0ea0133ec06f9c6fd85dc1acdf66ad29c (diff) | |
| download | u-boot-b725dc458f9db44957d4f541d05defe178dda7b5.tar.xz | |
i2c: Add a mux for GPIO-based 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.
This driver 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. It is used on snow to
permit the EC and the AP to share access to the main system PMIC and
battery. The scheme can survive reboots by either side without difficulty.
This scheme has been tested in the field with millions of devices.
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
Diffstat (limited to 'drivers/i2c/muxes/Kconfig')
| -rw-r--r-- | drivers/i2c/muxes/Kconfig | 9 |
1 files changed, 9 insertions, 0 deletions
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig index a05b32d..bd3e078 100644 --- a/drivers/i2c/muxes/Kconfig +++ b/drivers/i2c/muxes/Kconfig @@ -6,3 +6,12 @@ config I2C_MUX one of several buses using some sort of control mechanism. The bus select is handled automatically when that bus is accessed, using a suitable I2C MUX driver. + +config I2C_ARB_GPIO_CHALLENGE + bool "GPIO-based I2C arbitration" + depends on I2C_MUX + help + If you say yes to this option, support will be included for an + I2C multimaster arbitration scheme using GPIOs and a challenge & + response mechanism where masters have to claim the bus by asserting + a GPIO. |