Hi
On Mon, 15 Oct 2012, Felipe Balbi wrote:
> On Mon, Oct 15, 2012 at 01:51:08AM +0000, Paul Walmsley wrote:
> >
> > Commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde ("i2c: omap: switch to
> > threaded IRQ support") causes communication with I2C devices to fail
> > after system suspend/resume on all OMAP3 devices:
> >
> > ...
> > [ 40.228576] PM: noirq resume of devices complete after 3.723 msecs
> > [ 40.233184] PM: early resume of devices complete after 3.173 msecs
> > [ 40.242736] [sched_delayed] sched: RT throttling activated
> > [ 41.235046] omap_i2c omap_i2c.1: controller timed out
>
> instead of just reverting the patch, I'd rather try to figure out why
> controller times out in that situation.
>
> It should make no difference if you're running an IRQ thread or not.
>
> Do you have any extra debugging information which might help figuring
> out what the issue really is ?
As mentioned, the problem can be easily reproduced on OMAP3 is test by
running
"echo mem > /sys/power/state"
in userspace when rootfs is on MMC. Then wake up out of suspend, for
example, by hitting ENTER on the serial console.
This needs to be part of the testing before any OMAP patches are posted to
the lists -- if for no other reason than because Android kernels enter and
exit system suspend frequently as part of their standard usage model.
> If the thread is actually at fault, then we need to add IRQF_NO_THREAD
> to the IRQ flags, otherwise same issue will appear if we boot with
> "threadirqs" kernel parameter.
...
> but it fails because I2C times out and I'd like to understand why,
> before just reverting the patch.
It doesn't matter to me how it's fixed as long as it's fixed quickly
during the early 3.7-rcs.
- Paul
--
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
