On 3 August 2015 at 08:19, Simon Glass <s...@chromium.org> wrote: > 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 <s...@chromium.org> > --- > > Changes in v2: > - Add a README explaining the algorithm and update the commit message > > doc/README.i2c | 60 ++++++++++++ > drivers/i2c/muxes/Kconfig | 9 ++ > drivers/i2c/muxes/Makefile | 1 + > drivers/i2c/muxes/i2c-arb-gpio-challenge.c | 147 > +++++++++++++++++++++++++++++ > 4 files changed, 217 insertions(+) > create mode 100644 doc/README.i2c > create mode 100644 drivers/i2c/muxes/i2c-arb-gpio-challenge.c
Applied to u-boot-dm. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
