On Wed, Jan 23, 2013 at 12:23:04PM +0200, Felipe Balbi wrote: > In case we loop on IRQ handler until stat is > finally zero, we would end up in a situation > where all I2C transfers would misteriously > timeout because we were not calling complete() > in that situation. This is wrong, you may still have bytes to transfer, but a new interrupt has not arrived yet. This patch also breaks bisection; if you just apply patches 1-2 of this series the I2C does not work at all. > Fix the issue by moving omap_i2c_complete_cmd() > call inside the 'out' label. > > Signed-off-by: Felipe Balbi <balbi@xxxxxx> > --- > drivers/i2c/busses/i2c-omap.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > index be8c591..53985b4 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -1022,9 +1022,8 @@ omap_i2c_isr_thread(int this_irq, void *dev_id) > } > } while (stat); > > - omap_i2c_complete_cmd(dev, err); > - > out: > + omap_i2c_complete_cmd(dev, err); > spin_unlock_irqrestore(&dev->lock, flags); > > return IRQ_HANDLED; > -- > 1.8.1.rc1.5.g7e0651a > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
