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>
When multiple devices are connected, the SSD1306_REVERSE_MODE setting
cannot switch for each device.
Add an equivalent setting to the devicetree properties to replace it.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>
Moved the interrupt handling code from a bus-specific binding file to
the parent binding file. This modification ensures that interrupt
handling, which is inherently independent of the type of BUS used
(either i2c or spi), is located in the appropriate location within
the code.
Previously, this code was found in a bus-specific file, despite its
functionality being applicable to all buses. This change ensures a
more logical placement and will help to maintain coherence within the
codebase.
This change aligns with the existing implementation where the interrupt
handling code already operates independently of the BUS type.
Tested this on a nrf52840 with a bmi270 on spi bus with the sample from
zephyr/samples/sensor/bmi270 by adding an interrupt handler in main.c
which uses the bmi270_trigger.c implementation and verified this with
breakpoints and log output.
Added the irq-gpios to tests/drivers/build_all/sensor/i2c.dtsi and
tests/drivers/build_all/sensor/spi.dtsi and fixed whitespace formatting.
Fixes: #58843
Signed-off-by: Andreas Wiesinger <awiesing90@gmail.com>
The current implementation uses both, host and card capabilites to derive
the maximum bus width to be used. However, in cases where a MMC device is
not connected to the host via shdc using the full bus width of 8 lines,
device initialization fails. Introducing the `bus-width` property
circumvents this by reducing the host bus capabilites and forcing
communication with the MMC device using 1, 4 or 8 lines.
Signed-off-by: Mourad Kharrazi <mourad.kharrazi@ithinx.io>
Add a pseudo device which can be used to hook into qdec events and
optionally a button and relay the input_event to lvgl.
Signed-off-by: Fabian Blatz <fabianblatz@gmail.com>
Initial version of Infineon CAT1 SPI Driver supporting synchronous
and asynchronous data transfer API
Signed-off-by: Sreeram Tatapudi <sreeram.praveen@infineon.com>
Add devicetree binding for the TI TCAN4x5x series of CAN controllers. These
CAN controllers are based on the Bosch M_CAN IP and interfaced via a SPI
bus.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Create dac_mcxu_lpdac.c file to implement mcux lpdac, add binding for
the mcux lpdac, update Kconfig.mcux and CMakeLists.txt file to support
mcux lpdac.
Signed-off-by: Albort Xue <yao.xue@nxp.com>
The Nuvoton NCT38xx is a multi-function device providing a TCPC
controller and a I/O expander (GPIO driver). Add a multi-function
driver to manage exclusive access to the device.
Tested with "twister -T tests/drivers/build_all/gpio".
Signed-off-by: Keith Short <keithshort@google.com>
Seems like the SSD1306 controller needs a bit of time after power up
before it can take i2c commands. This causes problems with
microcontrollers that have no other delays in the startup sequence, like
rpi_pico.
There's currently no good way of modeling this in Zephyr right now, and
there's also no clear indication of how much time the device needs in
the datasheet that I could find, but it seems like 10ms is enough for
that to start reliably so add a delay in the ssd1306 init function to
ensure that at least that time has passed from system power up.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Remove `threshold-reg-offset` DT property and implement them with static
inline functions in `reg_def.h`
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Add `thr-sel` prop. to select the relevant threshold register for adc
comparator since there're two adc modules in npcx4 series.
Signed-off-by: Kate Yen <htyen@nuvoton.com>
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Add multi-device support in npcx adc driver since there is more than one
adc module in npcx4 series. And each adc's reference voltage might be
different, this CL introduces the `vref-mv` prop. to select its own
reference voltage.
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Signed-off-by: Kate Yen <htyen@nuvoton.com>
