I2C from interrupt context?
Hi,
I'm updating my EEPROM console logger and have encountered a problem
- the logger (as any console) can be called with hardware interrupts disabled and/or from interrupt context. It needs to write to I^2C (using ARM (Xscale) GPIO) and possibly SMBUS-only EEPROM chip. Is it at all supposed to be possible?
Signature · 1 line
Krzysztof Halasa
From: Krzysztof Halasa <khc-9GfyWEdoJtJmR6Xm/[email protected]>
Date: Fri, 07 Nov 2008 00:44:48 +0100
[ Fixed i2c list address, it's now hosted at vger ]
Quoted 5 lines
I'm updating my EEPROM console logger and have encountered a problem
- the logger (as any console) can be called with hardware interrupts disabled and/or from interrupt context. It needs to write to I^2C (using ARM (Xscale) GPIO) and possibly SMBUS-only EEPROM chip. Is it at all supposed to be possible?
Not really. The I2C operations need to be able to sleep and that's not allowed in interrupt context.
Quoted 5 lines · David Miller
From: Krzysztof Halasa <khc-9GfyWEdoJtJmR6Xm/[email protected]>
Date: Fri, 07 Nov 2008 00:44:48 +0100[ Fixed i2c list address, it's now hosted at vger ]
Quoted 8 lines
Quoted 5 lines
I'm updating my EEPROM console logger and have encountered a problem
- the logger (as any console) can be called with hardware interrupts disabled and/or from interrupt context. It needs to write to I^2C (using ARM (Xscale) GPIO) and possibly SMBUS-only EEPROM chip. Is it at all supposed to be possible?Not really. The I2C operations need to be able to sleep and that's not allowed in interrupt context.
That's not totally correct. Since kernel 2.6.25, i2c_transfer() supports being called in contexts where it cannot sleep. Of course, for it to work, the underlying i2c adapter driver must also not sleep. As I recall, only the i2c-pxa driver was explicitly modified to support this at the moment (see member use_pio of struct pxa_i2c) but other drivers could be modified in a similar way (and some i2c adapter drivers may be naturally non-sleeping - everything based on i2c-algo-bit is likely to fall into this category.)
The situation is far from perfect though. For one thing, I seem to recall that Andrew Morton didn't like the approach taken in i2c_transfer(). For another, i2c_smbus_xfer() was not yet modified so at this point only I2C-level transactions can be non-sleeping, SMBus-level transactions can't. But all this could be fixed by anyone who cares about these specific issues.
Signature · 1 line
Jean Delvare
Quoted 6 lines · Jean Delvare
The situation is far from perfect though. For one thing, I seem to recall that Andrew Morton didn't like the approach taken in
i2c_transfer(). For another,i2c_smbus_xfer()was not yet modified so at this point only I2C-level transactions can be non-sleeping, SMBus-level transactions can't. But all this could be fixed by anyone who cares about these specific issues.
Thanks, I'll look at it.
Signature · 1 line
Krzysztof Halasa
Quoted 10 lines · On Fri, 07 Nov 2008 17:05:35 +0100 Krzysztof Halasa…
Quoted 6 lines · Jean Delvare
The situation is far from perfect though. For one thing, I seem to recall that Andrew Morton didn't like the approach taken in
i2c_transfer(). For another,i2c_smbus_xfer()was not yet modified so at this point only I2C-level transactions can be non-sleeping, SMBus-level transactions can't. But all this could be fixed by anyone who cares about these specific issues.Thanks, I'll look at it.
The problem (well: bug) is that in_atomic() returns false inside a spinlock when CONFIG_PREEMPT=n. The code as it stands can sleep inside a spinlock, which is deadlockable if a scheduled-to task tries to take the same spinlock.
There is no means like this by which a piece of code can determine whether it can call schedule(). The pattern which we use in many many places (most especially GFP_KERNEL/GFP_ATOMIC) is to pass a flag down to callees telling them in some manner which context they were called from.