diff mbox

I2C: Call request_irq with IRQF_DISABLED

Message ID 1236261264-16053-1-git-send-email-Ext-Ari.Kauppi@nokia.com (mailing list archive)
State Superseded, archived
Headers show

Commit Message

Ari Kauppi March 5, 2009, 1:54 p.m. UTC
I have observed some Spurious IRQ's for I2C1 when all kernel hacking options
(and thus LOCKDEP) are disabled.

Applying Richard Woodruff's 'I2C bug fixes for L-O and L-Z' seems to help
but IRQF_DISABLED is needed for proper behaviour.

Signed-off-by: Ari Kauppi <Ext-Ari.Kauppi@nokia.com>
---
 drivers/i2c/busses/i2c-omap.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Comments

Felipe Balbi March 5, 2009, 7:35 p.m. UTC | #1
On Thu, Mar 05, 2009 at 03:54:24PM +0200, Ari Kauppi wrote:
> I have observed some Spurious IRQ's for I2C1 when all kernel hacking options
> (and thus LOCKDEP) are disabled.
> 
> Applying Richard Woodruff's 'I2C bug fixes for L-O and L-Z' seems to help
> but IRQF_DISABLED is needed for proper behaviour.
> 
> Signed-off-by: Ari Kauppi <Ext-Ari.Kauppi@nokia.com>

This driver should be in sync with mainline, the only missing commit is

commit 3487568e15df6e133f5f55779dec614dbeb68a99
Author: Eero Nurkkala <ext-eero.nurkkala@nokia.com>
Date:   Tue Nov 25 13:03:46 2008 +0200

    i2c: i2c-omap: Fix BUFSTAT_REG reading
    
    The number of bytes to be received is read from wrong
    place with all OMAPs with highspeed I2C support,
    which involves a FIFO and BUFSTAT_REG. It is the 6
    bits starting from the bit 8 in the BUFSTAT_REG
    that indicate this amount of bytes to be read.
    Moreover, only the 6 LSB:s are relevant for the
    TXSTAT field.
    
    Signed-off-by: Eero Nurkkala <ext-eero.nurkkala@nokia.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>

That and this one should be going via linux-i2c mainling list. Could you
send Eero's patch and yours to Jean Delvare (i2c maintainer) ? Please
keep linux-omap in the loop.

That said, this makes sense and avoids that we get interrupts while
handling a previous interrupt.

Acked-by: Felipe Balbi <felipe.balbi@nokia.com>
Jean Delvare March 5, 2009, 8:03 p.m. UTC | #2
On Thu, 5 Mar 2009 21:35:06 +0200, Felipe Balbi wrote:
> That and this one should be going via linux-i2c mainling list. Could you
> send Eero's patch and yours to Jean Delvare (i2c maintainer) ? Please
> keep linux-omap in the loop.

Come on, folks, how many times will I have to repeat myself and what
MAINTAINERS says? Patches to i2c-omap and every other i2c driver for
embedded platforms go to Ben Dooks (Cc'd), not me.
Felipe Balbi March 5, 2009, 8:15 p.m. UTC | #3
On Thu, Mar 05, 2009 at 09:03:35PM +0100, Jean Delvare wrote:
> On Thu, 5 Mar 2009 21:35:06 +0200, Felipe Balbi wrote:
> > That and this one should be going via linux-i2c mainling list. Could you
> > send Eero's patch and yours to Jean Delvare (i2c maintainer) ? Please
> > keep linux-omap in the loop.
> 
> Come on, folks, how many times will I have to repeat myself and what
> MAINTAINERS says? Patches to i2c-omap and every other i2c driver for
> embedded platforms go to Ben Dooks (Cc'd), not me.

that was my bad, I didn't see Ben was already in Cc.
diff mbox

Patch

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0c3ed41..18af43f 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -847,7 +847,7 @@  omap_i2c_probe(struct platform_device *pdev)
 	omap_i2c_init(dev);
 
 	isr = (dev->rev < OMAP_I2C_REV_2) ? omap_i2c_rev1_isr : omap_i2c_isr;
-	r = request_irq(dev->irq, isr, 0, pdev->name, dev);
+	r = request_irq(dev->irq, isr, IRQF_DISABLED, pdev->name, dev);
 
 	if (r) {
 		dev_err(dev->dev, "failure requesting irq %i\n", dev->irq);