Dynamic Voltage and Frequency Changes: Validate the Transition, Not Just the Final Setting

Validate a voltage/frequency change as an ordered transaction with observable intermediate states. A final frequency readback cannot show whether the supply was prepared first, whether a later step failed, or whether software still describes the previous operating point. Review the exact transition implementation before designing the capture or recovery test.

Applicability: this article pins Linux v6.12 OPP core behavior for an initialized, enabled table using a single clock and single-regulator configuration callback. The low/high OPP example is hypothetical. No voltage, frequency, settling interval, or semiconductor operating limit is recommended. Firmware-managed DVFS and custom platform callbacks require separate analysis.

1. Identify the transition owner and approved operating points

Record the caller that requests the transition, the OPP table actually loaded, the clock provider, regulator provider, and any required domain or interconnect settings. Distinguish a policy decision to select an OPP from the operations that realize it.

The OPP library documentation describes supported operating-point tuples and dynamic availability. An entry being present in a source file does not establish that it is currently available or approved for every silicon revision, temperature, supply, and board configuration.

Obtain the chosen processor’s operating limits and the selected regulator’s transition behavior before target testing. Use the board’s validated OPP table rather than deriving voltage from a generic frequency ratio. Shared supplies, coupled rails, firmware constraints, and speed-bin selection can change the requirements.

2. Trace the actual up and down order

In v6.12 _set_opp(), the scaling-up path configures required OPPs, performance level, bandwidth, and configured regulators before configuring clocks. The scaling-down path configures clocks first, then regulators, bandwidth, level, and required OPPs.

For the scoped single-clock example, this gives an explicit software ordering to verify: prepare the higher operating requirements before requesting the higher clock; request the lower clock before relaxing the associated requirements. The platform callbacks still determine the actual hardware actions and completion semantics.

Do not assume a custom callback implements only one write or automatically waits for every electrical prerequisite. Review its provider calls, error handling, and documented completion boundary. If the platform requires additional sequencing, the generic ordering alone cannot establish compliance.

Likewise, an ordered API call sequence is not a captured rail waveform. A regulator configuration request and measured voltage at the processor are different observations. Record both where the platform permits meaningful measurement.

3. Keep requested, selected, and realized frequency separate

The v6.12 dev_pm_opp_set_rate path rounds through the clock framework and finds a ceiling OPP for the resulting rate. The clock may support finer frequency steps than the OPP table, so the frequency passed onward need not be replaced by the table entry’s maximum frequency.

Capture the caller’s requested rate, rounded rate, selected OPP, clock-operation result, and available hardware readback. Avoid asserting that a table label proves the exact realized clock or that a policy request always causes a physical change.

A same-OPP request can still need a clock change in that path. Conversely, the core has an early return for a non-forced request to the already-current enabled OPP. Distinguish a real transition from a no-op before interpreting timing or energy measurements.

4. Model partial failure rather than assuming atomic rollback

_set_opp returns at a failing stage; it does not provide a generic reverse-operation transaction that automatically restores all earlier changes. Its current_opp bookkeeping advances only after the full sequence succeeds. A callback may implement additional rollback, but that must be verified separately.

Consider a hypothetical up-transition from L to H. The regulator callback succeeds, then the clock callback reports failure. The API returns an error and current_opp remains L, while an earlier supply configuration may already have changed. Do not claim either that H was reached or that every hardware setting returned to L.

For a hypothetical down-transition, the clock callback can succeed before the regulator callback fails. The old OPP bookkeeping again does not prove that the old physical clock remains. Preserve the successful earlier step and failure stage in the diagnostic record.

Blindly calling dev_pm_opp_set_opp with the bookkeeping’s old OPP is not a universal rollback: the non-forced same-OPP early-return condition can make that request a no-op. Recovery belongs in a reviewed platform/caller design that reconciles known operations and supported provider state, rather than modifying private core fields.

5. Build an event-indexed capture

Propose a trace with request entry, selected OPP, each provider operation’s entry and return, transition result, and first workload completion afterward. Add a suitable clock observation and supply measurement at the documented load point when available.

Use a common timing reference or record synchronization uncertainty. A software log timestamp is not necessarily the instant a regulator output crosses an acceptance threshold. Define those electrical thresholds and allowed transition conditions from the actual part documents before capturing.

Test both directions under a controlled representative load. A lightly loaded up-transition can miss a supply disturbance visible during real work; a final steady-state sample can miss a transient entirely. Keep probe bandwidth, loading, supply setup, and temperature with the evidence.

6. Separate model faults from safe target tests

First propose a mock-provider fixture that fails each operation in turn and records which calls occurred. Require no later stage after the first error, and verify the caller reports failure without inventing a completed OPP transition. These software fixtures have not been executed here.

Include the successful up/down paths, same-OPP no-op, rate change within one OPP, and partial-failure cases. Review recovery explicitly after each one. A test that only checks the final return code misses leftover provider changes.

On hardware, use only supported operating points and reviewed fault mechanisms. Do not create undervoltage, overclocking, or unsafe coupled-rail combinations to imitate the model. Where an error cannot be injected safely, retain that branch as a model/source-review result and state the target coverage gap.

7. Accept the complete transition contract

The release artifact should include selected-part limits, table provenance, callback implementation, ordered trace, error-stage ledger, and post-transition workload correctness. Keep electrical qualification separate from source-level call-order verification.

A valid endpoint is necessary, but the path and failure state also matter. Accept DVFS only when supported transitions preserve the platform’s operating requirements and unsuccessful requests leave a defined recovery outcome. Do not substitute a successful frequency readback for those independent checks.