On Fri, Apr 19, 2013 at 10:34:39PM +0100, Nicolas Pitre wrote:
[ Looping in Achin and Lorenzo ]
On Fri, 19 Apr 2013, Leo Yan wrote:
hi Nico & all,
We are do some profiling on TC2 board for low power mode, and found there have some long latency for the core/cluster's power on sequence, so want to confirm below questions:
- From our profiling result, we found if the core_A send IPI to core_B and
the core_B run into the function bL_entry_point (or the function mcpm_entry_point in your later patches for mainline) will take about 954us, it's really a long interval.
Is core_B in a different cluster than core_A? It is a known fact that powering up a cluster has far greater latency than simply pulling a core out of reset.
Now we use the firmware is 13.01's version (with has supported BX_ADDRx registers); so the cluster level's power on sequence should be: a) DCC to detect the nIRQOUT/nFIQOUT asserting; b) DCC power on the according cluster; c) the core run into boot monitor code and finally it will use the BX_ADDRx register to jump to the function *bL_entry_point*;
Due upper flows are black box for us, so we suspect the time will be consumed by one of these steps; could u or ARM guys can help confirm this question?
Those steps are a black box to me as well. I'll let the ARM guys answer your questions.
b) is what takes time to allow voltage to become stable.
Also remember that there might be an ongoing DVFS request for the other cluster and DVFS/power up are inherently serialized by the power controller, so you should expect a degree of variability on that.
- When we read the spec DAI0318D_v2p_ca15_a7_power_management.pdf and get
confirm from ARM support, we know there only have cluster level's power down with CA15_PWRDN_EN/CA7_PWRDN_EN bits.
For the core level, we can NOT independently to power off the core if other cores in the same cluster are still powered on. But this is conflicting with TC2's power management code in tc2_pm.c.
We can see in the function *tc2_pm_down()*, it will call gic_cpu_if_down() to disable GIC's cpu interface; that means the core cannot receive interrupts anymore and the core will run into WFI. After the core run into WFI, if DCC/SPC detect there have interrupts from GIC's nIRQOUT/nFIQOUT pins, then the DCC/SPC will power on the core (or reset the core) to let the core to resume back, then s/w need enable the GIC's cpu interface for itself.
Here the questions are: a) in the function *tc2_pm_down()*, after the core run into WFI state, though DCC/SPC cannot power off the core if the core is NOT the last man of the cluster, but DCC/SPC will reset the core, right? b) how DCC/SPC decide the core is want to run into C1 state or only "WFI" state? DCC/SPC will use the WAKE_INT_MASK bits as the flag?
b) is correct.
To be precise the core will be reset upon IRQ. Till there is no pending IRQ the core stays in wfi and is stuck there.
Lorenzo