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>
We can't enable device runtime power management in a device that is
set busy since it may suspend this device.
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>
The pm_device_slots section is only used by subsys/pm/pm.c. This file is
only compiled if CONFIG_PM=y. pm_device_slots is unused otherwise.
Don't populate pm_device_slots when CONFIG_PM=n, CONFIG_PM_DEVICE=y.
Signed-off-by: Marco Widmer <marco.widmer@bytesatwork.ch>
Based on information from doc/develop/api/overview.rst, add current
version for some groups representing APIs, following the following
table:
- Experimental: 0.1.0
- Unstable: 0.8.0
- Stable: 1.0.0
Also based on doc/develop/api/overview.rst, add 'since' tag to the
groups.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Extend macros from creating a PM device with an optional argument
which indicate whether type of device is ISR_SAFE or not.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
In many cases suspending or resuming of a device is limited to
just a few register writes. Current solution assumes that those
operations may be blocking, asynchronous and take a lot of time.
Due to this assumption runtime PM API cannot be effectively used
from the interrupt context. Zephyr has few driver APIs which
can be used from an interrupt context and now use of runtime PM
is limited in those cases.
Patch introduces a new type of PM device - synchronous PM. If
device is specified as capable of synchronous PM operations then
device runtime getting and putting is executed in the critical
section. In that case, runtime API can be used from an interrupt
context. Additionally, this approach reduces RAM needed for
PM device (104 -> 20 bytes of RAM on ARM Cortex-M).
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
The device_runtime header includes references to struct device
and k_timeout_t, but only zephyr/device.h is included. k_timeout_t
is in zephyr/kernel, so it must also be included.
Signed-off-by: Bjarki Arge Andreasen <bjarki@arge-andreasen.me>
Add a delay parameter to asynchronous device runtim put. This allows
to delay the put operation what is useful to avoid multiple states
transitions.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
This pointers need to be writable by the power management code,
but were declared as const, resulting in a fault
for platforms which prevent writing to RAM containing const
values.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Function pm_state_cpu_get_all is declared in state.h
but it is only implemented if CONFIG_PM is set.
Add an inline implementation for when CONFIG_PM is not set.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
In some platforms it may be desirable to disable certain CPU power
states, for example, because they have extra requirements not available
on all boards/applications. Because `cpu-power-states` are defined at
SoC dts file levels, the only way to achieve that now was by re-defining
`cpu-power-states` property in e.g. a board file. With this patch, one
can now selectively set `status = "disabled";` to any power state and it
will be skipped by the PM subsystem.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
pm_device_runtime_get() uses a semaphore to protect resources.
pm_device_runtime_get() blocked forever until obtaining the lock, making
it unusable from contexts where blocking is not allowed, e.g. ISRs. With
this patch, we give the chance to use the function from an ISR by not
waiting on the lock and returning -EWOULDBLOCK instead. If device is
suspending (from a previous put_async() operation) the same value is
returned as we can't wait either.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Adds a helper function for initializing devices into the expected power
state, through the devices `pm_device_action_cb_t`. This eliminates code
duplication between the init functions and the PM callback.
The expected device states in order of priority are:
* No power applied to device, `OFF`
* `zephyr,pm-device-runtime-auto` enabled, `SUSPEND`
* Otherwise, `ACTIVE`
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Adds a helper function for initializing devices into the expected power
state, through the devices `pm_device_action_cb_t`. This eliminates code
duplication between the init functions and the PM callback.
The expected device states in order of priority are:
* No power applied to device, `OFF`
* `zephyr,pm-device-runtime-auto` enabled, `SUSPEND`
* Otherwise, `ACTIVE`
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Dummy inline functions are useful to avoid ifdeffery in code when a
certain option is not available. pm_state_set/pm_state_exit_post_ops,
are only called from the PM subsystem, so never called if CONFIG_PM=n,
that is, never surrounded with ifdeffery.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Supplement the documentation pm_device_is_powered()
adding that a device is assumed powered in case
the device does not support PM or is not on a power domain.
Signed-off-by: Marcel Krüger <marcel.krueger@ithinx.io>
Rename the subsystems group from `subsys` to `os_services`, aligning
with what we have on the Sphinx side.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Events in the power-management policy context are defined as any source
that will wake up the system at a known time in the future. By
registering such event, the policy manager will be able to decide wether
certain power states are worth entering or not.
Events will bypass the ticks argument received by the policy manager if
they occur earlier.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Latency is always specified in microseconds, so apend `us` to the
relevant variables. Also, make it clear that latency request structures
are private (they are just exposed publicly to allow static allocation).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Until now iterable sections APIs have been part of the toolchain
(common) headers. They are not strictly related to a toolchain, they
just rely on linker providing support for sections. Most files relied on
indirect includes to access the API, now, it is included as needed.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add the `zephyr,pm-device-runtime-auto` flag to `pm.yaml` and
`struct pm_device`.
This flag is intended to signify to the boot system that device runtime
PM should be automatically enabled on the device after the init function
has run.
Only run `pm_device_runtime_auto_enable` function on a device if
initialisation succeeded. This prevents actions being run on devices
that are not ready.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Move the construction of the initial value of `struct pm_device` `flags`
to a dedicated macro. This makes it cleaner to add additional default
values.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Returning an error code when PM is not supported for a device only makes
writing drivers harder, as instead of checking for failures with `< 0`,
they also need to check for `-ENOTSUP`.
From the point of view of a driver, an `-ENOTSUP` return value is
equivalent to success, as if the device it is trying to turn on doesn't
support PM, by definition it is already enabled. This is equivalent to
the API behaviour when `CONFIG_PM_DEVICE_RUNTIME=n`.
Whether a device supports PM or not can still be determined at runtime
by inspecting the return code of `pm_device_runtime_enable` if
necessary.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Only run `pm_device_runtime_put` on the dependent domain if the original
claim operation succeeded. This fixes unbalanced operations when running
```
pm_device_runtime_get(dev);
pm_device_runtime_put(dev);
```
On a device that does not have PM enabled but does have a power domain.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
When PM is disabled, it does not make sense to return ENOSYS,
pm_device_runtime_enable/disable should be treated as noop functions.
When PM is disabled, those functions are not supposed to be implemented.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
To be able to call pm_device_runtime_put() from an IRQ context, move
from mutexes to semaphores and force the async path when the put
operation is called from an ISR.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
For the async operation move from condition variables to events to
reduce the dependency on the mutexes that cannot be used in IRQ
context.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
struct pm_device was incorrectly hidden from docs, as well as
pm_device_action_cb_t and pm_device_action_failed_cb_t.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Rename Z_DEVICE_DT_DEV_NAME to Z_DEVICE_DT_DEV_ID to make it more clear,
as the macro is generating a token that identifies the created struct
device.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The usage of dev_name is misleading, since it does not represent the
device name (struct device name field) but the name given to the defined
struct device. In practice, it is used as a kind of unique device
identtifier, so let's rename it to dev_id.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Current API allowed to get notified when the maximum system latency
changes, however, a single callback was allowed. The design was intended
for SoC specific actions when latency changes. However, in some cases
drivers may also want to know the current maximum latency to perform
local actions if other parts of the system modify it.
This patch updates the API with a pair of subscribe/unsubscribe calls to
achieve such goal. Tests have been updated to show how the API can be
used.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Rename the placeholder variable generated for PM slots so that the
prefix doesn't colide with the PM structs declared by devices. This
simplifies the process of searching for symbols in `.elf` files.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
When CONFIG_PM_DEVICE=n a device will always be in active state. Provide
a dummy implementation of pm_device_state_get that always returns
PM_DEVICE_STATE_ACTIVE.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Store errors powering up devices in a flag in the PM struct. This is
required as the `pm->state` variable always transitions to
`PM_DEVICE_STATE_SUSPENDED`, even when `PM_DEVICE_ACTION_TURN_ON`
returns an error. Marking the transition as failed will allow the
transition logic in `pm_device_runtime_get` to detect the problem.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
PM_DEVICE_ACTION_FORCE_SUSPEND has been equivalent to
PM_DEVICE_ACTION_SUSPEND for a while. Release notes for Zephyr 2.7
mentioned its removal (see 76702e8ff3) but
for some reason it was kept.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Adds a helper function to query whether a device is currently powered.
This can be used to determine if the chip can be initialised now, or if
it needs to be deferred.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Return `-ENOTSUP` on calls to device_runtime functions if the underlying
device does not support power management.
Fixes#45648.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
In order to bring consistency in-tree, migrate all includes within
include directory 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>
