Generating generic information for 'type: phandle-array' properties in
edtlib was difficult due to defining phandle-array as just a list of
phandles and numbers. To make sense of a phandle-array property like
'pwms', you have to know that #pwm-cells is expected to appear on
each referenced controller, and that the binding for the controller has
a #cells.
Because of this, handling of various 'type: phandle-array' properties
was previously hardcoded in edtlib and exposed through properties like
Node.pwms, instead of through the generic Node.props (though with a lot
of shared code).
In practice, it turns out that all 'type: phandle-array' properties in
Zephyr work exactly the same way: They all have names that end in -s,
the 's' is removed to derive the name of related properties, and they
all look up #cells in the binding for the controller, which gives names
to the data values.
Strengthen the definition of 'type: phandle-array' to mean a property
that works exactly like the existing phandle-array properties (which
also means requiring that the name ends in -s). This removes a ton of
hardcoding from edtlib and allows new 'type: phandle-array' properties
to be added without making any code changes.
If we ever need a property type that's a list of phandles and numbers
but that doesn't follow this scheme, then we could add a separate type
for it. We should check if the standard scheme is fine first though.
The only property type for which no information is generated is now
'compound'.
There's some inconsistency in how we generate identifiers for clocks
compared to other 'type: phandle-array' properties, so keep
special-casing them for now in gen_defines.py (see the comment in
write_clocks()).
This change also enabled a bunch of other simplifications, like reusing
the ControllerAndData class for interrupts.
Piggyback generalization of *-map properties so that they work for any
phandle-array properties. It's now possible to have things like
'io-channel-map', if you need to.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
This commit introduces separate "compatible" strings for DTS nodes
representing different types of Nordic SPI peripherals. Previously
"nordic,nrf-spi" was used for both SPI and SPIM. SPIS was already
handled separately.
Quite a few files need to be touched by this commit but the changes can
be divided into groups of related or very similar ones, distinguishable
by the initial part of the path to the modified file:
* dts/bindings/spi/
new binding for "nordic,nrf-spim" is added and common fields for all
3 types of Nordic SPI peripherals are extracted to a shared file
* dts/arm/nordic/
"compatible" properties in spiX nodes are updated (when there is no
choice as only one type of SPI peripheral is available) or replaced
with a comment pointing out that the proper type of peripheral needs
to be picked at some upper layer
* drivers/spi/
spi_nrfx_spim driver is updated with the new form of macros generated
from dts
* boards/
all spiX nodes in dts files for boards equipped with an nRF chip are
updated with the proper "compatible" property, according to the type
of SPI peripheral that is currently selected for the board by the
corresponding Kconfig choice option (SPI_x_NRF_SPI*)
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
This commit introduces separate "compatible" strings for dts nodes
representing different types of Nordic TWI peripherals. Previously
"nordic,nrf-i2c" was used for both TWI and TWIM, and TWIS was not
supported.
Quite a few files need to be touched by this commit but the changes can
be divided into groups of related or very similar ones, distinguishable
by the initial part of the path to the modified file:
* dts/bindings/i2c/
new bindings for "nordic,nrf-twim" and "nordic,nrf-twis" are added
and the one for "nordic,nrf-i2s" is renamed to "nordic,nrf-twi",
common fields for all these bindings are extracted to a shared file
* dts/arm/nordic/
"compatible" properties in i2cX nodes are updated (when there is no
choice as only one type of TWI peripheral is available) or replaced
with a comment pointing out that the proper type of peripheral needs
to be picked at some upper layer
* drivers/i2c/
both flavors of i2c_nrfx drivers are updated with the new names of
macros generated from dts
* boards/
all i2cX nodes in dts files for boards equipped with an nRF chip are
updated with the proper "compatible" property, according to the type
of TWI peripheral that is currently selected for the board by the
corresponding Kconfig choice option (I2C_x_NRF_TWI*)
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Use the new 'compatible:' and 'include:' syntaxes, and clean it up like
for other bindings.
Shorten the description, because it appears in the output as a comment
above the generated macros, and it looks neater. I asked Mateusz what
kind of device it is.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Use the new 'compatible:', 'include:', and 'required:' keys, and clean
it up like other bindings.
Shorten the 'description:' text, because it appears in the output as a
comment above the generated macros, and it looks neater.
Fixes: #19385
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Add support for up-and-down counter mode, which aligns the center of
each channel's pulses instead of their initial edges. This is enabled
on a PWM periphral by adding the "center-aligned" property to the
device tree, e.g.:
&pwm0 {
status = "okay";
center-aligned;
ch0-pin = <15>;
ch1-pin = <17>;
ch1-inverted;
};
Signed-off-by: Jim Paris <jim@jtan.com>
Use the device tree to assign the correct peripheral clock to each
UART/USART/LEUART. Previously, the clock identifier was determined
through the sequence number of the instantiated UART. This meant
configuring all UARTs when only one of the later UARTs was required.
Signed-off-by: Oane Kingma <o.kingma@interay.com>
This adds support for Kinestis K22
Co-authored-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Co-authored-by: Oliver Stäbler <oliver.staebler@bytesatwork.ch>
Co-authored-by: Tom Burdick <thomas.burdick@gmail.com>
Signed-off-by: Tom Burdick <thomas.burdick@gmail.com>
This commit adds driver supporting reading DNA ID value for LiteX SoC
builder.
Signed-off-by: Jakub Wegnerowski <jwegnerowski@internships.antmicro.com>
Signed-off-by: Mateusz Holenko <mholenko@antmicro.com>
Enable LiteX DNA ID driver in litex_vexriscv board.
Signed-off-by: Jakub Wegnerowski <jwegnerowski@internships.antmicro.com>
Signed-off-by: Mateusz Holenko <mholenko@antmicro.com>
Add RTC timer driver for CC13X2/CC26X2, and use it instead of systick
as system clock. It is necessary to use this timer for power
management support, so that the system can exit from deep sleep upon
expiry of timeouts.
Signed-off-by: Vincent Wan <vincent.wan@linaro.org>
Deprecate 'sub-node:' and add a more general 'child-binding:' mechanism
to bindings. Keep supporting 'sub-node:', but print a deprecation
warning when it's used.
Like 'sub-node:', 'child-binding:' gives a binding to child nodes, but
the binding is required to be a complete binding, and is treated (and
checked) like a normal binding.
'child-binding:' can in turn contain another 'child-binding:', up to any
number of levels. This is automatic from treating it like a normal
binding, and from the code initializing parent Devices before child
Devices.
This lets nodes give bindings to grandchildren.
For example, take this devicetree fragment:
parent {
compatible = "foo";
child-1 {
grandchild-1 {
...
};
grandchild-2 {
...
};
};
child-2 {
grandchild-3 {
...
};
};
};
The binding for 'foo' could provide bindings for grandchild-1/2/3 like
this:
compatible: "foo"
# Binding for children
child-binding:
title: ...
description: ...
...
# Binding for grandchildren
child-binding:
title: ...
description: ...
properties:
...
Due to implementation issues with the old devicetree scripts, only two
levels of 'child-binding:' is supported for now. This limitation will go
away in Zephyr 2.2.
Piggyback shortening 'description:' and 'title:' in some bindings that
provide child bindings. This makes the generated header a bit neater.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
The arc_iot.dtsi used "intel,qmsi-ss-gpio" and "intel,qmsi-ss-i2c"
compatiables, however we have no drivers for these and it seems wrong
that the ARC platform would utilize such compatiables. Remove the
compatiable fields for now (proper one's can be added when there are I2C
and GPIO drivers for this platform).
Also remove the binding files associated with "intel,qmsi-ss-gpio" and
"intel,qmsi-ss-i2c" as nothing in tree utilizes them.
Fixes: 19227
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Instead of
child:
bus: foo
parent:
bus: bar
, have
child-bus: foo
parent-bus: bar
'bus' is the only key that ever appears under 'child' and 'parent'.
Support the old keys for backwards compatibility, with a deprecation
warning if they're used.
Also add 'child/parent-bus' tests to the edtlib test suite. It was
untested before.
I also considered putting more stuff under 'child' and 'parent', but
there's not much point when there's just a few keys I think. Top-level
stuff is cleaner and easier to read.
I'm planning to add a 'child-binding' key a bit later (like 'sub-node',
but more flexible), and child-* is consistent with that.
Also add an unrelated test-bindings/grandchild-3.yaml that was
accidentally left out earlier.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
This driver was still using CONFIG_* values to determine its address,
IRQ, etc. Add a binding for an "intel,hpet" device and migrate this
driver to devicetree.
Fixes: #18657
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
Add support to STM IIS3DHHC the ultra-low noise, high-stability
three-axis linear accelerometer.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
4 are found: 2 with a counter of 16bits and 2 with a counter of 32 bits.
However, first 32bits instance will not be exposed as it will be used by
rtos timer driver directly to implement k_busy_wait()
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
The driver for STM32's independent watchdog already exists and is
compatible with the stm32wb SoC. Enable the independent watchdog
for the stm32wb series for use with this driver.
Signed-off-by: Robert Weber <robertweber95@gmail.com>
The LIS2MDL is not a combo device, but pure magnotemeter.
Hence, '-magn' extension is not adding information and can
be removed from dts compatible name as well as binding filename.
Instead specify '-i2c' or '-spi' to distinguish between the names.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
XIP support in x86 was something of a mess. This
patch does the following:
- Generic ia32 SOC no longer defines a "flash" region
as generic X86 devices don't have a microcontroller-
like concept of flash. The same has been done for apollo_lake.
- Generic ia32 and apollo_lake SOCs starts memory at 1MB.
- Generic ia32 SOC may optionally have CONFIG_XIP enabled.
The board definition must provide a flash region definition
that gets exposed as DT_PHYS_LOAD_ADDR.
- Fixed definitions for RAM/ROM source addresses in ia32's
linker.ld when XIP is turned off.
- Support for enabling XIP on apollo_lake SOC removed, there's
no use-case.
- acrn and gpmrb boards have flash and XIP related definitions
removed.
- qemu_x86 has a fake flash region added, immediately after system
RAM, for use when XIP is enabled. This used to be in the ia32 SOC.
However, the default for qemu_x86 is to now have XIP disabled.
- Fixed tests/kernel/xip to run by default on boards that enable
XIP by default, plus an additional test to exercise XIP on
qemu_x86 (which supports it but has XIP switched off by default)
The overall effect of this patch is to:
- Remove XIP configuration for SOC/boards where it does not make
any sense to have it
- Support testing XIP on qemu_x86 via tests/kernel/xip, but leave
it off by default for other tests, to ensure it doesn't bit-rot
and that the system works in both scenarios.
- XIP remains an available feature for boards that need it.
Fixes: #18956
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The KE1xF SoC family SIM unit differs from the other Kinetis family
SoCs. Add a unique compatiable and binding for it.
Fixes#18160
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
