Use clock control API to retrieve the module's frequency and
update the boards using it to provide the source clocks.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
Use clock control API to retrieve the module's frequency and
update the boards using it to provide the source clocks.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
The PIT maximum load value may not be always 32-bit. Allow the SoC to
define this value from devicetree.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
Remove temp-, vref- and vbat-channel from STM32 ADC nodes as it is not
used in the driver anymore.
Signed-off-by: Guillaume Gautier <guillaume.gautier-ext@st.com>
Use clock control API to retrieve the module's frequency and
update the boards using it to provide the source clocks.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
Deprecate the advanced CAN timing devicetree properties in favor of setting
advanced timing parameters from application code.
The advanced timing properties are giving in number of time quanta (Tq) and
requires reverse-calculation to find a suitable CAN clock divider. The
resulting bitrate error is compared against a threshold in the driver
initialization code, but the application is not able to retrieve it.
Forcing applications to use the CAN timing APIs directly instead makes it
up to the application to determine if the bitrate error is acceptable or
not.
The deprecated properties are:
- prop-seg
- phase-seg1
- phase-seg2
- prop-seg-data
- phase-seg1-data
- phase-seg2-data
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add phandle prop to reference any regulator that must
be enabled in order for the LPADC to function as intended.
Change LPADC driver to use this property if present.
LPADC on LPC55S36 depends on VREF peripheral, enable for this platform.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Add node for VREF0 peripheral to LPC55S3X SOC DT
Clock VREF peripheral if status = okay in DT
Enable VREF on lpcxpresso55s36
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Add binding, include header, and driver for NXP VREF IP block.
NXP VREF is an internal voltage reference generator on some SOCs
that fits well with the regulator API in zephyr.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Enable clock control driver for NXP S32ZE SoCs and add clock sources
definitions for devicetree.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
The ARM Cryptocell 310/312 IP is wrapped by Nordic specific registers.
It is organized as follows:
- Base address: Nordic wrapper
- Base address + 0x1000: ARM Cryptocell IP registers
Following more standard devicetree conventions, use a single node for
what is exposed as a single peripheral. The node contains 2 register
entries, one for the wrapper and a second one for the 3rd party IP.
Compatibles are used from more specific (nordic,cryptocell) to more
generic (arm,cryptocell-3xx).
Other minor fixes: peripheral is disabled by default (as it should be in
SoC dts files).
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
This platform (SOC_SERIES_EFM32PG1B) is also using SOC_GECKO_SERIES1 and
needs a pinctrl device defined to build the gecko-uart driver
successfully.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
The gecko UART driver needs pinctrl support for SOC_GECKO_SERIES1
devices, this has been added to jg and pg 12b series in 40fa96506b but
is missing in others, causing some build failurse.
Add the device nodes for the gg11b and gg12b files since they contain
gecko-uart references and seems to be under the SERIES1 define.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Rework RAM disk driver to be configured using devicetree and
support multiple instances.
This patch also removes a copy of the RAM disk driver,
tests/subsys/fs/fat_fs_dual_drive/src/disk_access_test_drv.c,
that was there for testing multiple disk drivers support.
Bonus: one SYS_INIT() less and a memory region can be exported to the
host.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
LP/HP RING OSC clocks were replaced by the ACE IPLL clock.
If needed IPLL can be configured to work as low power clock. But right
now ACE uses only WOVCRO and IPLL (configured to work as HP RING OSC
clock).
Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>
LP/HP RING OSC clocks were replaced by the ACE IPLL clock.
If needed IPLL can be configured to work as low power clock. But right
now ACE uses only WOVCRO and IPLL (configured to work as HP RING OSC
clock).
Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>
The ACE family platforms do not have LP/HP RING OSC clocks. They were
replaced by the ACE IP integrated PLL clock. Selecting LP or HP in
CLKCTL will result in enabling IPLL.
Clock can supply frequencies for both replaced clocks, default frequency
equals to 393.2 MHz.
Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>
The ACE family platforms do not have LP/HP RING OSC clocks. They were
replaced by the ACE IP integrated PLL clock. Selecting LP or HP in
CLKCTL will result in enabling IPLL.
Clock can supply frequencies for both replaced clocks, default frequency
equals to 393.2 MHz.
Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>
This creates separate dtsi files for the various memory density codes of
SAM X2xfamilies (they are the same where the specific size exists.)
All of the boards with the exclusion of EV11L78A use the same density
model of 18 (32KiB RAM and 256KiB flash) which is what the samd2x.dtsi
include specified for all of them previously.
The density code has been confirmed being the same across the D20/D21,
C20/C21, L21, and R21 families. This does not carry over to some other
series such as the E5x.
Signed-off-by: Diego Elio Pettenò <flameeyes@meta.com>
Add SRAM code region definition to RT6xx series SOC. The RT6xx shares
SRAM partitions between the code and data bus, but a default allocation
is chosen by the SOC level devicetree. The user can modify this
allocation by changing the base address and size of the sram_code and
sram0 regions in their board devicetree.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Add SRAM code region definition to RT5xx series SOC. The RT5xx shares
SRAM partitions between the code and data bus, but a default allocation
is chosen by the SOC level devicetree. The user can modify this
allocation by changing the base address and size of the sram_code and
sram0 regions in their board devicetree.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.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 yaml file for 'xen,xen', because without it an appropriate
'CONFIG_DT_HAS_XEN_XEN_ENABLED' isn't generated.
It will be used for checking Xen support on current setup, instead of
checking if it is BOARD/SOC "xenvm" (which is not correct for Domain-0
configurations).
Remove xen,xen-4.15.yaml at all, because it isn't necessary to have
yaml for some specific Xen version.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
This commit adds support for the ATMEL HSMCI peripheral
for the SAM4E MCU series, enabling native SD card support.
Signed-off-by: Vincent van Beveren <v.van.beveren@nikhef.nl>
The zdsp.basicmath needs a bit more ROM space to run.
So enlarge the indicated ROM size to accommodate that.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This commit adds/modifies `riscv,isa` strings using the following rules:
* the ISA string is lowercase
* multi-letter extensions are preceded with the underscore mark
* if an extension is implied by another one, it is not specified - e.g. the
D extension implies the F extension, so writing `rv32ifd` is redundant
Signed-off-by: Filip Kokosinski <fkokosinski@antmicro.com>
This commit removes the enum array with allowed values for the `riscv,isa`
field. There are many ways in which RISC-V ISA extension string can be
represented, and listing them all is futile. In addition, custom extensions
can be implemented, meaning every extension would have to be listed in the
enum array as well.
Signed-off-by: Filip Kokosinski <fkokosinski@antmicro.com>
While most of the ST family SoCs have the compatible string set, several
targets still miss it.
Signed-off-by: Piotr Zierhoffer <pzierhoffer@antmicro.com>
Add a MBOX driver wrapper around the NXP MU, simular to
the existing wrapper around the NXP S32 MRU. This allows Zephyr IPC
to work based on the MU, on a number of NXP boards.
Also update the SHA of NXP HAL to enable the Kconfig for this driver.
Signed-off-by: Yicheng Li <yichengli@google.com>
Determine sh1106 from the `compatibility` value instead of
the SSD1306_CONTROLLER_TYPE setting.
Change the settings in `boards/shields/ssd1306/sh1106_128x64.overlay`
to follow this change.
Remove the SSD1306_CONTROLLER_TYPE from its Kconfig.defconfig,
and set the `compatibility` to `sinowealth,sh1106`.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>
