Hi

On Mon, 15 Oct 2012, Felipe Balbi wrote:

On Mon, Oct 15, 2012 at 01:51:08AM +0000, Paul Walmsley wrote:

quoted

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