Power and performance control

Introduction

Modern processors implement dynamic power management to reduce energy consumption without sacrificing performance. Below are key Linux kernel subsystems which enable this:

  • CPUIdle: Manages idle states (C-states) when the CPU has no work to do. Deeper states save more power but have longer exit latency (Time to bring back to execution state from idle.).

  • CPUFreq: Manages operating frequency/voltage (P-states) of CPUs during active operation. Lower frequencies reduce power consumption, higher frequencies increase performance.

Together, these frameworks help balance power efficiency and system responsiveness.

The System Control and Management Interface (SCMI) is an ARM standard that defines a communication protocol between the OS Power Management (OSPM) software (running on application cores) and a System Control Processor (SCP), which implements power and performance control logic for the platform.

With the above framework, users can set the system into pre-defined power profiles in order to match system power consumption to the current driving task.

Architecture

Power and performance control implementation consists of following software components

  1. Linux drivers to control power and performance of devices. This includes cpuidle and cpufreq frameworks.

  2. MHU communication for SCMI power domain management protocol via PSCI and performance domain management protocol.

  3. Power and performance control executed in SCP Firmware.

The following diagram shows the components and interface to implement power and performance control.


Power and Performance Control Architecture

Fig. 31 Power and Performance Control Architecture


CPUIdle Design

CPUIdle manages the power states of a CPU when it is idle (i.e., not executing tasks). It allows the CPU to enter low-power C-states to save energy.

C-states are hardware-defined idle states. Following are the C-states defined for this demonstration.

  • CPU_SLEEP: Sleep for a single CPU.

  • CLUSTER_SLEEP: Deeper sleep for an entire cluster.

CPUIdle framework contains following components.

  • CPUIdle Core: Provides the common API for idle state management.

  • Governor: Chooses the appropriate idle state based on heuristics

    (e.g., ladder, menu, teo).

  • Driver: Platform-specific code mapping kernel states to hardware

    idle states (C1, C2, etc.).

  • Hardware Idle States: Actual processor low-power modes.

Please refer the kernel documentation for further details.

Interaction flow

  1. OSPM / Scheduler detects no runnable tasks on a CPU.

  2. CPUIdle Governor predicts idle duration and selects a C-state.

  3. CPUIdle Core calls the SCMI CPUIdle driver with the target state.

  4. Driver issues state request to the TF-A PSCI module.

  5. TF-A request SCP to enter the C-state.

  6. SCP sequences clocks/power for the CPU/cluster and acknowledges.

  7. Wakeup event (interrupt or timer) occurs: - TF-A handles the wakeup event and releases to Non-secure world.

  8. CPUIdle Core returns to the kernel; scheduling resumes.

CPUFreq Design

CPUFreq is a Linux kernel subsystem that dynamically adjusts the operating frequency and voltage of a CPU to balance performance and power consumption.

CPUFreq framework contains following components.

  • CPUFreq Core: Central framework providing APIs and sysfs entries.

  • Governor: Algorithm deciding which frequency to select (e.g., ondemand, schedutil, performance, powersave).

  • Driver: Talks to the hardware (via ACPI, device tree, platform APIs) to actually change CPU frequency/voltage.

  • DVFS Hardware: Dynamic Voltage and Frequency Scaling block of the SoC/CPU.

Please refer the kernel documentation for further details.

The following operating points are provided for demonstration purposes on this platform.

  • frequency: 1.8GHz, Voltage: 750mV

  • frequency: 2GHz, Voltage: 850mV

  • frequency: 2.5GHz, Voltage: 950mV

Each DSU cluster in RD-Aspen platform is considered as one performance domain. Hence the performance points can be chosen per cluster.

Note

The frequency/Voltage values above are chosen/assumed for FVP/reference design platform and may change on actual SoC.

Interaction flow

  1. OS Scheduler updates the cpu load and Governor (e.g., schedutil) decides a new target performance level or frequency.

  2. CPUFreq Core normalizes the request against policy constraints (allowed operating points, min/max frequency).

  3. SCMI CPUFreq driver translates the target to SCMI domain semantics. - SCMI Performance protocol provides set_level(min/max), set_rate(FHz) interface which is invoked depending on the request.

  4. SCP sequences DVFS (voltage ↔ frequency) and configures the respective clocks and PSU and acknowledges back to kernel.