[...]
PSCI assumes that the FW is in full control of the registers it's poking. While a lock isn't necessarily bad, I suspect it's going to be very difficult to have that common across all users without the code becoming unmaintainable fast. I'd also hope that for arm64 we wouldn't need it.
When/how/why does the kernel to poke these registers?
The PMC is what controls power partitions. Some of these partitions are assigned to CPUs, others are assigned to things like SATA, PCIe, display and so on. The problem is that if we manage the CPU power partitions via the firmware, then they will conflict with calls that we need to make from other drivers that need to gate or ungate the partitions for their hardware. As I understand it there's no provision in PSCI to manage non- CPU devices, so this is a problem.
Ok.
So I think either firmware needs to control everything, in which case we are going to need a new interface (or extend PSCI) or it mustn't control anything, in which case we need custom code in the kernel for SMP. Well, the other alternative would be the lock that we can grab in the powergate API and the PSCI calls.
One reason I'm not so keen on a lock is I could imagine you'd need to grab this for CPU_SUSPEND calls (i.e. cpuidle), at which point all CPUs are going to contend for the lock all the time.
One thing to bear in mind is that PSCI is only one user of the SMC space. Per SMC calling convention, portions of the SMC ID space are there to be used for other (vendor-specific) purposes.
So rather than extending PSCI, a parallel API could be implemented for power control of other devices, and the backend could arbitrate the two without the non-secure OS requiring implementation-specific mutual exclusion.
I think this has been brought up internally previously; I'll go and poke around in the area to see if we managed to figure out anything useful.
It sounds like what we figured out internally is roughly what I stated above:
Allocate some SMC calls in the SIP and/or OEM Service Calls range for vendor-specific device power management, and have the implementation on the secure side (which would do the actual register poking) arbitrate with any other secure-side access to those registers (i.e. CPU power management, which it will already have to arbitrate).
Thanks, Mark.