Hi, On Thu, Oct 18, 2012 at 09:51:13AM +0300, Kalle Jokiniemi wrote: > ke, 2012-10-17 kello 19:02 +0300, Felipe Balbi kirjoitti: > > Hi, > > > > On Thu, Oct 11, 2012 at 02:08:25PM -0700, Kevin Hilman wrote: > > > Hi Kalle, > > > > > > Kalle Jokiniemi <kalle.jokiniemi@xxxxxxxxxxxxxxx> writes: > > > > > > > The resume_noirq enables interrupts one-by-one starting from > > > > first one. Now if the wake up event for suspend came from i2c > > > > device, the i2c bus irq gets enabled before the threaded > > > > i2c device irq, causing a flood of i2c bus interrupts as the > > > > threaded irq that should clear the event is not enabled yet. > > > > > > > > Fixed the issue by adding suspend_noirq and resume_early > > > > functions that keep i2c bus interrupts disabled until > > > > resume_noirq has run completely. > > > > > > > > Issue was detected doing a wake up from autosleep with > > > > twl4030 power key on N9. Patch tested on N9. > > > > > > > > Signed-off-by: Kalle Jokiniemi <kalle.jokiniemi@xxxxxxxxxxxxxxx> > > > > > > This version looks good, thanks for the extra comments. > > > > > > Reviewed-by: Kevin Hilman <khilman@xxxxxx> > > > Tested-by: Kevin Hilman <khilman@xxxxxx> > > > > > > Wolfram, This should also probably be Cc'd to stable since it affects > > > earlier kernels as well. Thanks, > > > > just to make sure we're not fixing the wrong problem... does [1] help in > > any way ? > > Yes, I was fixing the wrong problem, this patch is obsolete. But the > problem was in the TWL interrupt handling (PIH was run before SIH), not > in i2c. See my other patch "twl4030: Fix chained irq handling on resume > from suspend" > > > > > [1] http://marc.info/?l=linux-omap&m=135048839915719&w=2 > > > > Could be related, though if I understood correctly, that runtime pm > stuff gets run at noirq phase, so it probably does not help. well, it will be called multiple times actually :-) Since i2c is forcefully suspend in noirq time, it suspends before e.g. rtc, twl*-gpio, etc, which means that (at least for) rtc will still do i2c transfers on its suspend callback which will runtime resume the i2c controller and later suspend it again :-) You might be right, however, that it won't help in your case. cheers -- balbi
Attachment:
signature.asc
Description: Digital signature
