Kevin,
> -----Original Message-----
> From: Kevin Hilman
>
> "Sonasath, Moiz" <m-sonas...@ti.com> writes:
>
> > This patch includes the workarround for I2C Errata 1.153:
[...]
> > +static int omap_i2c_wait_for_xudf(struct omap_i2c_dev *dev)
> > +{
> > + u16 xudf;
> > + int counter = 500;
> > +
> > + /* We are in interrupt context. Wait for XUDF for max 7 msec */
>
> What does being in interrupt context have to do with how long you
> wait? Threaded interrupts are now in mainline and will become the
> default, so this ISR may run in thread context.
The interrupt context comment was meant to say that we can't sleep. Perhaps,
with threaded interrupts that might not be true (I am not sure). We can remove
the interrupt context comment.
> > @@ -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.
Regards,
Nishant
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
