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,
--
PEAK-System Technik GmbH, Otto-Roehm-Strasse 69, D-64293 Darmstadt
Geschaeftsleitung: A.Gach/U.Wilhelm,St.Nr.:007/241/13586 FA Darmstadt
HRB-9183 Darmstadt, Ust.IdNr.:DE 202220078, WEE-Reg.-Nr.: DE39305391
Tel.+49 (0)6151-817320 / Fax:+49 (0)6151-817329, info@xxxxxxxxxxxxxxx
----
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
