Hi,
I have examined "cpuidle" procedure for ARM JUNO board with different idle states. My question is related to idle states which will cause the CPU core to suspend itself. I am familiar with properties under "idle-state" device tree node.
Example below.
taken from linux dts file [juno.dts]
based on commit: 102340
Date: Wed Mar 18 17:17:13 2015 +0000
arm64: dts: Add idle-states for Juno
Signed-off-by: Jon Medhurst <tixy@linaro.org>
from JUNO linux-kernel repository
So, Linux will at some point (when it satisfies all the latencies above) call PSCI suspend function, with "psci-suspend-param" as an argument.. That will propagate to the ATF (EL3) software layer and at the end will notify PMU (Cortex M3) to set new power state for the particular core. (scpi_set_css_power_state(..)).
But before invoking that call, all interrupts (at GIC level) are disabled.
"
arm_gic_cpuif_deactivate();
So, I am wondering, how Linux will wake-up core again? All interrupts are disabled.
Thanks,
A.
I'm not 100% sure if I've understood your question correctly, but I'll have a bash.
When all A class core are asleep. The GIC can be configured so that incoming interrupts (which would originally have been destined for A class cores) cause wake up events. These wake up events ignore the CPU interface enable bits. Search for (nIRQOUT) in the GIC-400 TRM. http://infocenter.arm.com/help/topic/com.arm.doc.ddi0471b/DDI0471B_gic400_r0p1_trm.pdf
These wake up signals nIRQOUT (0..5 on Juno there's a separate signal per core) can be routed to the NVIC (interrupt controller) managed by the Cortex-M3 which can wake up the A class core allowing it to service the original interrupt.
MarkN.
Thanks Mark,
It makes sense..
Cheers,A.