summaryrefslogtreecommitdiffstats
path: root/drivers/i2c/i2c-mux.c
Commit message (Collapse)AuthorAgeFilesLines
* i2c: mux: only print failure message on errorPeter Rosin2017-05-151-10/+16
| | | | | | | | As is, a failure message is printed unconditionally, which is confusing. And noisy. Fixes: 8d4d159f25a7 ("i2c: mux: provide more info on failure in i2c_mux_add_adapter") Signed-off-by: Peter Rosin <peda@axentia.se>
* i2c: mux: provide more info on failure in i2c_mux_add_adapterPeter Rosin2017-04-031-3/+6
| | | | | | | | No callers then need to report any further info, thus reducing both the amount of code and the log noise. Reviewed-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Peter Rosin <peda@axentia.se>
* i2c: add missing of_node_put in i2c_mux_del_adaptersQi Hou2017-03-031-0/+2
| | | | | | | | | | Refcount of of_node is increased with of_node_get() in i2c_mux_add_adapter(). It must be decreased with of_node_put() in i2c_mux_del_adapters(). Cc: stable@vger.kernel.org Signed-off-by: Qi Hou <qi.hou@windriver.com> Reviewed-by: Zhang Xiao <xiao.zhang@windriver.com> Signed-off-by: Peter Rosin <peda@axentia.se>
* i2c: move locking operations to their own structPeter Rosin2016-08-301-9/+16
| | | | | | | | This makes it trivial to constify them, so do that. Signed-off-by: Peter Rosin <peda@axentia.se> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* Merge branch 'i2c-mux-dt-3' of https://github.com/peda-r/i2c-mux into ↵Wolfram Sang2016-08-261-8/+36
|\ | | | | | | | | | | i2c/for-4.9 Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * i2c: mux: add support for 'i2c-mux', 'i2c-arb' and 'i2c-gate' DT subnodesPeter Rosin2016-08-251-8/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | i2c: add i2c_trylock_bus wrapper, use itPeter Rosin2016-08-251-2/+2
|/ | | | | | | | | This unifies usage with i2c_lock_bus and i2c_unlock_bus, and paves the way for the next patch which looks a bit saner with this preparatory work taken care of beforehand. Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: mux: relax locking of the top i2c adapter during mux-locked muxingPeter Rosin2016-05-041-13/+139
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* i2c: muxes always lock the parent adapterPeter Rosin2016-05-041-0/+30
| | | | | | | | | Instead of checking for i2c parent adapters for every lock/unlock, simply override the locking for muxes to always lock/unlock the parent adapter directly. Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: mux: drop old unused i2c-mux apiPeter Rosin2016-04-221-63/+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>
* i2c: mux: add common data for every i2c-mux instancePeter Rosin2016-04-221-41/+134
| | | | | | | | | | | | | | | | | 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>
* i2c: i2c-mux: sort includesWolfram Sang2016-02-201-4/+4
| | | | | | | I request this for drivers, so the core should adhere to sorted includes as well. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: add ACPI support for I2C mux portsDustin Byford2015-10-251-0/+8
| | | | | | | | | | | | | | | | | | | | | Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or device property compatible string match), enumerating I2C client devices connected through an I2C mux needs a little extra work. This change implements a method for describing an I2C device hierarchy that includes mux devices by using an ACPI Device() for each mux channel along with an _ADR to set the channel number for the device. See Documentation/acpi/i2c-muxes.txt for a simple example. To make this work the ismt, i801, and designware pci/platform devs now share an ACPI companion with their I2C adapter dev similar to how it's done in OF. This is done on the assumption that power management functions will not be called directly on the I2C dev that is sharing the ACPI node. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Dustin Byford <dustin@cumulusnetworks.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: mux: Use __i2c_transfer() instead of calling parent's master_xfer()Alexander Sverdlin2015-06-171-1/+1
| | | | | | | | | | | | | | | Newly introduced quirks infrastructure doesn't work for the devices behind MUXes because MUX's master_xfer() calls parent's master_xfer() directly without checking the quirks. Instead of duplicating check code in MUX just call __i2c_transfer() instead. This has a side effect on tracing (messages will appear on both MUX bus and parent bus), but maybe that's not bad at the end. Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Tested-by: Łukasz Gemborowski <lukasz.gemborowski@nokia.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org Fixes: b7f625840267b1 ("i2c: add quirk checks to core")
* i2c: use parent adapter quirks in muxAlexander Sverdlin2015-06-171-0/+1
| | | | | | | | | | | Inherit parent adapter quirks in MUX in case the devices on the multiplexed buses are interested in the adapter limitations. Signed-off-by: Łukasz Gemborowski <lukasz.gemborowski@nokia.com> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org Fixes: b7f625840267b1 ("i2c: add quirk checks to core")
* i2c: mux: use proper dev when removing "channel-X" symlinksWolfram Sang2015-04-231-3/+5
| | | | | | | | | | | | | | | | Those symlinks are created for the mux_dev, so we need to remove it from there. Currently, it breaks for muxes where the mux_dev is not the device of the parent adapter like this: [ 78.234644] WARNING: CPU: 0 PID: 365 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x5c/0x78() [ 78.242438] sysfs: cannot create duplicate filename '/devices/platform/i2cbus@8/channel-0' Remove confusing comments while we are here. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Fixes: c9449affad2ae0 Cc: stable@kernel.org
* i2c: mux: create "channel-n" symlinks for child segments in the mux deviceGerlando Falauto2014-11-181-0/+8
| | | | | | | | | | | | | | | This makes the topology clearer. For instance, by adding a pca9547 device with address 0x70 to bus i2c-0, you get: /sys/class/i2c-dev/i2c-0/device/0-0070/channel-0 -> i2c-1 ... /sys/class/i2c-dev/i2c-0/device/0-0070/channel-7 -> i2c-8 Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com> [wsa: simplified sysfs-usage and fixed format string usage] Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Martin Belanger <martin.belanger@cyaninc.com> Acked-by: Danielle Costantino <danielle.costantino@gmail.com>
* i2c: mux: create symlink to actual mux deviceWolfram Sang2014-11-181-0/+4
| | | | | | | | | | | | | | | The current implementation creates muxed i2c-<n> busses as immediate children of their i2c-<n> parent bus. In case of multiple muxes on one bus, it is impossible to determine which muxed bus comes from which mux. It could be argued that the parent device should be changed from the parent adapter to the mux device. This has pros and cons. To improve the topology, simply add a "mux_device" symlink pointing to the actual muxing device, so we can distinguish muxed busses. Doing it this way, we don't break the ABI. Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Tested-by: Guenter Roeck <linux@roeck-us.net>
* i2c: mux: Inherit retry count and timeout from parent for muxed busElie De Brauwer2013-12-121-0/+2
| | | | | | | | | | | | | | If a muxed i2c bus gets created the default retry count and timeout of the muxed bus is zero. Hence it it possible that you end up with a situation where the parent controller sets a default retry count and timeout which gets applied and used while the muxed bus (using the same controller) has a default retry count of zero and a default timeout of 1s (set in i2c_add_adapter()). This can be solved by initializing the retry count and timeout of the muxed bus with the values used by the the parent at creation time. Signed-off-by: Elie De Brauwer <eliedebrauwer@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: move OF helpers into the coreWolfram Sang2013-08-231-3/+0
| | | | | | | | | | I2C of helpers used to live in of_i2c.c but experience (from SPI) shows that it is much cleaner to have this in the core. This also removes a circular dependency between the helpers and the core, and so we can finally register child nodes in the core instead of doing this manually in each driver. So, fix the drivers and documentation, too. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: Make the return type of i2c_del_mux_adapter() voidLars-Peter Clausen2013-04-021-3/+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>
* i2c: Ignore return value of i2c_del_adapter()Lars-Peter Clausen2013-04-021-4/+1
| | | | | | | | | | | | | | i2c_del_adapter() always returns 0. So all checks testing whether it will be non zero will always evaluate to false and the conditional code is dead code. This patch updates all callers of i2c_del_mux_adapter() to ignore the return value and assume that it will always succeed (which it will). In a subsequent patch the return type of i2c_del_adapter() will be made void. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Ben Hutchings <bhutchings@solarflare.com> Reviewed-by: Jean Delvare <khali@linux-fr.org> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c-mux: Add support for device auto-detectionJean Delvare2012-10-051-0/+22
| | | | | | | | | | | | | | | | | 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>
* i2c/of: Automatically populate i2c mux busses from device tree data.David Daney2012-05-121-0/+23
| | | | | | | | | | | | | | | | | | | | | | | For 'normal' i2c bus drivers, we can call of_i2c_register_devices() and have the device tree framework automatically populate the bus with the devices specified in the device tree. This patch adds a common code to the i2c mux framework to have the mux sub-busses be populated by the of_i2c_register_devices() too. If the mux device has an of_node, we populate the sub-bus' of_node so that the subsequent call to of_i2c_register_devices() will find the corresponding devices. It seemed better to put this logic in i2c_add_mux_adapter() rather than the individual mux drivers, as they will all probably want to do the same thing. Signed-off-by: David Daney <david.daney@cavium.com> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Tested-by: Lars-Peter Clausen <lars@metafoo.de> [wsa: removed superfluous ret-variable and fixed a typo in a comment] Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
* i2c: Add a struct device * parameter to i2c_add_mux_adapter()David Daney2012-05-121-9/+10
| | | | | | | | | | | 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>
* i2c: Mark i2c_adapter.id as deprecatedJean Delvare2010-11-151-1/+0
| | | | | | | | | | | It's about time to make it clear that i2c_adapter.id is deprecated. Hopefully this will remind the last user to move over to a different strategy. Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Jarod Wilson <jarod@redhat.com> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com> Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
* i2c: Multiplexed I2C bus core supportMichael Lawnick2010-08-111-0/+165
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>
OpenPOWER on IntegriCloud