On Mon, Oct 15, 2012 at 2:46 PM, Kalle Jokiniemi <kalle.jokiniemi@xxxxxxxxxxxxxxx> wrote: > ma, 2012-10-15 kello 09:21 +0300, Kalle Jokiniemi kirjoitti: >> Hi, >> >> pe, 2012-10-12 kello 14:46 +0000, Strashko, Grygorii kirjoitti: >> > Hi Kevin, >> > >> > yep, [1] is the same fix - thanks. >> > >> > Hi Kalle, >> > >> > i've applied these changes and PM runtime fix on top of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git (omap2plus_defconfig) >> > Could you check it with your use case, pls? (just to be sure that idea is right) >> >> Odd, it's not working. I'll add some debug prints to see what happens >> there. > > Well, seems after enabling irq 23 in the resume_noirq, someone does > i2c_xfer and there is consequent flood of i2c_xfers and interrupts. If there is continuous xfers, you could enable debug LL and see who is queuing the transfers. > > Not sure now how these IRQ numbers get mapped these days, my debug print > says it's irq number 72 (UART1 from TRM) that is flooding (although it's > printed from the i2c-omap isr function, so it's still I2C bus irq...). Can you do a cat /proc/interrupts > > The irq enabling (in resume_noirq) is still slightly progressing after > the flooding starts, but my watchdog kicks in before we get to the > finish. > > Attached my debug prints patch and log. I used also "no_console_suspend" > boot option. > > - Kalle > -- 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
