2019-05-19 21:51:31 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
2010-08-12 00:21:02 +08:00
|
|
|
/*
|
|
|
|
*
|
|
|
|
* i2c-mux.h - functions for the i2c-bus mux support
|
|
|
|
*
|
|
|
|
* Copyright (c) 2008-2009 Rodolfo Giometti <giometti@linux.it>
|
|
|
|
* Copyright (c) 2008-2009 Eurotech S.p.A. <info@eurotech.it>
|
|
|
|
* Michael Lawnick <michael.lawnick.ext@nsn.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef _LINUX_I2C_MUX_H
|
|
|
|
#define _LINUX_I2C_MUX_H
|
|
|
|
|
|
|
|
#ifdef __KERNEL__
|
|
|
|
|
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 <linux/bitops.h>
|
|
|
|
|
2016-04-20 14:38:50 +08:00
|
|
|
struct i2c_mux_core {
|
|
|
|
struct i2c_adapter *parent;
|
|
|
|
struct device *dev;
|
2016-07-10 03:53:42 +08:00
|
|
|
unsigned int mux_locked:1;
|
|
|
|
unsigned int arbitrator:1;
|
|
|
|
unsigned int gate:1;
|
2016-04-20 14:38:50 +08:00
|
|
|
|
|
|
|
void *priv;
|
|
|
|
|
|
|
|
int (*select)(struct i2c_mux_core *, u32 chan_id);
|
|
|
|
int (*deselect)(struct i2c_mux_core *, u32 chan_id);
|
|
|
|
|
|
|
|
int num_adapters;
|
|
|
|
int max_adapters;
|
|
|
|
struct i2c_adapter *adapter[0];
|
|
|
|
};
|
|
|
|
|
|
|
|
struct i2c_mux_core *i2c_mux_alloc(struct i2c_adapter *parent,
|
|
|
|
struct device *dev, int max_adapters,
|
|
|
|
int sizeof_priv, u32 flags,
|
|
|
|
int (*select)(struct i2c_mux_core *, u32),
|
|
|
|
int (*deselect)(struct i2c_mux_core *, u32));
|
|
|
|
|
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
|
|
|
/* flags for i2c_mux_alloc */
|
2016-07-10 03:53:42 +08:00
|
|
|
#define I2C_MUX_LOCKED BIT(0)
|
|
|
|
#define I2C_MUX_ARBITRATOR BIT(1)
|
|
|
|
#define I2C_MUX_GATE BIT(2)
|
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-04-20 14:38:50 +08:00
|
|
|
static inline void *i2c_mux_priv(struct i2c_mux_core *muxc)
|
|
|
|
{
|
|
|
|
return muxc->priv;
|
|
|
|
}
|
|
|
|
|
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 *i2c_root_adapter(struct device *dev);
|
|
|
|
|
2016-04-20 14:38:50 +08:00
|
|
|
/*
|
|
|
|
* Called to create an i2c bus on a multiplexed bus segment.
|
|
|
|
* The chan_id parameter is passed to the select and deselect
|
|
|
|
* callback functions to perform hardware-specific mux control.
|
|
|
|
*/
|
|
|
|
int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
|
|
|
|
u32 force_nr, u32 chan_id,
|
|
|
|
unsigned int class);
|
2010-08-12 00:21:02 +08:00
|
|
|
|
2016-04-20 14:38:50 +08:00
|
|
|
void i2c_mux_del_adapters(struct i2c_mux_core *muxc);
|
2010-08-12 00:21:02 +08:00
|
|
|
|
|
|
|
#endif /* __KERNEL__ */
|
|
|
|
|
|
|
|
#endif /* _LINUX_I2C_MUX_H */
|