On Wed, May 08, 2013 at 02:07:26PM -0400, Nicolas Pitre wrote:
On Wed, 8 May 2013, Dave Martin wrote:
On Wed, May 08, 2013 at 11:17:49AM +0800, Leo Yan wrote:
- Now the switching is an async operation, means after the function
bL_switch_request is return back, we cannot say switching has been completed; so we have some concern for it.
I did write some patches to solve that, by providing a way for the caller to be notified of completion, while keeping the underlying mechanism asynchronous.
There are two things to distinguish here.
First, it is true that bL_switch_request() is currently posting switch requests and not waiting for them to complete.
Nico: Can you remember whether you had any concerns about that functionality? See "ARM: bL_switcher: Add switch completion callback", posted to you on Mar 15.
I had concerns which I sent on March 13, and as far as I can see they were all addressed in the fixup patch you posted on March 15.
However ...
For example, when switch from A15 core to A7 core, then maybe we want to decrease the voltage so that can save power; if the switching is an async operation, then it maybe introduce the issue is: after return back from the function bL_switch_request, then s/w will decrease the voltage; but at the meantime, the real switching is ongoing on another pair cores.
That's the second point. When bL_switch_to() returns, the switch _is_ complete. However the outbound CPU may still be alive doing some processing of its own. It may purposely stay alive for a while to allow the inbound CPU to snoop its cache. Or it could be used to pre-zero free memory pages or whatever. It may be doing extra cleanup work because it was elected as the last man in its cluster. Etc.
So, as I explained in my previous reply, it is not because the switch is over that the outbound CPU is no longer running. Therefore the switch done notification must not be used to hook voltage changes as only the MCPM backend really knows if and when all CPUs in a cluster are really down.
Note that if we really need to be certain that the CPU is really down, MCPM is not enough either, because that only observes various levels of committing to powerdown. Ultimately, only the SoC hardware knows when a true low-power state is reached.
If you want to cut the voltage to a level which would be unsafe before true powerdown is reached, this needs to be coordinated by external means. On some SoCs, the power controller may be capable of doing this itself -- I believe this is the case on TC2. If instead software has direct control, it would be necessarily to mask (or otherwise prevent) wakeups on the affected CPU and wait until the power controller tells you it is down before you start changing the voltage.
Cheers ---Dave