summaryrefslogtreecommitdiff
path: root/include/linux/i2c-mux.h
AgeCommit message (Collapse)AuthorFilesLines
2016-08-25i2c: mux: add support for 'i2c-mux', 'i2c-arb' and 'i2c-gate' DT subnodesPeter Rosin1-2/+6
Backwards compatibility is preserved; the subnodes are in practice optional. However, the mux core needs to know what subnode it should examine, so add a couple of new flags for i2c_mux_alloc for this purpose. The rule is that if the mux core finds a 'reg' property in the appropriate subnode, e.g. if 'reg' exists in the 'i2c-mux' subnode, then the mux core will assume that this is an old style entry and not an i2c-mux subnode (correspondingly for arbitrators and gates with 'i2c-arb' and 'i2c-gate'). Reviewed-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Peter Rosin <peda@axentia.se>
2016-05-04i2c: mux: relax locking of the top i2c adapter during mux-locked muxingPeter Rosin1-0/+8
With a i2c topology like the following GPIO ---| ------ BAT1 | v / I2C -----+----------+---- MUX | \ EEPROM ------ BAT2 there is a locking problem with the GPIO controller since it is a client on the same i2c bus that it muxes. Transfers to the mux clients (e.g. BAT1) will lock the whole i2c bus prior to attempting to switch the mux to the correct i2c segment. In the above case, the GPIO device is an I/O expander with an i2c interface, and since the GPIO subsystem knows nothing (and rightfully so) about the lockless needs of the i2c mux code, this results in a deadlock when the GPIO driver issues i2c transfers to modify the mux. So, observing that while it is needed to have the i2c bus locked during the actual MUX update in order to avoid random garbage on the slave side, it is not strictly a must to have it locked over the whole sequence of a full select-transfer-deselect mux client operation. The mux itself needs to be locked, so transfers to clients behind the mux are serialized, and the mux needs to be stable during all i2c traffic (otherwise individual mux slave segments might see garbage, or worse). Introduce this new locking concept as "mux-locked" muxes, and call the pre-existing mux locking scheme "parent-locked". Modify the i2c mux locking so that muxes that are "mux-locked" locks only the muxes on the parent adapter instead of the whole i2c bus when there is a transfer to the slave side of the mux. This lock serializes transfers to the slave side of the muxes on the parent adapter. Add code to i2c-mux-gpio and i2c-mux-pinctrl that checks if all involved gpio/pinctrl devices have a parent that is an i2c adapter in the same adapter tree that is muxed, and request a "mux-locked mux" if that is the case. Modify the select-transfer-deselect code for "mux-locked" muxes so that each of the select-transfer-deselect ops locks the mux parent adapter individually. Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-04-22i2c: mux: drop old unused i2c-mux apiPeter Rosin1-15/+0
All i2c mux users are using an explicit i2c mux core, drop support for implicit i2c mux cores. Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-04-22i2c: mux: add common data for every i2c-mux instancePeter Rosin1-0/+34
All i2c-muxes have a parent adapter and one or many child adapters. A mux also has some means of selection. Previously, this was stored per child adapter, but it is only needed to keep track of this per mux. Add an i2c mux core, that keeps track of this consistently. Also add some glue for users of the old interface, which will create one implicit mux core per child adapter. Signed-off-by: Peter Rosin <peda@axentia.se> Tested-by: Antti Palosaari <crope@iki.fi> Tested-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-04-02i2c: Make the return type of i2c_del_mux_adapter() voidLars-Peter Clausen1-1/+1
i2c_del_mux_adapter always returns 0 and none of it current users check its return value anyway. It is also an essential requirement of the Linux device driver model, that functions which may be called from a device's remove callback to free resources provided by the device, are not allowed to fail. This is the case for i2c_del_mux_adapter(), so make its return type void to make the fact that it won't fail explicit. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2012-10-06i2c-mux: Add support for device auto-detectionJean Delvare1-0/+1
Let I2C bus segments behind multiplexers have a class. This allows for device auto-detection on these segments. As long as parent segments don't share the same class, it should be fine. I implemented support in drivers i2c-mux-gpio and i2c-mux-pca954x. I left i2c-mux-pca9541 and i2c-mux-pinctrl alone for the moment as I don't know if this feature makes sense for the use cases of these drivers. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Peter Korsgaard <peter.korsgaard@barco.com> Cc: David Daney <david.daney@cavium.com> Cc: Michael Lawnick <ml.lawnick@gmx.de> Cc: Rodolfo Giometti <giometti@linux.it>
2012-05-12i2c: Add a struct device * parameter to i2c_add_mux_adapter()David Daney1-1/+2
And adjust all callers. The new device parameter is used in the next patch to initialize the mux's of_node so that its children may be automatically populated. Signed-off-by: David Daney <david.daney@cavium.com> Tested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-03-26i2c: Update the FSF addressJean Delvare1-1/+2
Signed-off-by: Jean Delvare <khali@linux-fr.org>
2010-08-11i2c: Multiplexed I2C bus core supportMichael Lawnick1-0/+46
Add multiplexed bus core support. I2C multiplexer and switches like pca954x get instantiated as new adapters per port. Signed-off-by: Michael Lawnick <ml.lawnick@gmx.de> Acked-by: Rodolfo Giometti <giometti@linux.it> Signed-off-by: Jean Delvare <khali@linux-fr.org>