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