> -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > owner@xxxxxxxxxxxxxxx] On Behalf Of Premi, Sanjeev > Sent: Monday, March 02, 2009 1:31 AM > To: Dasgupta, Romit; Woodruff, Richard; linux-omap@xxxxxxxxxxxxxxx > Subject: RE: omap3 cpuidle interrupt latency > > > -----Original Message----- > > From: Dasgupta, Romit > > Sent: Sunday, March 01, 2009 12:18 PM > > To: Woodruff, Richard; Premi, Sanjeev; linux-omap@xxxxxxxxxxxxxxx > > Subject: RE: omap3 cpuidle interrupt latency > > > > It would be nice if this device could dynamically set > > constraints (say by using a short kernel timer during > > activity or set/remove pm_qos latency) or the prediction > > aspect of cpuidle could be improved using rules feed from > > things like interrupt source. > > Despite all constraints; the latency concern is still valid. > > The constraints would either prevent idle state transition; > or in the idle processing we could still have repeat of current > situation - though less often. > > I feel checking for pending interrupt before executing WFI > would help. Will try in the morning. Moving time keeping functions out of interrupt disabled context may also help. Something like this return_sleep_time: local_irq_enable(); local_fiq_enable(); getnstimeofday(&ts_postidle); ts_idle = timespec_sub(ts_postidle, ts_preidle); ARM will wakeup from WFI idle on nIRQ/nFIQ signal assertion. But interrupts will be processed only after they are enabled in CPSR AFAIK. Regards, Pratheesh -- 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
