My first post in to the mailing list.
Deep power idle state is nothing but CPU power domain off. Its not impossible but would require some hw change.
If kernel is aware of a CPU being in power off state, can we first do a CPU wakeup before issuing SGI. The wakeup routine has to be implemented by SoC provider as it will be different for each vendor.
Regds Shakti
Sent from my Nokia Lumia 920 ________________________________ From: Santosh Shilimkarmailto:santosh.shilimkar@ti.com Sent: 2/26/2013 10:00 PM To: Daniel Lezcanomailto:daniel.lezcano@linaro.org Cc: jacob.jun.pan@linux.intel.commailto:jacob.jun.pan@linux.intel.com; Russell King - ARM Linuxmailto:linux@arm.linux.org.uk; linus.walleij@stericsson.commailto:linus.walleij@stericsson.com; linux-pm@vger.kernel.orgmailto:linux-pm@vger.kernel.org; viresh.kumar@linaro.orgmailto:viresh.kumar@linaro.org; patches@linaro.orgmailto:patches@linaro.org; linux-kernel@vger.kernel.orgmailto:linux-kernel@vger.kernel.org; linaro-kernel@lists.linaro.orgmailto:linaro-kernel@lists.linaro.org; linux-arm-kernel@lists.infradead.orgmailto:linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 0/4] time: dynamic irq affinity
On Wednesday 27 February 2013 03:47 AM, Daniel Lezcano wrote:
When a cpu goes to a deep idle state where its local timer is shutdown, it notifies the time framework to use the broadcast timer instead.
Unfortunately, the broadcast device could wake up any CPU, including an idle one which is not concerned by the wake up at all.
This implies, in the worst case, an idle CPU will wake up to send an IPI to another idle cpu.
This patch solves this by setting the irq affinity to the cpu concerned by the nearest timer event, by this way, the CPU which is wake up is guarantee to be the one concerned by the next event and we are safe with unnecessary wakeup for another idle CPU.
As the irq affinity is not supported by all the archs, a flag is needed to specify which clocksource can handle it.
Not completely related to this series but there is another issue where this local timer not wakeup capable hurts. So far we are discussing only the timer related future events which are known and can be programmed with broadcast device.
But think of the scenario's where we need to send asynchronous IPIs to CPUs to do some work. e.g generic_exec_single(). If the CPU which is suppose to be available after IPI call is in deep low power state, then the IPI(implemented on ARM) isn't effective. In CPU off idle modes, a GIC SGI will not wake the CPU and hence a special wakeup is needed to bring out those CPUs out of idle. This special wakeup is handled by broad-cast timer in case of CPUIDLE.
In short what I mean is, you need to have IPI which can wakeup CPUs from any deep idle power state to address above. Has anybody thought of this one ?
Regards, Santosh P.S: Time and again it proves that making the local timer wakeup capable solves the issue.
_______________________________________________ linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel