On Sat, Jan 08, 2011 at 08:58:57AM -0800, Abhijeet Dharmapurikar wrote: > > I am trying to address an issue of not handling a wakeup interrupt quick > enough while resuming. It is an edge triggered interrupt with the > IRQ_WAKEUP flag set. The interrupt controller implements lazy disabling > of interrupts, IOW does not have a disable callback in the irq_chip. > > So while going in to supend that interrupt is marked IRQ_DISABLED in > dpm_suspend_noirq(). > > On resume handle_edge_trigger is run right after > arch_suspend_enable_irqs(). It finds the interrupt marked IRQ_DISABLED > and it sets the IRQ_PENDING flag and does not call the handler. > > As the resume path unrolls, non boot cpus are enabled, > dpm_resume_noirq() is run. At that time it finds the IRQ_PENDING flag is > set on this interrupt and the interrupt handler is run. The reason it's after non-boot CPUs are enabled is that the affinity settings may require it to be run on one of these CPUs, so we need to ensure that those CPUs are up. We know it takes something like 200ms to run the lpg calibration, and this is responsible for the majority of the time when bringing a CPU online. One solution is to sort out whether we need to re-run the lpj calibration each time we resume a CPU. At the moment, we're just using the boot CPU loops_per_jiffy for every udelay(), assuming that all CPUs are running at the same clock rate - so we _could_ skip the calibration as its never used. Or we could fix things so that it is used (which also sorts udelay for asymetrically clocked secondary CPUs) but then we always have to re-run the calibration, or we have to stipulate that secondary CPUs come up at the same clock rate as they went down. I suspect there's systems out there where the latter is not true at present, so it's not something we can impose - which means we're stuck having to do 200ms of recalibration per CPU. Another solution is to check whether we can run the handler before other CPUs are online - it may mean we're breaking IRQ affinity, but any non-boot affinity has already been broken by taking the other CPUs offline. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
