Re: [PATCH v3] ARM: OMAP: i2c: fix interrupt flood during resume

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux