Update the descriptions for the various CAN devicetree timing properties
specified in Time Quanta (TQ) to make it clear that these, if present, are
only used for the initial timing parameters.
Deprecate the (Re-)Synchronization Jump Width (SJW) devicetree properties
for both arbitration and data phase timing as these are now only used in
combination with the other TQ-based CAN timing properties, which are all
deprecated.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
This is the final step in making the `zephyr,memory-attr` property
actually useful.
The problem with the current implementation is that `zephyr,memory-attr`
is an enum type, this is making very difficult to use that to actually
describe the memory capabilities. The solution proposed in this PR is to
use the `zephyr,memory-attr` property as an OR-ed bitmask of memory
attributes.
With the change proposed in this PR it is possible in the DeviceTree to
mark the memory regions with a bitmask of attributes by using the
`zephyr,memory-attr` property. This property and the related memory
region can then be retrieved at run-time by leveraging a provided helper
library or the usual DT helpers.
The set of general attributes that can be specified in the property are
defined and explained in
`include/zephyr/dt-bindings/memory-attr/memory-attr.h` (the list can be
extended when needed).
For example, to mark a memory region in the DeviceTree as volatile,
non-cacheable, out-of-order:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_VOLATILE |
DT_MEM_NON_CACHEABLE |
DT_MEM_OOO )>;
};
The `zephyr,memory-attr` property can also be used to set
architecture-specific custom attributes that can be interpreted at run
time. This is leveraged, among other things, to create MPU regions out
of DeviceTree defined memory regions on ARM, for example:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-region = "NOCACHE_REGION";
zephyr,memory-attr = <( DT_ARM_MPU(ATTR_MPU_RAM_NOCACHE) )>;
};
See `include/zephyr/dt-bindings/memory-attr/memory-attr-mpu.h` to see
how an architecture can define its own special memory attributes (in
this case ARM MPU).
The property can also be used to set custom software-specific
attributes. For example we can think of marking a memory region as
available to be used for memory allocation (not yet implemented):
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_NON_CACHEABLE |
DT_MEM_SW_ALLOCATABLE )>;
};
Or maybe we can leverage the property to specify some alignment
requirements for the region:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_CACHEABLE |
DT_MEM_SW_ALIGN(32) )>;
};
The conventional and recommended way to deal and manage with memory
regions marked with attributes is by using the provided `mem-attr`
helper library by enabling `CONFIG_MEM_ATTR` (or by using the usual DT
helpers).
When this option is enabled the list of memory regions and their
attributes are compiled in a user-accessible array and a set of
functions is made available that can be used to query, probe and act on
regions and attributes, see `include/zephyr/mem_mgmt/mem_attr.h`
Note that the `zephyr,memory-attr` property is only a descriptive
property of the capabilities of the associated memory region, but it
does not result in any actual setting for the memory to be set. The
user, code or subsystem willing to use this information to do some work
(for example creating an MPU region out of the property) must use either
the provided `mem-attr` library or the usual DeviceTree helpers to
perform the required work / setting.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Add test suite for the DT fixed-partitions API. It is verified on two
kinds of MTD nodes, one of which is meant to represent external memory.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
The 'zephyr,memory-region-mpu' property was addede gqas a
convenient way to create and configure MPU regions using information
coming from DT. It has been used a lot since it was introduced so I
guess we can consider it a Zephyr success story ™ .
Unfortunately it has been proved to be a bit limited and with some
important limitations:
1. It was introduced as a property of the compatible
zephyr,memory-region that is used to create linker regions and
sections from DT data. This means that we can actually create MPU
regions only for DT-defined regions and sections.
2. The naming is unfortunate because it is implying that it is used only
for MPU.
3. It is misplaced being in include/zephyr/linker/devicetree_regions.h
and still it has nothing to do with the linker at all.
4. It is exporting a function called LINKER_DT_REGION_MPU that again has
nothing to do with the linker.
Point (1) is also particularly limiting because it is preventing us to
characterize memory regions that are not generated using the
'zephyr,memory-region' compatible, like generic mmio-sram regions.
While we fix all the issues, we also want to extend a bit the range of
usefulness of this property. We are renaming it 'zephyr,memory-attr' and
it is now carrying information about the type of memory the property is
attached to (cacheable, non-cacheable, IO, eXecutable, etc...). The user
can use this property and the DT API coming with it to act on the memory
node it is accompanied by.
We are still providing the DT_MEMORY_ATTR_APPLY() macro that can be used
to create the MPU regions as before, but we are adding also a
DT_MEMORY_ATTR_FOREACH_NODE() macro that can be used to cycle through
the memory nodes and act on those.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Usage of 64-bit address constants from devicetree without a
UINT64_C wrapping macro results in the following warning and the
cut-off of the address value:
"warning: integer constant is so large that it is unsigned"
This change extends devicetree API adding few wrappers over the
address constant getters which add ULL size suffix to an
address integer literal when the appearance of 64-bit address
values is possible
Signed-off-by: Alexander Razinkov <alexander.razinkov@syntacore.com>
Verify expected results for every permissible argument type, including
with a phandle and a string in an inferred binding from /zephyr,user.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This commit adds access to the string values without a quotes.
Signed-off-by: Radosław Koppel <r.koppel@k-el.com>
Co-authored-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
This adds a few bits to the devicetree API tests for multi-bus
nodes where a bus can support multiple protocols. This uses
I3C as basis as I3C controller can support both I2C and I3C on
the same bus, while I2C controller cannot support both. So
this needs to make sure the correct bus macros are generated
if appropriate (and not generated if not needed).
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Adds vendor name helpers to access generated macros based on matching
entries in the vendor prefixes file.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
This commit adds string token versions of the values also
in items inside string-array.
Signed-off-by: Radosław Koppel <r.koppel@k-el.com>
Co-authored-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Co-authored-by: Kumar Gala <galak@kernel.org>
All in tree device drivers use some form of DEVICE_DT_GET
so we no longer need to require label properties.
Signed-off-by: Kumar Gala <galak@kernel.org>
This contains accessor macros for getting the maximum bitrate supported
by a CAN controller/transceiver combination.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
This macro expands to DT_STRING_TOKEN if property exists, otherwise
falls back to default value.
Helpful when a non-required enum binding doesn't mention a default
value, but a default value makes sense to be set in the code.
Including DT_INST_STRING_TOKEN_OR and test code.
Signed-off-by: Bernardo Perez Priego <bernardo.perez.priego@intel.com>
The vnd,gpio-device compatible is now used by the test GPIO driver
(CONFIG_GPIO_TEST) introduced in #41387. This means that we can't define
new devices with this compatible when CONFIG_GPIO=y.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Add tests for the instance based enum macros DT_INST_ENUM_IDX and
DT_INST_ENUM_IDX_OR.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
One limitation of the current IPM API is that it is assuming that the
hardware is only exporting one single channel through which the data can
be sent or signalling can happen.
If the hardware supports multiple channels, the IPM device must be
instantiated (possibly in the DT) several times, one for each channel to
be able to send data through multiple channels using the same hw
peripheral. Also in the current IPM API only one callback can be
registered, that means that only one driver is controlling all the
signalling happening on all the channels.
This patch is introducing a new MBOX API that is supporting
multi-channel signalling and data exachange leveraging and extending the
previous (and outdated) IPM API.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Currently all the *-names and *-cells properties are derived from the
name of the base <name>s property. This is a limitation because:
- It forces the base property name to be plural ending in -s
- It doesn't allow the english exception of plural words ending in -es
With this patch we add one additional property 'specifier-space' that
can be used to explicitly specify the base property name.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Suggested-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
It can be convenient to "iterate" over the elements of a property, in
the same way it is convenient to "iterate" over enabled instances.
Add a new macro for doing this, along with a DT_INST_FOREACH_PROP_ELEM
variant.
This is likely to be more convenient than UTIL_LISTIFY or FOR_EACH in
some situations because:
- it handles inputs of any length
- compiler error messages will be shorter and more self-contained
- it is easier to use with phandle-array type properties, which
require more complicated macro boilerplate when used with
util_macro.h APIs
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Make sure that child bindings with their own compatibles are treated
as first-class bindings. Do this by making sure that nodes whose
bindings are defined via 'child-binding:' are picked up as bus nodes,
instead of a parent bus node of the same type.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This returns the node identifier for a node's bus. For example, for a
device on an I2C bus, it would return a node identifier for the I2C
bus controller.
We already have a DT_BUS() and DT_INST_BUS_LABEL(), but there hasn't
been a request or need for DT_INST_BUS() up until now, so it didn't
exist yet.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
These need to be gpio controllers and have the necessary specifier
properties for use in gpio specifiers.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
The DTS language permits zeroing out phandles in a phandle array to
say "there's nothing at this index", and dtlib manages that correctly,
but edtlib and gen_defines.py aren't equipped to do so.
Fix this by allowing None elements in the lists of ControllerAndData
values returned by edtlib for such properties.
Handle that in gen_defines.py by setting the generated
DT_N_<node>_P_<prop>_IDX_<i>_EXISTS macro to 0 in such cases.
The DT_N_<node>_P_<prop>_LEN macro still accounts for the entire
length of the phandle-array; it's just that some indexes may be
missing data.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Test macro DT_PROP_BY_PHANDLE_IDX_OR. There are two tests, one when
the property exists and other when the property is not set.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Add the first API functions that directly deal with node dependency
ordinals as determined by edtlib:
- DT_DEP_ORD(node_id): node_id's ordinal
- DT_REQUIRES_DEP_ORDS(node_id): list of dep ordinals for node_id's
direct dependencies
- DT_SUPPORTS_DEP_ORDS(node_id): list of dep ordinals for nodes
depending directly on node_id
- DT_INST_ equivalents
This is not meant to be an exhaustive set of macros related to
dependency ordinals; rather, it's a starting out point meant to enable
initial struct device dependency tracking work. We can add more if
needed.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
In case a "required: False" enum binding doesn't mention a
default value, but a default value makes sense to be set in the code,
DT_ENUM_IDX_OR could be used to provide the default idx to be used.
New macro comes with appropriate tests.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
This is preparation for an additional test suite specifically for the
legacy API which will be added next.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
