The Z_DEVICE_STATE_DEFINE macro was conditioned by CONFIG_PM_DEVICE.
This is a problem if one day we have other conditional fields in the
device state field that need to be initialized. The approach has been
changed to have an always existing initializer for the PM field, that is
a no-op if device PM is not enabled.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Create a utility macro to initialize struct pm_device. The initializer
is kept in the pm/device.h header.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The usage field was being initialized using the ATOMIC_INIT macro,
however, it is just a uint32_t variable.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The initialization of the struct pm_device pm field found in the device
state can be statically initialized without the need of doing it at
runtime.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This groups the device state variables in their own linker section.
This is needed for demand paging as these variables are needed
during boot where the paging mechanism has not been initialized.
These variables need to be in the pinned section so they can
be accessed during boot.
Note that if device PM is not enabled, the device state variables
are put into BSS. So we need to pin these.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Adds an API to query and visit supported devices. Follows the example
set by the required devices API.
Implements #37793.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Add supported device information to the device `handles` array. This
enables API's to iterate over supported devices for power management
purposes.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Force the inclusion of a `DEVICE_HANDLE_SEP` at the end of the
devicetree dependency section of the array. This lets us simplify the
implementation of `device_required_handles_get`, as there is only one
symbol the section ends with.
This does not use any extra ROM as the array is padded out to the
original size with `DEVICE_HANDLE_ENDS` anyway.
Also adds a description of the array format where the array is
instantiated.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Optimize the handles array by making the following observations:
* The devicetree ordinal at index 0 in pass1 is discarded by
gen_handles.py, and therefore does not appear in the pass2 array.
* gen_handles.py does not need `DEVICE_HANDLE_ENDS` to determine the
end of the handle array, as that information is present in the .elf.
Therefore, instead of replacing the devicetree ordinal with an
additional `DEVICE_HANDLE_ENDS` at the end (to preserve lengths), we
can simply move the ordinal to the end and have it be the original
`DEVICE_HANDLE_ENDS` symbol. This reduces the size of the array by
one handle per device (2 bytes).
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Its possible that a dts binding doesn't inherit from base.yaml and
thus doesn't have `wakeup-source` defined. To handle these cases
use DT_PROP_OR() which can deal with a property not existing at
all.
Fixes#37676
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Introduce a new API to allow devices capable of wake up the system
register themselves was wake up sources. This permits applications to
select the most appropriate way to wake up the system when it is
suspended.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Add a type and documentation for the device PM control callback. This
way possible return codes and its meaning are documented.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Since the state is no longer modified by the device PM callback, just
use the state value.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The following device busy APIs:
- device_busy_set()
- device_busy_clear()
- device_busy_check()
- device_any_busy_check()
were used for device PM, so they have been moved to the pm subsystem.
This means they are now prefixed with `pm_` and are defined in
`pm/device.h`.
If device PM is not enabled dummy functions are now provided that do
nothing or return `-ENOSYS`, meaning that the functionality is not
available.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add DEVICE_DT_GET_ONE() macro. This macro is similar to
DEVICE_DT_GET_ANY() but instead of returning NULL if no enabled,
compatible device instance is found, it throws a compilation error.
This is useful for compile-time checks in samples.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The callback is not used anymore, so just delete it from the pm_control
callback signature.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Move all PM_DEVICE_STATE_* definitions to an enum. The
PM_DEVICE_STATE_SET and PM_DEVICE_STATE_GET definitions have been kept
out of the enum since they do not represent any state. However, their
name has not been changed since they will be removed soon.
All drivers and tests have been adjusted accordingly.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
When a device is defined a new pointer to a device will be created in
the "z_pm_device_slots" region, effectively creating a device array with
the same size as the number of system devices. This array is then used
by the device PM subsystem to keep track of suspended devices during
power transitions.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
If this call receives an invalid device pointer as argument it
assumes that the `device` is not ready for usage.
This routine is currently called by two device specific APIs:
- device_usable_check(const struct device *dev)
- device_is_ready(const struct device *dev)
The device-specific APIs documentation claims that these two
routines must be called with a device pointer captured from
DEVICE_DT_GET(). So passing NULL is a violation of the rule.
Nevertheless, is quite common in drivers to assign NULL to
a device pointer if the corresponding DT property has not been
found (e.g. a not used gpio interrupt declaration for a given
device instance) and seems legit to interpret this condition
same as the device is not ready for usage.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
The context parameter used across device power management is
actually the power state. Just use it and avoid a lot of
unnecessary casts.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
- Move PM related APIs to `include/pm` so that it follows API `pm_`
prefix namespace. In order to make transition easier
`include/power/power.h` is kept pointing to `include/pm/pm.h`.
- Move most of device PM related content from `include/device.h` to
`include/pm/device.h` and `include/pm/runtime.h`.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Devices that do not require PM should just use NULL.
`device_pm_control_nop` is still kept as an alias to NULL untill all
in-tree usage is replaced with NULL.
Code relying on device_pm_control function now returns -ENOTSUP
(equivalent to calling device_pm_control_nop).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
In case of ARC MWDT toolchain and C++ support enabled the Zephyr .init*
section conflicts with .init* sections derived from toolchain libs.
Let's add 'z_' prefix to Zephyr .init* section (and therefore .device
section as they share the same macros) to make Zephyr section name
unique.
Signed-off-by: Evgeniy Paltsev <PaltsevEvgeniy@gmail.com>
Commit 0a7b65e tweaked the CREATE_OBJ_LEVEL macro in such a way
that it would break the expected sorting order.
For example if you had 2, 19, 20, 30 as the level, we'd end up sort
these to be 19, 2, 20, 30.
Fix this by adding aditional "_" symbol after the init level counter.
That allows to keep correct sort order (for both GNU and MWDT
toolchains) and distinguish init level counter from section suffix
(for MWDT toolchain).
Fixes zephyrproject-rtos#33464
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
This patch includes initial support for FT800 display driver.
It includes basic features. It can be easily extended with more
FT800 display list and co-processor features.
Signed-off-by: Hubert Miś <hubert.mis@gmail.com>
This is a follow up to commit 2aab687270.
Since device_is_ready() is no longer a system call, there is no need
to keep z_impl_device_is_ready().
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
The static device dependencies from devicetree are not the only ones
that might be present at runtime. Add API that allows visiting
required devices without assuming that handles for or pointers to them
can be accessed as a static contiguous sequence.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
We default to use the "label" properties of a devicetree node as the
name if it exists. If the "label" does not exist we than use the
node-name@unit-address for the node as the name.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Various samples are using the DT_INST macros to get devicetree node
identifiers, and going from there in the usual way to get a struct
device*.
This is undesirable for preparing a simple sample application:
1. The devicetree instance number space's rules are both complicated
and irrelevant outside of device drivers. Using this number space
just to get a node identifier is distracting and confusing in this
context.
2. A basic "get the device and use the API" sample doesn't care about
the *devicetree node identifier*; it really just wants a *device*.
Introducing node identifiers at all is also kind of beside the
point.
The only good reason to use DT_INST macros is that they guarantee that
instance number 0 refers to an enabled node with a given compatible,
as long as there is at least one. But the extra complexity isn't
really worth the benefit.
Add a new DEVICE_DT_GET_ANY(compat) macro that solves both of these
problems, by returning an arbitrary device structure straight from a
compatible. This uses INST numbers behind the scenes, but that's now
an implementation detail.
This avoids introducing INST numbers or node identifiers where they
are not needed, without requiring warts like sample-specific aliases
that point at the right devicetree node.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Following the idiom used for system calls, add script support to read
the initial application binary to identify which devices are defined,
and to use their offset in the device array as their unique handle
rather than the externally-defined ordinal from devicetree. The
device dependency arrays are updated to use these handles.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Generate arrays of dependency information for each device. If a
device definition is being constructed from devicetree these come from
the devicetree dependency information. Additional dependencies may be
passed through using the DT_ macros.
Define flag values for device handles so we can partition the
dependency array into distinct sets, which include things it requires,
things it supports (may not be needed), and child nodes (not
implemented, may not be needed).
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Move the busy status from a global atomic bit sequence to atomic flags
in the device PM state. While this temporarily adds 4 bytes to each
PM structure the whole device PM infrastructure will be refactored and
it's likely the extra memory can be recovered.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Separate the state indicator of whether the initialization function
has been invoked from the success or failure of the initialization.
This allows precise confirmation that the device is ready (i.e. it has
been initialized, and that initialization succeeded).
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
This avoids the need for distinct object that uses flash to store its
initializer. Instead the state is initialized when the kernel is
starting up, before anything can reference it. In future refactoring
the PM state could be accessed directly without storing an extra
pointer in the static device state.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
While devices have driver-specific dynamic state accessed through the
data field, there is also dynamic state that is common to most if not
all devices. Add a structure to hold that data.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
As we add support for devices that are powered down, or are present
but have not yet been started, we need more precise information about
why a device isn't ready, so callers can take appropriate steps to
make it ready.
Add a new function that determines readiness and indicates the reason
for not being ready in a defined unique error code per condition.
Expose this in both a syscall form to be invoked from applications,
and a unchecked form that can be used from supervisor contexts
including syscall implementation functions.
Anticipated future conditions include:
* device is powered down and needs to be brought back up;
* device was installed disabled and has not been started.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>