u-boot/drivers/i2c/muxes/Makefile

#
# Copyright (c) 2015 Google, Inc
#
# SPDX-License-Identifier:	GPL-2.0+
#
obj-$(CONFIG_I2C_ARB_GPIO_CHALLENGE) += i2c-arb-gpio-challenge.o
obj-$(CONFIG_I2C_MUX) += i2c-mux-uclass.o
dm: i2c: Add support for multiplexed I2C buses Add a new I2C_MUX uclass. Devices in this class can multiplex between several I2C buses, selecting them one at a time for use by the system. The multiplexing mechanism is left to the driver to decide - it may be controlled by GPIOs, for example. The uclass supports only two methods: select() and deselect(). The current mux state is expected to be stored in the mux itself since it is the only thing that knows how to make things work. The mux can record the current state and then avoid switching unless it is necessary. So select() can be skipped if the mux is already in the correct state. Also deselect() can be made a nop if required. Signed-off-by: Simon Glass <sjg@chromium.org> 2015-08-03 14:19:21 +00:00			`#`
			`# Copyright (c) 2015 Google, Inc`
			`#`
			`# SPDX-License-Identifier: GPL-2.0+`
			`#`
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> 2015-08-03 14:19:22 +00:00			`obj-$(CONFIG_I2C_ARB_GPIO_CHALLENGE) += i2c-arb-gpio-challenge.o`
dm: i2c: Add support for multiplexed I2C buses Add a new I2C_MUX uclass. Devices in this class can multiplex between several I2C buses, selecting them one at a time for use by the system. The multiplexing mechanism is left to the driver to decide - it may be controlled by GPIOs, for example. The uclass supports only two methods: select() and deselect(). The current mux state is expected to be stored in the mux itself since it is the only thing that knows how to make things work. The mux can record the current state and then avoid switching unless it is necessary. So select() can be skipped if the mux is already in the correct state. Also deselect() can be made a nop if required. Signed-off-by: Simon Glass <sjg@chromium.org> 2015-08-03 14:19:21 +00:00			`obj-$(CONFIG_I2C_MUX) += i2c-mux-uclass.o`