Premi, Sanjeev wrote:
-----Original Message-----
From: linux-omap-owner@xxxxxxxxxxxxxxx
[mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Premi, Sanjeev
Sent: Tuesday, March 03, 2009 3:54 PM
To: Kevin Hilman
Cc: linux-omap@xxxxxxxxxxxxxxx
Subject: RE: omap3 cpuidle interrupt latency
-----Original Message-----
From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, March 03, 2009 1:16 AM
To: Premi, Sanjeev
Cc: linux-omap@xxxxxxxxxxxxxxx
Subject: Re: omap3 cpuidle interrupt latency
"Premi, Sanjeev" <premi@xxxxxx> 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.
IIUC, the keypad interrupts are making it all the way to the kernel, but
the touchscreen ones are not, correct?
What happens if you enable IRQ wakeups for the TS interrupt?
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
