As stated in GIC v3 Arch: After powering up a PE, software must set ProcessorSleep to 0 and wait until ChildrenAsleep == 0.
Can you please also state the conditions for GICR_WAKER.ChildrenAsleep to go 0? As in my case at a particular operating frequency of GIC500, for some ARM A53 cores ChildrenAsleep do not go to 0 indefinitely (post clearing ProcessorSleep).
And hence respective cores do not come out of WFI.
P.S. Interrupt targeted to the Core and PE clocks enabled with WakeRequst signal.
Hi Danish,
I have moved your question to the Software Tools community as I feel that a member of this Community may be able to help answer your question.
Thanks
Ryan
ProcessorSleep is used to tell the GIC whether the connected core is awake. Software sets the bit to 1 brefpre the cores is enters a low power state. It clears the bit to 0 once after the core wakes up again.
When ProcessorSleep is written, there is some handshaking between the core and the GIC. ChildrenAsleep is reporting when that's finished.
So is ChildrenAsleep is updating as expected, it suggests the core hasn't responded properly.
I'm a bit confused by the WFI comment, is GICR_WAKER being written by a different processors?
Also remember that after clearing ProcessorSleep (and seeing ChildrenAsleep==0), only then can you re-program the ICC registers
Thanks Martin, Ryan
Yes you're correct, the GICR_WAKER is written by another PE of the device.
Also, in the later set of experiments I found that clock was still gated to the Core cluster which may explain why this handshake never completed. In the SoC design, the wake_request signal propagates to the COP and directs it to re-enable the clocks of the core cluster. Seems the wake_request signal never reached the COP boundary, is there some way in GIC500/CPU interface/memory mapping where I can look for the status of this signal (per core)?
Regards,
Danish