summaryrefslogtreecommitdiff
path: root/drivers/i2c/muxes
AgeCommit message (Collapse)Author
2020-05-18common: Drop linux/delay.h from common headerSimon Glass
Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18common: Drop log.h from common headerSimon Glass
Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18common: Drop image.h from common headerSimon Glass
Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-04-20i2c: muxes: pca954x: add PCA9546 variantChris Packham
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-02-05dm: core: Create a new header file for 'compat' featuresSimon Glass
At present dm/device.h includes the linux-compatible features. This requires including linux/compat.h which in turn includes a lot of headers. One of these is malloc.h which we thus end up including in every file in U-Boot. Apart from the inefficiency of this, it is problematic for sandbox which needs to use the system malloc() in some files. Move the compatibility features into a separate header file. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-02-05dm: core: Require users of devres to include the headerSimon Glass
At present devres.h is included in all files that include dm.h but few make use of it. Also this pulls in linux/compat which adds several more headers. Drop the automatic inclusion and require files to include devres themselves. This provides a good indication of which files use devres. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de>
2019-12-15dm: gpio: Allow control of GPIO uclass in SPLSimon Glass
At present if CONFIG_SPL_GPIO_SUPPORT is enabled then the GPIO uclass is included in SPL/TPL without any control for boards. Some boards may want to disable this to reduce code size where GPIOs are not needed in SPL or TPL. Add a new Kconfig option to permit this. Default it to 'y' so that existing boards work correctly. Change existing uses of CONFIG_DM_GPIO to CONFIG_IS_ENABLED(DM_GPIO) to preserve the current behaviour. Also update the 74x164 GPIO driver since it cannot build with SPL. This allows us to remove the hacks in config_uncmd_spl.h and Makefile.uncmd_spl (eventually those files should be removed). Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-08-27i2c-mux-gpio: Fix GPIO request flag issueYe Li
When requesting GPIO, the GPIOD_IS_OUT is missed in flag, so the GPIO is set the input mode not output and cause mux not work. Signed-off-by: Ye Li <ye.li@nxp.com>
2019-04-11i2c: muxes: pca954x: support PCA9543 I2C switchLuca Ceresoli
The PCA9543 is a 2-channel I2C switch. Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Reviewed-by: Heiko Schocher <hs@denx.de> Acked-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Heiko Schocher<hs@denx.de>
2019-04-11i2c: muxes: pca954x: clarify enable fieldLuca Ceresoli
The chip_desc.enable field is used only for muxes, not for switches. Document it and remove the unused values. Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Reviewed-by: Heiko Schocher <hs@denx.de> Acked-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Heiko Schocher<hs@denx.de>
2019-04-11i2c: muxes: pca954x: update list of supported devicesLuca Ceresoli
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-02-11i2c: mux: Generate longer i2c mux nameMichal Simek
For !DM case busses are listed as ZynqMP> i2c bus Bus 0: zynq_0 Bus 1: zynq_0->PCA9544A@0x75:0 Bus 2: zynq_0->PCA9544A@0x75:1 Bus 3: zynq_0->PCA9544A@0x75:2 Bus 4: zynq_1 Bus 5: zynq_1->PCA9548@0x74:0 Bus 6: zynq_1->PCA9548@0x74:1 Bus 7: zynq_1->PCA9548@0x74:2 Bus 8: zynq_1->PCA9548@0x74:3 Bus 9: zynq_1->PCA9548@0x74:4 Bus 10: zynq_1->PCA9548@0x75:0 Bus 11: zynq_1->PCA9548@0x75:1 Bus 12: zynq_1->PCA9548@0x75:2 Bus 13: zynq_1->PCA9548@0x75:3 Bus 14: zynq_1->PCA9548@0x75:4 Bus 15: zynq_1->PCA9548@0x75:5 Bus 16: zynq_1->PCA9548@0x75:6 Bus 17: zynq_1->PCA9548@0x75:7 where is exactly describing i2c bus topology. By moving to DM case i2c mux buses are using names from DT and because i2c-muxes describing sub busses with the same names like i2c@0, etc it is hard to identify which bus is where. Linux is adding topology information to i2c-mux busses to identify them better. This patch is doing the same and composing bus name with topology information. When patch is applied with topology information on zcu102-revA. ZynqMP> i2c bus Bus 0: i2c@ff020000 20: gpio@20, offset len 1, flags 0 21: gpio@21, offset len 1, flags 0 75: i2c-mux@75, offset len 1, flags 0 Bus 2: i2c@ff020000->i2c-mux@75->i2c@0 Bus 3: i2c@ff020000->i2c-mux@75->i2c@1 Bus 4: i2c@ff020000->i2c-mux@75->i2c@2 Bus 1: i2c@ff030000 (active 1) 74: i2c-mux@74, offset len 1, flags 0 75: i2c-mux@75, offset len 1, flags 0 Bus 5: i2c@ff030000->i2c-mux@74->i2c@0 (active 5) 54: eeprom@54, offset len 1, flags 0 Bus 6: i2c@ff030000->i2c-mux@74->i2c@1 Bus 7: i2c@ff030000->i2c-mux@74->i2c@2 Bus 8: i2c@ff030000->i2c-mux@74->i2c@3 Bus 9: i2c@ff030000->i2c-mux@74->i2c@4 Bus 10: i2c@ff030000->i2c-mux@75->i2c@0 Bus 11: i2c@ff030000->i2c-mux@75->i2c@1 Bus 12: i2c@ff030000->i2c-mux@75->i2c@2 Bus 13: i2c@ff030000->i2c-mux@75->i2c@3 Bus 14: i2c@ff030000->i2c-mux@75->i2c@4 Bus 15: i2c@ff030000->i2c-mux@75->i2c@5 Bus 16: i2c@ff030000->i2c-mux@75->i2c@6 Bus 17: i2c@ff030000->i2c-mux@75->i2c@7 Behavior before the patch is applied. ZynqMP> i2c bus Bus 0: i2c@ff020000 20: gpio@20, offset len 1, flags 0 21: gpio@21, offset len 1, flags 0 75: i2c-mux@75, offset len 1, flags 0 Bus 2: i2c@0 Bus 3: i2c@1 Bus 4: i2c@2 Bus 1: i2c@ff030000 (active 1) 74: i2c-mux@74, offset len 1, flags 0 75: i2c-mux@75, offset len 1, flags 0 Bus 5: i2c@0 (active 5) 54: eeprom@54, offset len 1, flags 0 Bus 6: i2c@1 Bus 7: i2c@2 Bus 8: i2c@3 Bus 9: i2c@4 Bus 10: i2c@0 Bus 11: i2c@1 Bus 12: i2c@2 Bus 13: i2c@3 Bus 14: i2c@4 Bus 15: i2c@5 Bus 16: i2c@6 Bus 17: i2c@7 Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
2019-01-15i2c: mux: Covert to livetree functionsMichal Simek
Updates i2c muxes drivers to support livetree. Similar changes were done by: "net: zynq_gem: convert to use livetree" (sha1: 26026e695afa794ac018a09e79a48120d322b60d) Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2018-08-17kconfig: fix typo 'parition'Simon Goldschmidt
Replaced misspelled words "parition"/"paritioning" (missing 't') in two Kconfig files by correct words "partition"/"partitioning" Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
2018-08-06i2c-mux: pca954x: support pca9646 i2c switchPeng Fan
Add the PCA9646 support, which is 2-wire bus switch and buffered 4-channel. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Anatolij Gustschin <agust@denx.de>
2018-05-07SPDX: Convert all of our single license tags to Linux Kernel styleTom Rini
When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com>
2017-10-11i2c: muxes: pca954x: look up width from chip_descChris Packham
Commit 8e6eda7cda6c ("drivers/i2c/muxes/pca954x: Add pca9547 I2C mux support") introduced a chip_desc for the pca954x devices but failed to update pca954x_ofdata_to_platdata() to be aware of it. Make pca954x_ofdata_to_platdata() lookup the chip_desc to validate the device width. Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Marek Behun <marek.behun@nic.cz>
2017-09-13i2c: muxes: pca954x: Add support for GPIO reset lineMoritz Fischer
This commit adds support for GPIO reset lines matching the common linux "reset-gpios" devicetree binding. Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com> Reviewed-by: Heiko Schocher <hs@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-08-23i2c: muxes: add i2c gpio multiplexer driverPeng Fan
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-07-12drivers/i2c/muxes/pca954x: Add pca9547 I2C mux supportMarek BehĂșn
This I2C mux is found, for example, on the Turris Omnia board. Signed-off-by: Marek Behun <marek.behun@nic.cz> Reviewed-by: Heiko Schocher <hs@denx.de> Signed-off-by: Stefan Roese <sr@denx.de>
2017-06-01dm: core: Update device_bind_driver_to_node() to use ofnodeSimon Glass
Adjust this function to us an ofnode instead of an offset, so it can be used with livetree. This involves updating all callers. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-02-08dm: core: Replace of_offset with accessorSimon Glass
At present devices use a simple integer offset to record the device tree node associated with the device. In preparation for supporting a live device tree, which uses a node pointer instead, refactor existing code to access this field through an inline function. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-01-18i2c: mux: Allow muxes to work as children of i2c bus without i2c-parentMoritz Fischer
For mux check if the parent is already a device of UCLASS_I2C and if yes just use that. Otherwise see if someone specified an i2c-parent phandle. This mimics the behavior found in the Kernel, as it removes the requirement to explicitly specify a i2c-parent phandle. Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com> Cc: Heiko Schocher <hs@denx.de> Cc: Bin Meng <bmeng.cn@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Michal Simek <michal.simek@xilinx.com> Cc: u-boot@lists.denx.de
2016-08-12i2c: Drop redundant platform data setting in driversSimon Glass
The i2c uclass has a default setting for per_child_platdata_auto_alloc_size so drivers do not need to set it. Remove this from drivers to avoid confusion. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-05-17i2c: muxes: Add support for TI PCA954X muxMichal Simek
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-01-21dm: i2c: Allow muxes to be enabled for SPL separatelySimon Glass
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>
2015-12-11Kconfig: i2c: Fix indentationMichal Simek
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-11Kconfig: i2c: Fix typo Suport -> SupportMichal Simek
Fix typo in command description. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2015-08-05i2c: Add a mux for GPIO-based I2C bus arbitrationSimon Glass
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-05dm: i2c: Add support for multiplexed I2C busesSimon Glass
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>