Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-12-13 06:42:56 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/drivers/i2c/muxes/Kconfig

47 lines
1.7 KiB
Text
Raw Normal View History

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
config I2C_MUX
Kconfig: i2c: Fix typo Suport -> Support Fix typo in command description. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2015-12-08 10:18:53 +00:00
bool "Support I2C multiplexers"
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
depends on DM_I2C
help
This enables I2C buses to be multiplexed, so that you can select
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.
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
dm: i2c: Allow muxes to be enabled for SPL separately Since I2C muxes are seldom needed in SPL, and the code for this increases the size somewhat, add a separate option to enable I2C muxes for SPL. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-01-22 02:43:53 +00:00
config SPL_I2C_MUX
bool "Support I2C multiplexers on SPL"
spl: Ensure all SPL symbols in Kconfig have some SPL dependency Tighten up symbol dependencies in a number of places. Ensure that a SPL specific option has at least a direct dependency on SPL. In places where it's clear that we depend on something more specific, use that dependency instead. This means in a very small number of places we can drop redundant dependencies. Reported-by: Pali Rohár <pali@kernel.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2022-06-11 03:03:09 +00:00
depends on SPL && I2C_MUX
dm: i2c: Allow muxes to be enabled for SPL separately Since I2C muxes are seldom needed in SPL, and the code for this increases the size somewhat, add a separate option to enable I2C muxes for SPL. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-01-22 02:43:53 +00:00
help
This enables I2C buses to be multiplexed, so that you can select
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.
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
config I2C_ARB_GPIO_CHALLENGE
Kconfig: i2c: Fix indentation Use tabs instead of space for indentation. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2015-12-08 10:18:54 +00:00
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.
i2c: muxes: Add support for TI PCA954X mux Add support for common TI i2c mux which is available on ZynqMP zcu102 board. DM i2c mux core code is selecting/deselecting bus before/after every command is performed that's why only one channel is active at a time. That's also the reason why deselect is just disable all available channels. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Heiko Schocher <hs@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-04-25 08:50:42 +00:00
config I2C_MUX_PCA954x
tristate "TI PCA954x I2C Mux/switches"
depends on I2C_MUX
help
i2c: muxes: pca954x: update list of supported devices The Kconfig help has not been updated while adding PCA9547 and PCA9646. Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Acked-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Heiko Schocher<hs@denx.de>
2019-04-09 06:57:41 +00:00
If you say yes here you get support for the TI PCA954x I2C mux/switch
devices. It is x width I2C multiplexer which enables to partitioning
I2C bus and connect multiple devices with the same address to the same
I2C controller where driver handles proper routing to target i2c
i2c: muxes: pca954x: add PCA9546 variant This adds the PCA9546 4-channel i2c bus switch. Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-04-01 02:55:27 +00:00
device. Supported chips are PCA9543, PCA9544, PCA9546, PCA9547,
PCA9548 and PCA9646.
i2c: muxes: add i2c gpio multiplexer driver Add an i2c mux driver providing access to i2c bus segments using a hardware MUX sitting on a master bus and controlled through gpio pins. E.G. something like: ---------- ---------- Bus segment 1 - - - - - | | SCL/SDA | |-------------- | | | |------------| | | | | | Bus segment 2 | | | Linux | GPIO 1..N | MUX |--------------- Devices | |------------| | | | | | | | Bus segment M | | | |---------------| | ---------- ---------- - - - - - SCL/SDA of the master I2C bus is multiplexed to bus segment 1..M according to the settings of the GPIO pins 1..N. Note commit log from kernel commit 92ed1a76("i2c: Add generic I2C multiplexer using GPIO API") Signed-off-by: Peng Fan <peng.fan@nxp.com> Tested-by: Peng Fan <peng.fan@nxp.com> (i.MX6QP-Sabreauto) Cc: Heiko Schocher <hs@denx.de> Cc: Stefano Babic <sbabic@denx.de> Cc: Simon Glass <sjg@chromium.org>
2017-08-14 10:00:05 +00:00
config I2C_MUX_GPIO
tristate "GPIO-based I2C multiplexer"
depends on I2C_MUX && DM_GPIO
help
If you say yes to this option, support will be included for
a GPIO based I2C multiplexer. This driver provides access to
I2C busses connected through a MUX, which is controlled
through GPIO pins.
Reference in a new issue Copy permalink