Ensure `pm_state_force` returns `false` when it fails to retrieve or set
the desired power state. This change improves error handling and ensures
the function's behavior aligns with its intended purpose.
Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>
pm_suspend is returning early if there are no states
available (due to locking or latency policy). However,
if state is forced it should not return but rather enter
forced power state.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
When all states are locked or latency requirement cannot be met
by any power state it is important to be able to quickly exit
suspend procedure because that usually means that application
requires high performance. Add function for detecting if any
power state is available.
Additionally, add function pm_policy_state_is_available for
checking if given state is available which means that it is not
locked and fulfills current latency requirement.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Use power state pointers instead of copies which improves performance.
Align power_mgmt_multicore test which was creating pm states in
runtime.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
When core is suspended and power mode has non zero exit_latency_us
a system timeout will be rescheduled to a point in time that is
earlier by exit_latency_us than request. It is to accommodate for
lengthy resuming procedure which would cause requested timeout to
be significantly late. However, setting additional wake up point
has cost, it is one more redundant core wake up and that impacts
performance and power consumption.
Add Kconfig option to chose what conversion method is used. It has
the biggest impact on small exit_latency_us where conversion may
result in 0 ticks (no pre-wake up) or 1 tick (wake up).
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
A warning is giving for missing initalizer for field `exit_latency_us`
of `struct pm_state_info`. This adds the additional init fields.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
Some events needs to be handled with a very low latency constraint.
If the system is in deep sleep, exit latency from this low level state
exceeds sometimes the maximum latency constraint of these events.
Before suspending the system, select which events is happening sooner,
kernel events or normal events.
CPU will be up just before the next event occurs taking into account the
exit latency of the current power state
Change also the policy event API to take as argument absolute time in HW
cycles instead of time in us
Signed-off-by: Riadh Ghaddab <rghaddab@baylibre.com>
PM_DEVICE is not attached to system managed device power management.
It is a very common use case targets with device runtime power
management that don't want system device power management enabled.
We introduce a new symbol (PM_DEVICE_SYSTEM_MANAGED) to explicit
control whether or not system device power management should be
globally enabled.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Remove device pm path when there is no is no power state in DT with
device pm enabled. This basically does the same thing that was done
by PM_DEVICE_RUNTIME_EXCLUSIVE.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Make it possible to disble device power management individually per
power state. This allows targets tuning which states should
(and which should not) trigger device power management.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
pm_system_resume() can be called directly from ISR and because of this
devices should be resumed before calling pm_state_exit_post_ops().
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
There is no need to this function be defined inside the kernel since
all places using it are protecting the call under ifdef PM guards.
This way we can also remove the ifdef condition inside the implementation.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
This API is not widely used and it is actually broken since device
runtime power management is not checking it when suspending and
resuming.
On top of that, this API is very close to pm_device_busy* API,
close enough to consolidate in only one API.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
When the policy returns NULL pm_system_suspend was assuming that
the current state in z_cpus_pm_state was ACTIVE, since that is the
state set after the core wakes and return to this function. The
problem is that in cases where the cpu does not preserve the context,
and returns to this function, z_cpus_pm_state has the value of the
last state used and the cpu use it again.
Fix it setting z_cpus_pm_state to ACTIVE every time the policy returns
NULL.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
pm_suspend_devices() could return an error. Set timeout using
sys_clock_set_timeout() to after this error is handled so that
we have the accurate power state when calling the timeout function.
This is useful in cases where we wish to compensate the
system timer for certain power modes.
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
This is a private kernel header with private kernel APIs, it should not
be exposed in the public zephyr include directory.
Once sample remains to be fixed (metairq_dispatch), which currently uses
private APIs from that header, it should not be the case.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Any system supporting PM must now implement
pm_state_set/pm_exit_post_ops. Before this change any platform could
enable CONFIG_PM=y, even though it did nothing, ie, no power savings at
all.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Only set a cpu as active (on pm subsystem) when the cpu is effectively
initialized. We cannot assume on pm subsystem that all cpus were
initialized since when the option CONFIG_SMP_BOOT_DELAY is used cpus are
initialized on demand by the application.
Note that once cpus are properly initialized the subystem is able to track
their status.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
The z_set_timeout_expiry() function is a wrapper provided in the
timeout subsystem that has some corrections for timelicing. But the
suspend code doesn't care; by definition there are no active threads
that might be timeslicing at the point where the OS is suspending.
Use the lower-level timer driver API instead.
(z_set_timeout_expiry() is also about to disappear)
Signed-off-by: Andy Ross <andyross@google.com>
z_cpus_active count becomes incorrect when the state is
PM_STATE_RUNTIME_IDLE and CONFIG_PM_DEVICE is enabled.
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
The PM subsystem should not call the PM control callbacks on
uninitialized devices when entering low-power states.
Signed-off-by: Corey Wharton <xodus7@cwharton.com>
Replace usage of CONFIG_MP_NUM_CPUS with CONFIG_MP_MAX_NUM_CPUS for
init and declaration as we phase out CONFIG_MP_NUM_CPUS usage.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
Sometimes we want to entirely decouple the system PM from the device PM,
leaving the devices to manage its own power states using the runtime PM.
This is currently not possible because the suspend / resume code path is
triggering the device PM hooks even when the runtime PM is enabled.
Introduce a new PM_DEVICE_RUNTIME_EXCLUSIVE symbol to allow the platform
to skip the device PM triggers on suspend / resume.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
_current_cpu is a macro that expands to an assert that checks if the
current context can be migrated to a another cpu. Since this
pm_system_suspend() is called from the idle thread (each cpu has its
own) and with locked this check is redundant. Just use
arch_curr_cpu() to avoid it.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
pm_system_resume() can be called from the idle thread with
interruptions unmasked. In this situation, _current_cpu will call
z_smp_cpu_mobile() that will return true and cause an assert.
In this function we don't need to check if the current context can be
preempted, we just need the information about which cpu is executing
it.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Files including <zephyr/kernel.h> do not have to include
<zephyr/zephyr.h>, a shim to <zephyr/kernel.h>.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
There is a race condition in a multicore system that happens when the
idle thread in a CPU checks if the state was forced, if not it will
call the policy manager. If a secondary core forces a state after that
this point the value returned by the policy will be rewritten.
Another case is, if a state is forced while a CPU is sleeping,
when this CPU resumes, the forced bit is cleared and the forced state
is never be used.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
In pm_system_suspend there is a goto label that is supposed to be used
to do cleanup before exit the function but it is not doing anything
right now. Just remove it.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
In order to bring consistency in-tree, migrate all subsystems code to
the new prefix <zephyr/...>. Note that the conversion has been scripted,
refer to zephyrproject-rtos#45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Aligning with the rest of PM API, replace pm_power_state_exit_post_ops
with pm_state_exit_post_ops.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Now that the forced flag is cleared with the kernel locked in the
suspend path, we need to clear it out when the suspend process fails.
This is being done before jump to the end label because in the
successful path the flag is already cleared.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
The "state forced" flag has to be cleared with the scheduler locked,
otherwise the idle thread can be scheduled out without clear it and
the next call to force a state will fail.
Fixes#41911
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Return a constant reference to the next state instead of a copy of
struct pm_state_info. When the next state should be active, just return
NULL. Struct copying should be in general avoided, specially in code
paths executed frequently as is this one.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
