> -----Original Message----- > From: [email protected] [mailto:linux-omap- > [email protected]] On Behalf Of Kamat, Nishant > Sent: Tuesday, June 23, 2009 12:55 PM > > > > @@ -647,7 +679,7 @@ omap_i2c_isr(int this_irq, void *dev_id) > > > while ((stat = (omap_i2c_read_reg(dev, > > OMAP_I2C_STAT_REG))) & bits) { > > > dev_dbg(dev->dev, "IRQ (ISR = 0x%04x)\n", stat); > > > if (count++ == 100) { > > > - dev_warn(dev->dev, "Too much work in > > one IRQ\n"); > > > + dev_dbg(dev->dev, "Too much work in one IRQ\n"); > > > > Should stay as dev_warn I think. > > > > When I2C is used to transfer a large number of bytes continuously (e.g. > during some camera sensor firmware update), we hit the max count more > often now (because of the delay introduced by the workaround > implementation). In this case, its undesirable to see the dev_warn > messages fill up the console. Changing this to dev_dbg means that this > message is not printed in the expected case. Just wondering on this -> cant I do a multibyte write upto 255 bytes? Is count==100 not enough given that we used buffered writes? The real question is this: Are devices expected to trigger retry logic to the extent where the error condition is triggered?
I think this might be an indication of something else being at fault with the sensor /configuration of sensor - hiding the error messages by moving warn->dbg is not correct IMHO. Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
