The fuel gauge API uses separate get/set property structs to indicate what
properties are readable or writable. This lead to duplication in property
names and potential confusion for new users of the API. See issue #61818.
In addition to above, drivers already determine at runtime if a property is
supported for read or write actions.
Join the get/set fuel gauge property structs as a single struct.
Signed-off-by: Aaron Massey <aaronmassey@google.com>
There's no need to use APPLICATION level. Also create a custom init
level that runs late in the process (depends e.g. on SPI which runs at
high priority level, 70).
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.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 wrapper functions for Xen memory managment hypercall. They can be
used for unprivilaged Zephyr guest initialization and for domain
management, when Zephyr is used as Xen Domain 0.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
This commit adds possibility to call hypervisor HVM parameter functions
for specified domain (instead of only DOMID_SELF). It is needed for
configuring domains, that were created from Zephyr control domain.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Add Xen domctl API implementation for Zephyr as control domain.
Previously Zephyr OS was used as unprivileged Xen domain (Domain-U),
but it also can be used as lightweight Xen control domain (Domain-0).
To implement such fuctionality additional Xen interfaces are needed.
One of them is Xen domain controls (domctls) - it allows to create,
configure and manage Xen domains.
Also, used it as a possibility to update files copyright and licenses
identifiers in touched files.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
This commit adds interface for evtchn allocation that can be used by
privilaged domain. Domain 0 can specify both dom and remote_dom
parameters for hypercall, where in others domains dom should be always
DOMID_SELF. It is needed for creating pre-defined channels during
domain setup in Zephyr Dom0.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Xen-related Kconfig options were highly dependand on BOARD/SOC xenvm.
It is not correct because Xen support may be used on any board and SoC.
So, Kconfig structure was refactored, now CONFIG_XEN is located in
arch/ directory (same as in Linux kernel) and can be selected for
any Cortex-A arm64 setup (no other platforms are currently supported).
Also remove confusion in Domain 0 naming: Domain-0, initial domain,
Dom0, privileged domain etc. Now all options related to Xen Domain 0
will be controlled by CONFIG_XEN_DOM0.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Move memory mapping of Xen node to Grant Table driver system init
function. After moving mapping we don't need anymore records of
xen-xen node into 'mmu_regions' array, so they were deleted from
all SoCs: Rcar Gen3/Gen4 and XenVM.
We need at least 16M of virtual address space to map memory of Xen
node, so the virtual memory sized has been increased to 32 MB, it
should be enough for basic use-cases and mapping of 16M mem region
of Xen node.
Unfortunately, after moving we also need to increase number of XLAT
tables. The previous code was more efficient if we talking about
usage of XLAT tables, because it mapped grant tables using a higher-
order table that allows mapping blocks of 2MB. And after the changes
is maps every 4KB page, so we need more XLAT tables.
Increase number of grant frames, it is needed to sync stage 1 and stage 2
memory mappings, previously we map only one page on stage 2 and further
usage of unmap regions can cause MMU translation errors.
Perform mapping stage 1 before mapping for stage 2 (add to physmap),
because right after stage 1 we can try to access memory and if it is
unmap in stage 2, error will be received during translation.
Note: Xen Grant Table driver doesn't use Zephyr Device Model.
Authored-by: Mykola Kvach <mykola_kvach@epam.com>
Co-authored-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Add RSU UPDATE function id in sip_svc to set the RSU UPDATE
ADDRESS in sip_svc_v2 for Intel Agilex SOCFPGA platform.
Signed-off-by: Mahesh Rao <mahesh.rao@intel.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>
Add all available instances of the ADC series
MAX11102-MAX11117 to the ADC shell.
Signed-off-by: Benedikt Schmidt <benedikt.schmidt@embedded-solutions.at>
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>
The ipm_cavs_idc driver was used with the old intel_s1000
board which has been removed. On the audio DSP side,
the IDC under CAVS is being handled by SoC layer code.
Now the ipm_cavs_idc is not needed anymore for anything.
So remove it.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Support connecting different display for each SPI and I2C
at the same time.
In a case like DTS below.
```
&spi1 {
ssd1306_spi: ssd1306@0 {
compatible = "solomon,ssd1306fb";
...
};
};
&i2c0 {
ssd1306_i2c: ssd1306@3c {
compatible = "solomon,ssd1306fb";
...
};
};
```
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.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>
Store properties defined in dts in ssd1306_config's fields.
And replace code that uses DT_INST_PROP (0, ...) by config properties.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>
Split the native tty serial driver in a top and bottom to enable using it
with embedded libCs.
Signed-off-by: Marko Sagadin <marko.sagadin42@gmail.com>
Update single phase bit in register when changing data->qdec_config.
Otherwise the changed settings has no effect.
Signed-off-by: Jeppe Odgaard <jeppe.odgaard@prevas.dk>
The Cadence I3C was not building with CONFIG_I3C_USE_IBI, this fixes
the build and will give a small code size reduction when enabled.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
If a transfer happen in rapid sucession. It was possible for
the core to not be ready to accept another command. Poll on
the idle status bit until the core is ready to accept new data.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
Due to a bug, after a completed transfer happen. Only the first
command response error was read. This fixes the issue so all
commands are read for if an error occurred.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.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>
Fix another i2c_dump_msgs_rw:
/drivers/fuel_gauge/bq27z746/emul_bq27z746.c:282:26: warning: passing
argument 1 of ‘i2c_dump_msgs_rw’ from incompatible pointer type
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Zephyr version 3.4 changed the SPI context structure and macros
which broke the logic in the MEC172x SPI driver configuration API.
This was not detected by CI due to no tests for this driver are in
the tree. The driver now behaves like most other SPI drivers requiring
a different configuration structure pointer to be passed if any item
in the configuration changes.
Signed-off-by: Manimaran A <manimaran.a@microchip.com>
Enable PM on STM32 entropy driver.
Only supports PM_DEVICE for now, runtime support will be added later.
Signed-off-by: Erwan Gouriou <erwan.gouriou@st.com>
