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.
Nicolas