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

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

[Stephane Grosjean]

Hi,

I'm facing a deadlock regarding a timer callback which is only calling 
i2c_transfer(), and I wonder if this comes from that call: I first 
googled and found that i2c_transfer() may sleep (which is forbidden in 
my timer callback) but when I have a look the beginning of the function, 
it starts to check if it is in any atomic context, before trying to 
acquire  a lock...

So I'm afraid I'm lost and I hope someone will be able to understand to 
that question: might i2c_transfer() be used in a timer callback or 
should I handle my periodic call to i2c_tranfer() by means of a delayed 
work?

Thanks for your reply,

Regards,

Stéphane

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

[Jean Delvare]

Bonjour Stéphane,

On Mon, 20 Feb 2012 14:01:52 +0100, Stephane Grosjean wrote:
> I'm facing a deadlock regarding a timer callback which is only calling 
> i2c_transfer(), and I wonder if this comes from that call: I first 
> googled and found that i2c_transfer() may sleep (which is forbidden in 
> my timer callback) but when I have a look the beginning of the function, 
> it starts to check if it is in any atomic context, before trying to 
> acquire  a lock...
> 
> So I'm afraid I'm lost and I hope someone will be able to understand to 
> that question: might i2c_transfer() be used in a timer callback or 
> should I handle my periodic call to i2c_tranfer() by means of a delayed 
> work?

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. So if you want your code to be portable, you have to
assume that it may sleep, which means you indeed have to use a delayed
work.

HTH,
-- 
Jean Delvare

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

[Stephane Grosjean]

Merci Jean,

Thx for the quick answer. I think this will help.

Stéphane

Le 20/02/2012 14:11, Jean Delvare a écrit :
> Bonjour Stéphane,
>
> On Mon, 20 Feb 2012 14:01:52 +0100, Stephane Grosjean wrote:
>> I'm facing a deadlock regarding a timer callback which is only calling
>> i2c_transfer(), and I wonder if this comes from that call: I first
>> googled and found that i2c_transfer() may sleep (which is forbidden in
>> my timer callback) but when I have a look the beginning of the function,
>> it starts to check if it is in any atomic context, before trying to
>> acquire  a lock...
>>
>> So I'm afraid I'm lost and I hope someone will be able to understand to
>> that question: might i2c_transfer() be used in a timer callback or
>> should I handle my periodic call to i2c_tranfer() by means of a delayed
>> work?
> 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. So if you want your code to be portable, you have to
> assume that it may sleep, which means you indeed have to use a delayed
> work.
>
> HTH,

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

[Jean Delvare]

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