I2C from interrupt context? - Kernel

This is a discussion on I2C from interrupt context? - Kernel ; 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: I2C from interrupt context?

  1. 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?
    --
    Krzysztof Halasa
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: I2C from interrupt context?

    From: Krzysztof Halasa
    Date: Fri, 07 Nov 2008 00:44:48 +0100

    [ Fixed i2c list address, it's now hosted at vger ]

    > 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.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: I2C from interrupt context?

    On Thu, 06 Nov 2008 15:47:54 -0800 (PST), David Miller wrote:
    > From: Krzysztof Halasa
    > Date: Fri, 07 Nov 2008 00:44:48 +0100
    >
    > [ Fixed i2c list address, it's now hosted at vger ]
    >
    > > 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.

    --
    Jean Delvare
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: I2C from interrupt context?

    Jean Delvare writes:

    > 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.
    --
    Krzysztof Halasa
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: I2C from interrupt context?

    On Fri, 07 Nov 2008 17:05:35 +0100 Krzysztof Halasa wrote:

    > Jean Delvare writes:
    >
    > > 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.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread