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>
As we move to making the `label` property optional, we need to account
for widespread use of `dev->name` in contexts where the pointer is not
validated before it is dereferenced. Use an empty string instead of a
null pointer when no label is provided.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
While using the encoded path to a device tree node guarantees a unique
identifier for the corresponding device there is a limit on the number
of characters of that name that can be captured when looking up a
device by name from user mode, and the path can exceed that limit.
Synthesize a unique name from the node dependency ordinal instead, and
update the gen_defines script to record the name associated with the
full path in the extern declaration.
Add a build-time check that no device is created with a name that
violates the user mode requirement.
Also update the network device DTS helper functions to use the same
inference for dev_name and label that the real one does, since they
bypass the real one.
Signed-off-by: Peter Bigot <peter.bigot@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>
Now that we generate a header that extern's all possible devicetree
based device struct we can remove DEVICE_DT_DECLARE and
DEVICE_DT_INST_DECLARE as they aren't needed anymore.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Generate a header (device_extern.h) that handles extern of possible
device structs that would come from devicetree. This removes the need
for DEVICE_DT_DECLARE and DEVICE_DT_INST_DECLARE which we can remove.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The existing code only worked for nodes that had a label property,
which is every device except ESP32 pinmux. However, a label property
should not be necessary for defining a device from devicetree.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
- Remove SYS_ prefix
- shorten POWER_MANAGEMENT to just PM
- DEVICE_POWER_MANAGEMENT -> PM_DEVICE
and use PM_ as the prefix for all PM related Kconfigs
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add convenience macros versions of DEVICE_DT_DECLARE and
DEVICE_DT_DEFINE that take a DT_INST number instead.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
When using a devicetree node as an identifier we know the identifier
used to define the device structure. This allows code to directly
reference that structure, avoiding the need to look it up by label at
runtime.
Change the macros so DEVICE_DT_* device objects are globally visible
using the node identifier as the object identifier.
Also add the necessary API to verify that a device that was captured
at build time successfully completed initialization and any other
steps necessary before it can be safely used.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
For devices defined using devicetree nodes we need to pass the
devicetree node, and to infer names for the device and the driver from
it. Devices defined in the classical way don't need this. Introduce
another level of private abstraction that accepts the information from
either source, falling back to the old parameters when the provided
node is invalid.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
The dev_name is the canonical DT node identifier encoding the
devicetree path; the drv_name is the label of the corresponding node.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
deprecate DEVICE_INIT in favor of just using DEVICE_DEFINE directly.
The small handful of DEVICE_INIT users was easily converted to use
DEVICE_DEFINE or SYS_DEVICE_DEFINE.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
This is a step towards phasing out DEVICE_INIT and just having
DEVICE_DEFINE. To make it a little easier on users or DEVICE_DEFINE
if they don't care about PM, they can just pass NULL for the
pm_control_fn paramater.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Now that device_api attribute is unmodified at runtime, as well as all
the other attributes, it is possible to switch all device driver
instance to be constant.
A coccinelle rule is used for this:
@r_const_dev_1
disable optional_qualifier
@
@@
-struct device *
+const struct device *
@r_const_dev_2
disable optional_qualifier
@
@@
-struct device * const
+const struct device *
Fixes#27399
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
In order to make all device instances constant, driver_api pointer is
not set to NULL anymore if initialization failed.
Instead, have a bitfield dedicated to it.
Fixes#27399
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Following are the changes to variable names that are matching
with tag names (Rule 5.7 violations)
In kernel.h, event_type is matching with a tag name in
lib/os/onoff.c. Added a _ prefix to event_type and
also to the macro argument names.
In userspace.c, *dyn_obj is matching with the tag name
dyn_obj in the file itslef. Changed it to dyn
In device.h, device_mmio.h, init.h and init.c,
changed the *device to dev. Except for one change in
init.h
Signed-off-by: Spoorthy Priya Yerabolu <spoorthy.priya.yerabolu@intel.com>
struct device is by definition representing an device driver instance
and as such, driver_ prefix in attributes is rather redundant and can be
removed.
Fixes#27397
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
There use to be a config attribute of type device_config, on which
config_info could be found. config_info was thus named that way to
differentiate easily from config attribute in struct device.
Now that there is no such device_config structure, config_info in
structure device now, can be renamed to config.
Semantically, it makes for sense. We have an attribute pointing to the
configuration of the device driver instance. Configuration information
is correct but has a redundant meaning.
Fixes#27397
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Three variants provided:
- Drivers with one MMIO region to manage
- Drivers with multiple MMIO regions to manage
- Drivers or driver-like code which doesn't use Zephyr's device
model
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Currently this is useful only for some internal applications that
iterate over the device table, since applications can't get access to
a device that isn't ready, and devices can't be made unready. So it's
introduced as internal API that may be exposed as device_ready() when
those conditions change.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Device objects in Zephyr are currently placed into an array by linker
scripts, making it easy to iterate over all devices if the array
address and size can be obtained. This has applications in device
power management, but the existing API for this was available only
when that feature was enabled. It also uses a signed type to hold the
device count.
Provide a new API that is generally available, but marked as internal
since normally applications should not iterate over all devices. Mark
the PM API approach deprecated.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
DEVICE_AND_API_INIT and DEVICE_DEFINE are identical except that
DEVICE_DEFINE adds a parameter providing the device pm control
function, while DEVICE_AND_API_INIT does not. This requires duplicate
implementations where if CONFIG_DEVICE_POWER_MANAGEMENT is enabled
then DEVICE_AND_API_INIT delegates to DEVICE_DEFINE with a dummy pm
control function, and if it is not enabled then DEVICE_DEFINE discards
the parameter and delegates to DEVICE_AND_API_INIT.
DEVICE_INIT is like DEVICE_AND_API_INIT but doesn't provide an API.
Clean this up by refactoring so that DEVICE_DEFINE is the core
implementation, providing with and without device power management
right next to each other where they can be compared and maintained.
Redefine DEVICE_INIT and DEVICE_AND_API_INIT delegate to
DEVICE_DEFINE.
Also remove duplicate code by extracting the variations due to
enabling device power management into macros.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Avoid duplication of the encoding of the public device identifier by
using the constructing macro in definitions.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
This parameter points to the driver instance private data, and not to
its configuration data, which one is set via cfg_info parameter.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
The device_pm_control_nop function is documented to always return zero
regardless of operation. However, when device_get_power_state() is
invoked with this control function it returns success leaving the
output parameter state unmodified, which may not be a valid device
state.
Document and implement that the nop control function returns -ENOTSUP
always.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
When the device driver model got introduced, there were no concept of
SYS_INIT() which can be seen as software service. These were introduced
afterwards and reusing the device infrastructure for simplicity.
However, it meant to allocate a bit too much for something that only
required an initialization function to be called at right time.
Thus refactoring the devices structures relevantly:
- introducing struct init_entry which is a generic init end-point
- struct deviceconfig is removed and struct device owns everything now.
- SYS_INIT() generates only a struct init_entry via calling
INIT_ENTRY_DEFINE()
- DEVICE_AND_API_INIT() generates a struct device and calls
INIT_ENTRY_DEFINE()
- init objects sections are in ROM
- device objects sections are in RAM (but will end up in ROM once they
will be 'constified')
It also generate a tiny memory gain on both ROM and RAM, which is nice.
Perhaps kernel/device.c could be renamed to something more relevant.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This adds a sys init level which allows device and sys_init
to be done after SMP initialization, z_smp_init(), when all
cores are up and running.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
