On Mon, 9 Sep 2013, Catalin Marinas wrote:
On Sun, Sep 08, 2013 at 05:16:16PM +0100, Nicolas Pitre wrote:
What MCPM does is to receive this power saving request from cpuidle on individual CPUs including their target residency, etc. It also receives similar requests for CPU hotplug and so on. And then MCPM _arbitrates_ the combination of those requests according to
I also agree that (in the absence of anything else) MCPM needs to arbitrate the combination of such requests.
- the sttrictest restrictions in terms of wake-up latency of _all_
CPUs in the same power domain, and
Wouldn't the strictest restrictions just translate to min(C-state(CPUs-in-cluster)), min(C-state(clusters)) etc.? IOW simple if/then/or/and rules because deeper C states have higher target residency and wake-up latency?
Sure, just like the CPU,cluster tuple vs MPIDR, this is just a different way to communicate the information. The current code in mainline is currently rather rough and serves as a basis for further discussion. IOW this is the Linux kernel with a policy of having no internal stable APIs which may easily evolve to fit the overall design over time. Those are simple implementation details compared to the question of whether or not this should live in firmware or in the kernel.
For instance, what is not universal are the C-state definitions. Hardware is getting more complex and varied, and it is becoming hard to simply abstract different power modes into a linear numerical scale. So the C-state concept will also need to evolve.
- the state of the other CPUs which might be in the process of coming
back from an interrupt or any other event, and 3) the particularities of the hardware platform where this is happening.
It's fine for MCPM to handle in the absence of any other synchronisation (which could be firmware).
It could be firmware... if you are convinced you'll be able to update the firmware easily if the synchronization model changes (which as I highlighted already is far from obvious as exemplified by needed bug fixes in the TC2 firmware over 6 months after reporting them), or if you can be convinced that your better than everyone else and your firmware implementation is totally free of bugs and that the implemented synchronization model will never need to change.
Look, I _know_ that firmware could be made to do the job and PSCI is an appropriate abstraction in that case. That is not the point. So let me refocus the discussion back to my initial concern that started this conversation.
No one so far was able to make the demonstration that any firmware implementation would be bug free, and/or flexible enough to cater for future innovations in the kernel, and/or easily updateable after product deployment just like the kernel is.
Complexity always induces bugs, and bugs in the firmware are order of magnitude more costly than bugs in the kernel. That cost is either in the bug fixing with re-certification of the firmware and the sensitive update process, or in the need to work around those bugs that will be there forever and the inability to improve things over time only with a simple non-secure software update. But I'm sure you know that already.
Therefore having (equivalent of) MCPM in the firmware is _not_ cost effective. So it is to be expected that some people will make the engineering decision not to do the full power synchronization in the firmware and opt for simpler and more flexible alternatives to PSCI from the firmware perspective.
I'm sorry to bring this over again, but the discussion seems to keep being diverted away from this fundamental point with no concrete answers. I'm attributing this to a flaw in the overall secure world architecture that you have to put up with, hence the apparent diversion.
Nicolas