On Thu, 2009-03-12 at 01:04 +0100, ext Paul Walmsley wrote: Hi Paul, > On Wed, 11 Mar 2009, Paul Walmsley wrote: > > > > On Fri, Mar 06, 2009 at 03:34:54PM +0200, Ari Kauppi wrote: > > > > I have observed some Spurious IRQ's for I2C1 when all kernel hacking options > > > > (and thus LOCKDEP) are disabled. > > > > Ari, are you seeing "Spurious irq XX: XXXXXXXX, please flush posted write > > for irq" messages? If so, the correct fix for this is to read from the > > device interrupt status register immediately after writing to it. This > > forces the ARM to wait until the write to the device is complete. Ari, > > could you make this change to i2c-omap.c:omap_i2c_isr() instead, and test > > whether this fixes the problem? > > > > + u32 tmp; > > > > ... > > > > omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat); > > + tmp = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); /* OCP barrier */ > > You'll also want to make a similar change in omap_i2c_ack_stat(), to add a > read immediately after that write. I was seeing some Spurious irq's for the I2C1 (IRQ 56). I'm aware of flushing posted write and the very first thing I tried was to use read-after-write for OMAP_I2C_STAT_REG (in all applicable places). However, it didn't make any difference. Applying Richard Woodruff's patch (mentioned earlier in thread) that disables dev->b_hw hack for 3430 (STT/STP bits written together) and double clears ARDY fixed the spurious IRQ issues for I2C1. However, with the STT/STP+ARDY patch I was seeing Spurious interrupts all over the place and the IRQF_DISABLED in i2c-omap seemed to tame them quite well. I do agree that my approach might not be the proper one in long term. Best regards, -- Ari -- 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
