2011-01-11 05:11:23 +08:00
|
|
|
/*
|
|
|
|
* I2C multiplexer using GPIO API
|
|
|
|
*
|
|
|
|
* Peter Korsgaard <peter.korsgaard@barco.com>
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/i2c.h>
|
|
|
|
#include <linux/i2c-mux.h>
|
2012-04-28 21:32:06 +08:00
|
|
|
#include <linux/i2c-mux-gpio.h>
|
2011-01-11 05:11:23 +08:00
|
|
|
#include <linux/platform_device.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/gpio.h>
|
i2c: mux: relax locking of the top i2c adapter during mux-locked muxing
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-05-05 04:15:29 +08:00
|
|
|
#include "../../gpio/gpiolib.h"
|
2012-10-26 00:23:53 +08:00
|
|
|
#include <linux/of_gpio.h>
|
2011-01-11 05:11:23 +08:00
|
|
|
|
|
|
|
struct gpiomux {
|
2012-04-28 21:32:06 +08:00
|
|
|
struct i2c_mux_gpio_platform_data data;
|
2012-10-06 04:23:54 +08:00
|
|
|
unsigned gpio_base;
|
2016-11-25 02:19:28 +08:00
|
|
|
struct gpio_desc **gpios;
|
|
|
|
int *values;
|
2011-01-11 05:11:23 +08:00
|
|
|
};
|
|
|
|
|
2012-04-28 21:32:06 +08:00
|
|
|
static void i2c_mux_gpio_set(const struct gpiomux *mux, unsigned val)
|
2011-01-11 05:11:23 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < mux->data.n_gpios; i++)
|
2016-11-25 02:19:28 +08:00
|
|
|
mux->values[i] = (val >> i) & 1;
|
|
|
|
|
|
|
|
gpiod_set_array_value_cansleep(mux->data.n_gpios,
|
|
|
|
mux->gpios, mux->values);
|
2011-01-11 05:11:23 +08:00
|
|
|
}
|
|
|
|
|
2016-04-20 14:39:05 +08:00
|
|
|
static int i2c_mux_gpio_select(struct i2c_mux_core *muxc, u32 chan)
|
2011-01-11 05:11:23 +08:00
|
|
|
{
|
2016-04-20 14:39:05 +08:00
|
|
|
struct gpiomux *mux = i2c_mux_priv(muxc);
|
2011-01-11 05:11:23 +08:00
|
|
|
|
2013-10-11 18:09:57 +08:00
|
|
|
i2c_mux_gpio_set(mux, chan);
|
2011-01-11 05:11:23 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-04-20 14:39:05 +08:00
|
|
|
static int i2c_mux_gpio_deselect(struct i2c_mux_core *muxc, u32 chan)
|
2011-01-11 05:11:23 +08:00
|
|
|
{
|
2016-04-20 14:39:05 +08:00
|
|
|
struct gpiomux *mux = i2c_mux_priv(muxc);
|
2011-01-11 05:11:23 +08:00
|
|
|
|
2012-04-28 21:32:06 +08:00
|
|
|
i2c_mux_gpio_set(mux, mux->data.idle);
|
2011-01-11 05:11:23 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-11-28 04:59:38 +08:00
|
|
|
static int match_gpio_chip_by_label(struct gpio_chip *chip,
|
2012-10-06 04:23:54 +08:00
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
return !strcmp(chip->label, data);
|
|
|
|
}
|
|
|
|
|
2012-10-26 00:23:53 +08:00
|
|
|
#ifdef CONFIG_OF
|
2012-11-28 04:59:38 +08:00
|
|
|
static int i2c_mux_gpio_probe_dt(struct gpiomux *mux,
|
2012-10-26 00:23:53 +08:00
|
|
|
struct platform_device *pdev)
|
|
|
|
{
|
|
|
|
struct device_node *np = pdev->dev.of_node;
|
|
|
|
struct device_node *adapter_np, *child;
|
|
|
|
struct i2c_adapter *adapter;
|
|
|
|
unsigned *values, *gpios;
|
2013-10-08 21:51:53 +08:00
|
|
|
int i = 0, ret;
|
2012-10-26 00:23:53 +08:00
|
|
|
|
|
|
|
if (!np)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
adapter_np = of_parse_phandle(np, "i2c-parent", 0);
|
|
|
|
if (!adapter_np) {
|
|
|
|
dev_err(&pdev->dev, "Cannot parse i2c-parent\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
adapter = of_find_i2c_adapter_by_node(adapter_np);
|
2015-08-27 04:59:33 +08:00
|
|
|
of_node_put(adapter_np);
|
2015-03-30 21:03:38 +08:00
|
|
|
if (!adapter)
|
2013-10-09 17:50:45 +08:00
|
|
|
return -EPROBE_DEFER;
|
2015-03-30 21:03:38 +08:00
|
|
|
|
2012-10-26 00:23:53 +08:00
|
|
|
mux->data.parent = i2c_adapter_id(adapter);
|
|
|
|
put_device(&adapter->dev);
|
|
|
|
|
|
|
|
mux->data.n_values = of_get_child_count(np);
|
|
|
|
|
|
|
|
values = devm_kzalloc(&pdev->dev,
|
|
|
|
sizeof(*mux->data.values) * mux->data.n_values,
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!values) {
|
|
|
|
dev_err(&pdev->dev, "Cannot allocate values array");
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
for_each_child_of_node(np, child) {
|
|
|
|
of_property_read_u32(child, "reg", values + i);
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
mux->data.values = values;
|
|
|
|
|
|
|
|
if (of_property_read_u32(np, "idle-state", &mux->data.idle))
|
|
|
|
mux->data.idle = I2C_MUX_GPIO_NO_IDLE;
|
|
|
|
|
|
|
|
mux->data.n_gpios = of_gpio_named_count(np, "mux-gpios");
|
|
|
|
if (mux->data.n_gpios < 0) {
|
|
|
|
dev_err(&pdev->dev, "Missing mux-gpios property in the DT.\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
gpios = devm_kzalloc(&pdev->dev,
|
|
|
|
sizeof(*mux->data.gpios) * mux->data.n_gpios, GFP_KERNEL);
|
|
|
|
if (!gpios) {
|
|
|
|
dev_err(&pdev->dev, "Cannot allocate gpios array");
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
2013-10-08 21:51:53 +08:00
|
|
|
for (i = 0; i < mux->data.n_gpios; i++) {
|
|
|
|
ret = of_get_named_gpio(np, "mux-gpios", i);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
gpios[i] = ret;
|
|
|
|
}
|
2012-10-26 00:23:53 +08:00
|
|
|
|
|
|
|
mux->data.gpios = gpios;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#else
|
2012-11-28 04:59:38 +08:00
|
|
|
static int i2c_mux_gpio_probe_dt(struct gpiomux *mux,
|
2012-10-26 00:23:53 +08:00
|
|
|
struct platform_device *pdev)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2012-11-28 04:59:38 +08:00
|
|
|
static int i2c_mux_gpio_probe(struct platform_device *pdev)
|
2011-01-11 05:11:23 +08:00
|
|
|
{
|
2016-04-20 14:39:05 +08:00
|
|
|
struct i2c_mux_core *muxc;
|
2011-01-11 05:11:23 +08:00
|
|
|
struct gpiomux *mux;
|
|
|
|
struct i2c_adapter *parent;
|
i2c: mux: relax locking of the top i2c adapter during mux-locked muxing
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-05-05 04:15:29 +08:00
|
|
|
struct i2c_adapter *root;
|
2012-10-06 04:23:54 +08:00
|
|
|
unsigned initial_state, gpio_base;
|
2011-01-11 05:11:23 +08:00
|
|
|
int i, ret;
|
|
|
|
|
2012-10-26 00:23:53 +08:00
|
|
|
mux = devm_kzalloc(&pdev->dev, sizeof(*mux), GFP_KERNEL);
|
2016-04-20 14:39:05 +08:00
|
|
|
if (!mux)
|
2012-10-26 00:23:53 +08:00
|
|
|
return -ENOMEM;
|
|
|
|
|
2013-07-30 15:59:33 +08:00
|
|
|
if (!dev_get_platdata(&pdev->dev)) {
|
2012-10-26 00:23:53 +08:00
|
|
|
ret = i2c_mux_gpio_probe_dt(mux, pdev);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
2013-07-30 15:59:33 +08:00
|
|
|
} else {
|
|
|
|
memcpy(&mux->data, dev_get_platdata(&pdev->dev),
|
|
|
|
sizeof(mux->data));
|
|
|
|
}
|
2012-10-26 00:23:53 +08:00
|
|
|
|
2012-10-06 04:23:54 +08:00
|
|
|
/*
|
|
|
|
* If a GPIO chip name is provided, the GPIO pin numbers provided are
|
|
|
|
* relative to its base GPIO number. Otherwise they are absolute.
|
|
|
|
*/
|
2012-10-26 00:23:53 +08:00
|
|
|
if (mux->data.gpio_chip) {
|
2012-10-06 04:23:54 +08:00
|
|
|
struct gpio_chip *gpio;
|
|
|
|
|
2012-10-26 00:23:53 +08:00
|
|
|
gpio = gpiochip_find(mux->data.gpio_chip,
|
2012-10-06 04:23:54 +08:00
|
|
|
match_gpio_chip_by_label);
|
|
|
|
if (!gpio)
|
|
|
|
return -EPROBE_DEFER;
|
|
|
|
|
|
|
|
gpio_base = gpio->base;
|
|
|
|
} else {
|
|
|
|
gpio_base = 0;
|
|
|
|
}
|
|
|
|
|
2012-10-26 00:23:53 +08:00
|
|
|
parent = i2c_get_adapter(mux->data.parent);
|
2015-03-30 21:03:38 +08:00
|
|
|
if (!parent)
|
2013-10-09 17:50:45 +08:00
|
|
|
return -EPROBE_DEFER;
|
2011-01-11 05:11:23 +08:00
|
|
|
|
2016-11-25 02:19:28 +08:00
|
|
|
muxc = i2c_mux_alloc(parent, &pdev->dev, mux->data.n_values,
|
|
|
|
mux->data.n_gpios * sizeof(*mux->gpios) +
|
|
|
|
mux->data.n_gpios * sizeof(*mux->values), 0,
|
2016-04-20 14:39:05 +08:00
|
|
|
i2c_mux_gpio_select, NULL);
|
|
|
|
if (!muxc) {
|
2011-01-11 05:11:23 +08:00
|
|
|
ret = -ENOMEM;
|
2012-10-06 04:23:53 +08:00
|
|
|
goto alloc_failed;
|
2011-01-11 05:11:23 +08:00
|
|
|
}
|
2016-11-25 02:19:28 +08:00
|
|
|
mux->gpios = muxc->priv;
|
|
|
|
mux->values = (int *)(mux->gpios + mux->data.n_gpios);
|
2016-04-20 14:39:05 +08:00
|
|
|
muxc->priv = mux;
|
|
|
|
|
|
|
|
platform_set_drvdata(pdev, muxc);
|
|
|
|
|
i2c: mux: relax locking of the top i2c adapter during mux-locked muxing
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-05-05 04:15:29 +08:00
|
|
|
root = i2c_root_adapter(&parent->dev);
|
|
|
|
|
|
|
|
muxc->mux_locked = true;
|
2016-04-20 14:39:05 +08:00
|
|
|
mux->gpio_base = gpio_base;
|
2011-01-11 05:11:23 +08:00
|
|
|
|
2012-10-26 00:23:53 +08:00
|
|
|
if (mux->data.idle != I2C_MUX_GPIO_NO_IDLE) {
|
|
|
|
initial_state = mux->data.idle;
|
2016-04-20 14:39:05 +08:00
|
|
|
muxc->deselect = i2c_mux_gpio_deselect;
|
2011-01-11 05:11:23 +08:00
|
|
|
} else {
|
2012-10-26 00:23:53 +08:00
|
|
|
initial_state = mux->data.values[0];
|
2011-01-11 05:11:23 +08:00
|
|
|
}
|
|
|
|
|
2012-10-26 00:23:53 +08:00
|
|
|
for (i = 0; i < mux->data.n_gpios; i++) {
|
i2c: mux: relax locking of the top i2c adapter during mux-locked muxing
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-05-05 04:15:29 +08:00
|
|
|
struct device *gpio_dev;
|
|
|
|
struct gpio_desc *gpio_desc;
|
|
|
|
|
2012-10-26 00:23:53 +08:00
|
|
|
ret = gpio_request(gpio_base + mux->data.gpios[i], "i2c-mux-gpio");
|
2013-03-07 06:35:53 +08:00
|
|
|
if (ret) {
|
|
|
|
dev_err(&pdev->dev, "Failed to request GPIO %d\n",
|
|
|
|
mux->data.gpios[i]);
|
2011-01-11 05:11:23 +08:00
|
|
|
goto err_request_gpio;
|
2013-03-07 06:35:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ret = gpio_direction_output(gpio_base + mux->data.gpios[i],
|
|
|
|
initial_state & (1 << i));
|
|
|
|
if (ret) {
|
|
|
|
dev_err(&pdev->dev,
|
|
|
|
"Failed to set direction of GPIO %d to output\n",
|
|
|
|
mux->data.gpios[i]);
|
|
|
|
i++; /* gpio_request above succeeded, so must free */
|
|
|
|
goto err_request_gpio;
|
|
|
|
}
|
i2c: mux: relax locking of the top i2c adapter during mux-locked muxing
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-05-05 04:15:29 +08:00
|
|
|
|
2016-11-25 02:19:28 +08:00
|
|
|
gpio_desc = gpio_to_desc(gpio_base + mux->data.gpios[i]);
|
|
|
|
mux->gpios[i] = gpio_desc;
|
|
|
|
|
i2c: mux: relax locking of the top i2c adapter during mux-locked muxing
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-05-05 04:15:29 +08:00
|
|
|
if (!muxc->mux_locked)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
gpio_dev = &gpio_desc->gdev->dev;
|
|
|
|
muxc->mux_locked = i2c_root_adapter(gpio_dev) == root;
|
2011-01-11 05:11:23 +08:00
|
|
|
}
|
|
|
|
|
i2c: mux: relax locking of the top i2c adapter during mux-locked muxing
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-05-05 04:15:29 +08:00
|
|
|
if (muxc->mux_locked)
|
|
|
|
dev_info(&pdev->dev, "mux-locked i2c mux\n");
|
|
|
|
|
2012-10-26 00:23:53 +08:00
|
|
|
for (i = 0; i < mux->data.n_values; i++) {
|
|
|
|
u32 nr = mux->data.base_nr ? (mux->data.base_nr + i) : 0;
|
|
|
|
unsigned int class = mux->data.classes ? mux->data.classes[i] : 0;
|
2011-01-11 05:11:23 +08:00
|
|
|
|
2016-04-20 14:39:05 +08:00
|
|
|
ret = i2c_mux_add_adapter(muxc, nr, mux->data.values[i], class);
|
2017-04-03 16:14:11 +08:00
|
|
|
if (ret)
|
2011-01-11 05:11:23 +08:00
|
|
|
goto add_adapter_failed;
|
|
|
|
}
|
|
|
|
|
|
|
|
dev_info(&pdev->dev, "%d port mux on %s adapter\n",
|
2012-10-26 00:23:53 +08:00
|
|
|
mux->data.n_values, parent->name);
|
2011-01-11 05:11:23 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
add_adapter_failed:
|
2016-04-20 14:39:05 +08:00
|
|
|
i2c_mux_del_adapters(muxc);
|
2012-10-26 00:23:53 +08:00
|
|
|
i = mux->data.n_gpios;
|
2011-01-11 05:11:23 +08:00
|
|
|
err_request_gpio:
|
|
|
|
for (; i > 0; i--)
|
2012-10-26 00:23:53 +08:00
|
|
|
gpio_free(gpio_base + mux->data.gpios[i - 1]);
|
2011-01-11 05:11:23 +08:00
|
|
|
alloc_failed:
|
|
|
|
i2c_put_adapter(parent);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-11-28 04:59:38 +08:00
|
|
|
static int i2c_mux_gpio_remove(struct platform_device *pdev)
|
2011-01-11 05:11:23 +08:00
|
|
|
{
|
2016-04-20 14:39:05 +08:00
|
|
|
struct i2c_mux_core *muxc = platform_get_drvdata(pdev);
|
|
|
|
struct gpiomux *mux = i2c_mux_priv(muxc);
|
2011-01-11 05:11:23 +08:00
|
|
|
int i;
|
|
|
|
|
2016-04-20 14:39:05 +08:00
|
|
|
i2c_mux_del_adapters(muxc);
|
2011-01-11 05:11:23 +08:00
|
|
|
|
|
|
|
for (i = 0; i < mux->data.n_gpios; i++)
|
2012-10-06 04:23:54 +08:00
|
|
|
gpio_free(mux->gpio_base + mux->data.gpios[i]);
|
2011-01-11 05:11:23 +08:00
|
|
|
|
2016-04-20 14:39:05 +08:00
|
|
|
i2c_put_adapter(muxc->parent);
|
2011-01-11 05:11:23 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-11-28 04:59:38 +08:00
|
|
|
static const struct of_device_id i2c_mux_gpio_of_match[] = {
|
2012-10-26 00:23:53 +08:00
|
|
|
{ .compatible = "i2c-mux-gpio", },
|
|
|
|
{},
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(of, i2c_mux_gpio_of_match);
|
|
|
|
|
2012-04-28 21:32:06 +08:00
|
|
|
static struct platform_driver i2c_mux_gpio_driver = {
|
|
|
|
.probe = i2c_mux_gpio_probe,
|
2012-11-28 04:59:38 +08:00
|
|
|
.remove = i2c_mux_gpio_remove,
|
2011-01-11 05:11:23 +08:00
|
|
|
.driver = {
|
2012-04-28 21:32:06 +08:00
|
|
|
.name = "i2c-mux-gpio",
|
2013-09-30 11:34:25 +08:00
|
|
|
.of_match_table = i2c_mux_gpio_of_match,
|
2011-01-11 05:11:23 +08:00
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2012-04-28 21:32:06 +08:00
|
|
|
module_platform_driver(i2c_mux_gpio_driver);
|
2011-01-11 05:11:23 +08:00
|
|
|
|
|
|
|
MODULE_DESCRIPTION("GPIO-based I2C multiplexer driver");
|
|
|
|
MODULE_AUTHOR("Peter Korsgaard <peter.korsgaard@barco.com>");
|
|
|
|
MODULE_LICENSE("GPL");
|
2012-04-28 21:32:06 +08:00
|
|
|
MODULE_ALIAS("platform:i2c-mux-gpio");
|