Enable these tests which run in native_posix in native_sim,
Switch from native_posix to native_sim as default test platform
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Add tests for new DT APIs added in the previous commit:
- `DT_IRQN_BY_IDX`
- `DT_INST_IRQN_BY_IDX`
Added additional tests for the following existing DT APIs when
`CONFIG_MULTI_LEVEL_INTERRUPTS` is enabled:
- `DT_IRQN`
- `DT_INST_IRQN`
Added `qemu_riscv32` for the multi-level interrupt tests.
Signed-off-by: Yong Cong Sin <ycsin@meta.com>
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>
Rename `DT_COMPAT_ON_BUS_INTERNAL` to
`DT_HAS_COMPAT_ON_BUS_STATUS_OKAY` to make it a public DT API.
It is helpful for code that handles multiple DT_DRV_COMPAT in one file,
such as in the following cases.
```
#if (DT_HAS_COMPAT_ON_BUS_STATUS_OKAY(some_sensor, i2c) || \
DT_HAS_COMPAT_ON_BUS_STATUS_OKAY(another_sensor, i2c)
...
#endif
#define DT_DRV_COMPAT some_sensor
DT_INST_FOREACH_STATUS_OKAY(DEFINE_SOME_SENSOR)
#undef DT_DRV_COMPAT
#define DT_DRV_COMPAT another_sensor
DT_INST_FOREACH_STATUS_OKAY(DEFINE_ANOTHER_SENSOR)
```
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.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>
Add the _VARGS variant of DT_FOREACH_NODE and
DT_FOREACH_STATUS_OKAY_NODE for when we want to do some kind of
operation on all the nodes in the tree.
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>
It will be convenient to treat these respectively as degenerate cases
of 'phandles' and 'string-array'. Add support for this and regression
tests. (There's nothing to do in the case of 'phandle' beyond
documenting the guarantee.)
For the record, the other DT_PROP_LEN() tests for each type are in:
type test case property
------------ -------------------- ------------
array test_arrays a
string-array test_path_props compatible
uint8-array test_arrays b
phandles test_phandles phs
phandle-array test_phandles pha-gpios
phandle test_phandles ph
Update docstrings and fix some issues in them.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Twister now supports using YAML lists for all fields that were written
as space-separated lists. Used twister_to_list.py script. Some artifacts
on string length are due to how ruamel dumps content.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Remove all init functions that do nothing, and provide a `NULL` to
*DEVICE*DEFINE* macros.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@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>
integration_platforms help us control what get built/executed in CI and
for each PR submitted. They do not filter out platforms, instead they
just minimize the amount of builds/testing for a particular
tests/sample.
Tests still run on all supported platforms when not in integration mode.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Follow up to e1e16640b5 adding model name
helpers to access generated macros based on a compatible's matching
entries in vendor prefixes.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
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>
It is frequent to see in Devicetree code constructs like:
```c
#define NAME_AND_COMMA(node_id) DT_NODE_FULL_NAME(node_id),
const char *child_names[] = {
DT_FOREACH_CHILD(DT_NODELABEL(n), NAME_AND_COMMA)
};
```
That is, an auxiliary macro to append a separator character in
DT_FOREACH* macros. Non-DT API, e.g. FOR_EACH(), takes a separator
argument to avoid such intermediate macros.
This patch adds DT_FOREACH_CHILD_SEP (and instance/status okay/vargs
versions of it). They all take an extra argument: a separator. With this
change, the example above can be simplified to:
```c
const char *child_labels[] = {
DT_FOREACH_CHILD(DT_NODELABEL(n), DT_NODE_FULL_NAME, (,))
};
```
Notes:
- Other DT_FOREACH* macros could/should be extended as well
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
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>
Deprecate DT_LABEL and DT_INST_LABEL as we have phased out
general 'label' usage and there isn't a need to keep a specific
set of macros for 'label'. DT_PROP(node, label) works fine for
the small handful of cases that need it now.
Signed-off-by: Kumar Gala <galak@kernel.org>
Add two new utility macros for iterating over the entire tree, along
with tests.
I have a use case for DT_FOREACH_STATUS_OKAY_NODE() right now, but I
think it makes sense to define both of them right away for
completeness.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Add a bunch of missing "zephyr/" prefixes to #include statements in
various test and test framework files.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
A lot of places that DT_LABEL is used we can replace with DT_SAME_NODE
as we are just checking that the node we got from the macro is the
same as what we expect.
Signed-off-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>
Deprecate DT_BUS_LABEL and DT_INST_BUS_LABEL as we phase out
'label' property usage in favor of DT_BUS and variants.
Signed-off-by: Kumar Gala <galak@kernel.org>
Deprecate DT_GPIO_LABEL, DT_INST_GPIO_LABEL, DT_GPIO_LABEL_BY_IDX,
and DT_INST_GPIO_LABEL_BY_IDX as we phase out 'label' property usage
in favor of DT_GPIO_CTLR and variants.
Signed-off-by: Kumar Gala <galak@kernel.org>
Deprecate DT_SPI_DEV_CS_GPIOS_LABEL and DT_INST_SPI_DEV_CS_GPIOS_LABEL
as we phase out 'label' property usage in favor of
DT_SPI_DEV_CS_GPIOS_CTLR and variants.
Signed-off-by: Kumar Gala <galak@kernel.org>
In order to bring consistency in-tree, migrate all tests to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Some names of the test cases are duplicated within the project.
This commit contains the proposed names of the test scenarios.
Signed-off-by: Katarzyna Giadla <katarzyna.giadla@nordicsemi.no>
It can be useful to know what a node's index is in its parent's list
of children. This information is now available to C via
gen_defines.py, but no user-facing macros are available to access it.
Add a macro which exposes this information to users via devicetree.h.
Some APIs want to build on devicetree.h by creating some derived
structure for each of a node's children. It can therefore be
convenient to use each child's index in the list of children as an
identifier for the child.
Some concrete and common examples are "gpio-keys" and "gpio-leds",
which allow you to define arbitrary numbers of keys and LEDs as child
nodes of nodes with those compatibles. Derived APIs can use a key or
LED node's index in its list of parents as a way to identify which of
several structures is relevant to a particular controlled key or LED.
These are just examples, though -- the feature added here makes no
assumptions about where it's being used.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Alberto Escolar Piedras