Hi Bill, On Mon, 20 Feb 2012 07:46:07 -0600, Bill Gatliff wrote: > On Feb 20, 2012 7:11 AM, "Jean Delvare" <khali@xxxxxxxxxxxx> wrote: > > On Mon, 20 Feb 2012 14:01:52 +0100, Stephane Grosjean wrote: > > > I'm facing a deadlock regarding a timer callback... > > > > Depends on the underlying I2C adapter driver. One of the sleep causes > > is indeed the acquisition of the mutex in i2c_transfer(). However the > > function then calls a driver specific callback function > > (adap->algo->master_xfer) which may or may not sleep too depending on > > the implementation. > > Indeed. A fair number of the i2c transfer functions I have encountered call > schedule_work() or equivalent, and/or wait_for_completion(). Or even plain msleep(). > The low-level transfer function implementations are entirely > platform-dependent, and often lean heavily on the assumption that they > aren't called in atomic contexts. So in addition to driving architecture > decisions in your code which calls them, they can also have implications > for real-time performance. > > None of the above is a complaint, mind you. Just observations. :) I certainly hope you wouldn't dare to complain without also submitting a proposal and a patch set addressing any issue you have ;) -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
