pub struct PowerManager<C: PowerController = NoController> { /* private fields */ }Expand description
Power manager for controlling system power state.
§Hardware support (read this)
Real power transitions — dynamic CPU-frequency scaling and peripheral
clock/power gating for HighPerformance / Balanced / LowPower /
UltraLowPower / DeepSleep — are SoC-vendor-specific and require a
BSP-provided PowerController. This manager never fabricates
vendor-register writes; it delegates every transition to the installed
controller.
The type parameter records which controller is installed:
PowerManager::newbuilds aPowerManager<NoController>: a bookkeeping-only manager. Transitions are validated and the requested mode is recorded (socurrent_modealways reflects the last successful request), but no hardware is touched for the four active modes. This is honest by construction — the type isPowerManager<NoController>andhas_hardware_controllerreturnsfalse.PowerManager::with_controllerbuilds aPowerManager<C>around a real BSP controller;request_modethen delegates toPowerController::set_power_modeand propagates its result.
§Sleep modes
For PowerMode::Sleep and PowerMode::DeepSleep the manager, after
delegating to the controller, additionally issues the ISA-level WFI
(wait-for-interrupt) on arm/aarch64 and riscv targets. WFI really
halts the core in a low-power state until a wake event and is target-generic
(not SoC-specific), so it lives here rather than in the controller. On other
targets it is a no-op.
§Requiring real hardware
Callers that must not proceed without silicon-level control should use
request_mode_strict, which returns
EmbeddedError::NoPowerController when only a NoController is
installed instead of silently recording a mode that never reached hardware.
Implementations§
Source§impl PowerManager<NoController>
impl PowerManager<NoController>
Sourcepub const fn new() -> Self
pub const fn new() -> Self
Create a new bookkeeping-only power manager in high performance mode.
The manager holds a NoController, so transitions are recorded but no
hardware is reconfigured. Use with_controller
to install a BSP-provided PowerController for real transitions.
Source§impl<C: PowerController> PowerManager<C>
impl<C: PowerController> PowerManager<C>
Sourcepub const fn with_controller(controller: C) -> Self
pub const fn with_controller(controller: C) -> Self
Create a power manager backed by a BSP-provided PowerController,
starting in high performance mode.
Every subsequent transition delegates to controller.
Sourcepub const fn controller(&self) -> &C
pub const fn controller(&self) -> &C
Borrow the installed power controller.
Sourcepub fn has_hardware_controller(&self) -> bool
pub fn has_hardware_controller(&self) -> bool
Whether a real hardware PowerController is installed.
Returns false for the default NoController and true for any
controller that does not override
PowerController::is_hardware to false.
Sourcepub fn current_mode(&self) -> PowerMode
pub fn current_mode(&self) -> PowerMode
Get current power mode.
Sourcepub fn request_mode(&self, mode: PowerMode) -> Result<()>
pub fn request_mode(&self, mode: PowerMode) -> Result<()>
Request a power mode transition.
The requested mode is validated and recorded, then applied through the
installed PowerController. With the default NoController the mode
is recorded but no hardware is reconfigured (see the type-level
docs); with a BSP controller the transition is delegated to
PowerController::set_power_mode and its result is propagated. For
sleep modes the ISA-level WFI is issued afterwards on arm/riscv.
If you must not proceed without real hardware control, use
request_mode_strict instead.
§Errors
Returns EmbeddedError::PowerModeTransitionFailed if the transition is
not allowed, or any error surfaced by the installed controller.
Sourcepub fn request_mode_strict(&self, mode: PowerMode) -> Result<()>
pub fn request_mode_strict(&self, mode: PowerMode) -> Result<()>
Request a power mode transition, failing loudly if there is no real hardware controller.
Identical to request_mode except that it returns
EmbeddedError::NoPowerController — without recording the mode or
touching hardware — when only a bookkeeping NoController is
installed. Use this when a silent no-op would be a correctness bug (for
example, before entering a mode your application depends on for thermal
or battery limits).
§Errors
Returns EmbeddedError::NoPowerController if no hardware controller is
installed, otherwise behaves like
request_mode.