ma, 2012-10-15 kello 15:41 +0530, Shubhrajyoti Datta kirjoitti:
> On Mon, Oct 15, 2012 at 2:46 PM, Kalle Jokiniemi
> <kalle.jokini...@jollamobile.com> 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

Yes :)

[root@localhost proc]# cat
interrupts                                          

CPU0                                                                 
 20:          0      INTC  gpmc
 23:          2      INTC  TWL4030-PIH
 25:          0      INTC  l3-debug-irq
 26:          0      INTC  l3-app-irq
 28:      48157      INTC  DMA
 40:          0      INTC  omap-iommu.0
 52:          0      INTC  dsp_wdt
 53:     807807      INTC  gp_timer
 65:          0      INTC  omap-sham
 72:       5490      INTC  omap_i2c
 73:         85      INTC  omap_i2c
 77:          0      INTC  omap_i2c
 90:       1069      INTC  OMAP UART2
102:      55940      INTC  mmc0
179:       6142      GPIO  omap2-onenand
306:      44666      PRCM  pm_wkup
315:          4      PRCM  hwmod_io, pm_io
338:          0   twl4030  twl4030_gpio
343:          2   twl4030  twl4030_power
346:          0   twl4030  twl4030_pwrbutton
348:          2   twl4030  twl4030_usb
349:          0   twl4030  rtc0

Hmm, I did not notice that PIH handler before, makes sense now that it
triggers the flood (irq 23) as it is really the one that passes the
interrupts to other handlers.

- Kalle

> 
> 
> >
> > 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to