> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Premi, Sanjeev
> Sent: Tuesday, March 03, 2009 3:54 PM
> To: Kevin Hilman
> Cc: [email protected]
> Subject: RE: omap3 cpuidle interrupt latency
>
> > -----Original Message-----
> > From: Kevin Hilman [mailto:[email protected]]
> > Sent: Tuesday, March 03, 2009 1:16 AM
> > To: Premi, Sanjeev
> > Cc: [email protected]
> > Subject: Re: omap3 cpuidle interrupt latency
> >
> > "Premi, Sanjeev" <[email protected]> writes:
> >
> > > I have noticed large interrupt latency when the cpuidle
> is enabled.
> > > e.g. response time for ping goes from avg 10-20ms to 800-1000ms.
> > > (I am at HEAD of the 'pm' branch)
> >
> > Is it interrupt latency in general you are measuring? or just the
> > interrupt latency for the smc network driver. I think what you are
> > seeing is the result of the SMC IRQ not being configured as
> a wakeup
> > source, thus a network interrupt will not wake the system,
> but you end
> > up waiting for the next idle timer until the system wakes
> and handles
> > the network interrupt.
>
> I used SMC as an example. The read over USB is also slow...
>
> I feel there is generic latency. Initially, I was suspecting
> the hrtimer functions taking long time. But that may not be the case.
>
> >
> > By default, I don't believe the GPIO interrupt used by the smc is
> > configured as a wakeup source. Have you configured that GPIO as a
> > wakeup source?
>
> My current measurements are based with all idle related flags
> 'sleep_while_idle', 'clocks_off_while_idle' and 'enable_off_mode'
> set at 0.
>
> Does WFI require a wakeup event? Even when system is not in
> 'off' stare?
For simple debug, I replaced the _omap_sram_idle() processing with:
__asm__ ("dmb");
__asm__ ("dsb");
__asm__ ("wfi");
Here, again behavior was same for ethernet.
For more simplification, I focused on keypad and touchscreen.
1) Let the system stay idle for about 10secs
2) Press the keypad & tap the touchscreen
3) cat /proc/interrupts
While the keypad interrupts (via SYS_NIRQ) are getting updated;
most of the TS interrupts (via GPIO) seem to be missing; With a
busy loop in the background OR _omap_sram_idle() commented - not
doing WFI - changes the behavior. Each tap on the TS is registered
in /proc/interrupts.
>
> ~sanjeev
>
> >
> > Kevin
> >
> >
> > > The IRQs and FIQs are disabled at the beginning of the function
> > > omap3_enter_idle() but WFI is executed much later in
> > _omap_sram_idle().
> > > In between, there is only one check for pending IRQs -
> > > omap_irq_pending()
> > >
> > > If any interrupt occurs beyond this point is it considered
> > by the WFI?
> > >
> > > To reduce this latency, I am planning to do either/both of thse:
> > > - Add more checks for pending IRQs
> > > - Reduce the time for which the IRQs and FIQs are disabled
> > >
> > > Benefits will depend upon the behavior of WFI.
> > >
> > > Best regards,
> > > Sanjeev
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe
> > linux-omap"
> > > in the body of a message to [email protected] More
> > majordomo
> > > info at http://vger.kernel.org/majordomo-info.html
> >
> > --
> To unsubscribe from this list: send the line "unsubscribe
> linux-omap" in the body of a message to
> [email protected] More majordomo info at
> http://vger.kernel.org/majordomo-info.html
>
> --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
