On Tue, Jan 05, 2016 at 04:57:18PM +0100, Peter Rosin wrote: > From: Peter Rosin <peda@xxxxxxxxxx> > > With a i2c topology like the following > > GPIO ---| ------ BAT1 > | v / > I2C -----+----------+---- MUX > | \ > EEPROM ------ BAT2 Yuck. One would think you would just use an I2C controlled mux in this case... > 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). > > Add devive tree properties (bool named i2c-controlled) to i2c-mux-gpio and > i2c-mux-pinctrl that asserts that the the gpio/pinctrl is controlled via > the same i2c bus that it muxes. Can't you determine this condition by checking the mux parent and gpio parent are the same i2c controller? Alternatively, can't you just always do the locking like i2c-controlled is set when a mux is involved? What is the harm in doing that if the GPIO is controlled somewhere else? I would prefer to see a solution not requiring DT updates to fix and this change seems like it is working around kernel issues. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
