lkml.org 
[lkml]   [2016]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 8/8] i2c-mux: relax locking of the top i2c adapter during i2c controlled muxing
On Tue, Jan 05, 2016 at 04:57:18PM +0100, Peter Rosin wrote:
> From: Peter Rosin <peda@axentia.se>
>
> 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


\
 
 \ /
  Last update: 2016-01-06 16:01    [W:0.569 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site