Question: Hotplug support for systems without PMIC

[ldts]

Under the current linux implementation for psci 0.2, hotplug instructs the PMIC to switch off the calling CPU and sets it in WFI; the linux implementation then uses another CPU to check that the CPU was properly powered (it calls affinity_info for the CPU that was powered off)

what would be the recommended mode of operation on systems without a a PMIC? ie, could we allow the secondary CPU to actually perform the power action (it is my understanding that in some SoCs, one CPU can switch off a different one).

[danh-arm]

As stated in the PSCI spec, "ARM expects that the Exception level with the highest privilege ... will be the component that can program the power controller to enter an idle state". The ARM Trusted Firmware PSCI implementation exists as an EL3 runtime service and has a platform-specific part that is responsible for communicating with the platform's power controller.

The power controller could be a PMIC or another CPU. If it's another CPU then you need a platform-specific secure world interface to that CPU for CPU power state control. If that CPU is also responsible for other forms of power management (e.g. DVFS), then there are complications around providing independent channels of communication to both the secure and normal worlds. If that other CPU is also part of the Linux scheduling domain, then there are complications around how to do power control of that CPU versus other CPUs. If multiple CPUs are able to do power control of the other CPUs, then there are additional potential race conditions and "last-man" issues.

All of these problems need to be handled by the platform specific PSCI implementation. There may also be a knock-on impact to the normal world platform-specific power control interfaces.

Most of the complications I mention go away if there is a dedicated PMIC or power control CPU.

[ldts]

(thanks for adding the label - I didn't have the permissions to do it myself)

In the case of Juno, the CPUx that will be powered off sends a power off request to the SDP (which will perform the action in due course) and then executes WFI waiting to be switched off; the SDP will then switch off CPUx.

In systems where you can't post a delayed power off request to the external PMIC, we could modify the cpu_kill linux call to the ATF; this RichOS call to the ATF is currently used by CPUx only to check that CPUy was indeed powered off; the proposal would be to have the handler of this call in the ATF to perform the actual power off action of CPUy.

Implementing this might require a new PSCI function or extending one of the current ones with an additional parameter.

I would like to have your input on the above. thanks.

[achingupta]

@ldts. I have a few questions about the approach you have outlined.

1. An external PMIC waits for a CPU to enter WFI before turning off the power supplies. There is a reliable mechanism that supports this i.e. the PMIC knows for certain that the CPU is in WFI. Will CPUx have access to a similar mechanism? There will be races here which will be difficult to avoid
2. If there was a special SMC to implement cpu_kill() in Trusted Firmware, then multiple CPUs could call it simultaneously. This could happen while there are other CPU_ON calls targeting CPUy in flight at the same time. There will need to be some sort of an OFF_PENDING state.There would be an extra software overhead to manage these races. Is this what you have in mind?

Thanks!

[Bigfan-Chen]

Regarding race condition, kernel for hotplug flow uses mutex lock in cpu_maps_update_begin() and cpu_hotplug_begin() to protect this section. In addition, op_cpu_kill() is also called in mutex protect region as the following call flow. Hence, race condition should be avoid in kernel. If any misunderstanding, please feel free to let us know.

CPUx: the cpu executing kill process CPUy: the target cpu to be killed

In cpu.c and smp.c

/in CPUx context/ cpu_down() -> cpu_maps_update_begin() /mutex to protect cpu maps/ ->-> cpu_hotplug_begin() /mutex to protect hotplug flow/ ->->-> __cpu_die() /waiting CPUy complete died/ ->->->->op_cpu_kill() ->->->->->cpu_psci_cpu_kill() /expecting to add a special SMC to implement CPUy power control flow/ ->-> cpu_hotplug_done() /unlock mutex/ -> cpu_maps_update_done() /unlock mutex/

[danh-arm]

What you're proposing might work (at least in most cases) but is effectively a change to the PSCI specification. The Trusted Firmware simply implements that specification so this isn't really the right forum for such a discussion. There will be some PSCI experts from ARM going to the upcoming Linaro Connect event in Hong Kong. If you are going too, I suggest you seek them out. Otherwise, contact ARM directly through your partner manager.

[danh-arm]

I'm closing as this thread seems to have run its course. We can reopen if needed.

[belladmv]

Hello,

I am not sure if this is the right forum to ask this question. If not, please suggest. I have a question regarding the PMIC interface and controlling it.

Here, I am assuming PMIC is interfaced using I2C interface and is supplying power to the ARM Core. If the ARM Power needs to be turned off, then the PMIC needs to be controlled by the PSCI platform specific code. That essentially means having an I2C driver for the PMIC in the PSCI firmware implementation. However, for DVFS operations, which is not handled by the PSCI firmware, the linux PM framework also needs to access the PMIC to set the voltage required. What is your suggestion for handling this?

Thanks, MBEL.

[soby-mathew]

@belladmv, could you please open a new issue with your query as this issue is already closed.