Re: Questions about i2c_transfer() usage in timer context...

[Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>]

Hi Bill,

On Mon, 20 Feb 2012 07:46:07 -0600, Bill Gatliff wrote:
> On Feb 20, 2012 7:11 AM, "Jean Delvare" <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org> 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