Removed statement about the QoS having to be symmetrical
for two streams using the same CIS, as that requirement
was recently removed.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The toolchain support was developed and tested against arm clang
version 6.17. So add a check to ensure we are utilizing 6.17 or
newer.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
`bt_id_create` does not accept public addresses, but the phrasing that
is removed in this change can be interpreted as "replace the public
address with a different public address". This was confusing users, so
it will be removed.
The intended meaning of the original sentence may have been "use the
provided address for BT_ID_DEFAULT, instead of using the public
address". Amending the sentence to something like that was considered.
But, there was no consensus on the usefulness of this addition, so it
was left out for brevity.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
If an event with corrupted length arrives, the extra check makes the
handler return early to avoid reading data out of bounds.
Signed-off-by: Arkadiusz Kozdra <akozdra@antmicro.com>
Fixes a segfault if a discovery event happens while discovery is not
active and the discovery callback is null.
Signed-off-by: Arkadiusz Kozdra <akozdra@antmicro.com>
Fix spiram WP_SD3 pin reference as that should be checked from efuse
values in case no customized number is set.
Fixes#54005
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Update ESP32-C3 architecture as IMC instead IMA.
Although not documented, ESP32-S3 supports CSR instructions.
It also needs to be enabled, otherwise build will fail.
Fixes#53555
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
This change produces more quickly in the stream valid
audio samples. The start fade-in ramp can be shortened to
100 ms for 48 kHz and 200 ms for 16 kHz. It was before 200 ms
and 400 ms. The updated DMIC hardware in allows to do this
change.
Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@intel.com>
Rework the Host Command support. It includes:
-change API to backend
-change a way of defining rx and tx buffers
-fix synchronization between the handler and backend layer
-simplify the HC handler
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
Follow naming pattern in the subsystems(logging or shell) and name
the layer between generic handler and peripheral driver "backend".
The name doesn't suit that well to the SHI backend, because there isn't
SHI API itself and the SHI interface is used only for the host
communication. So the backend code includes the peripheral driver itself.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
The Host Commands can be used with different transport layers e.g. SHI
or eSPI. The code that provides the peripheral API and allows sending
and receiving Host Commands via different transport layers is not
actually drivers of a peripheral, so move it to the
subsys/mgmt/ec_host_cmd folder.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
Check if device runtime is enabled in the beginning of
runtime_suspend to avoid unnecessary checks.
This does not change the current behavior.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Check if device runtime is enabled in the beginning of
pm_device_runtime_get to avoid unnecessary checks.
This does not change the current behavior.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Use client context to seperate buffer usage.
Use new `TFTP_EVT_DATA` event to send data to application.
Use new `TFTP_EVT_ERROR` event to report error to application.
Update `tftp_get()` and `tftp_put()` API to use the client context.
Signed-off-by: Jun Qing Zou <jun.qing.zou@nordicsemi.no>
This adds the runner arguments for dfu-util to the longan_nano board,
to allow flashing via DFU in addition to openocd.
Signed-off-by: Jonas Otto <jonas@jonasotto.com>
For RISCV arch, enable FLASH_SIZE and FLASH_BASE_ADDRESS config.
To avoid duplicated work, remove flash config from RISCV soc.
Signed-off-by: Jonas Otto <jonas@jonasotto.com>
Zephyr supports ADCs with 16-bit resolution, but the ADC sample
displayed readings for such incorrectly due to too-small datatype
This commit fixes the ADC sample for ADCs with 16-bit resolution
Signed-off-by: Ben Marsh <ben.marsh@helvar.com>
Drop the non existing option PINMUX_XEC, this has been removed in
d76f4f2c8a drivers: pinmux: mchp_xec: drop driver
And is currently causing build errors.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
This will make it more convenient to use it from multiple different
places, which we will have a need for in the future.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
We need to have an _include_path attribute to pretty-print
this object from within pdb, for some reason. Add it.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
There's no need for _parse_node() to return the Node instance that is
its sole argument. The only user of the return value is a dead store.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This helper lets you place a node (really the entire subtree rooted at
that node) elsewhere in the devicetree. This will be useful when
adding system devicetree support, when we'll want to be able to, for
example, move the CPU cluster node selected by the current execution
domain to /cpus.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Introduce a context manager that will save some typing
when dealing with expected exceptions.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The image header is compatible for zImage(32) protocol.
Offset Value Description
0x24 0x016F2818 Magic number to identify ARM Linux zImage
0x28 start address The address the zImage starts at
0x2C end address The address the zImage ends at
As Zephyr can be built with a fixed load address, Xen/Uboot can read
the image header and decide where to copy the Zephyr image.
Also, it is to be noted that for AArch32 A/R, the vector table should
be aligned to 0x20 address. Refer ARM DDI 0487I.a ID081822, G8-9815,
G8.2.168, VBAR, Vector Base Address Register :-
Bits[4:0] = RES0.
For AArch32 M (Refer DDI0553B.v ID16122022, D1.2.269, VTOR, Vector Table
Offset Register), Bits [6:0] = RES0.
As zImage header occupies 0x30 bytes, thus it is necessary to align
the vector table base address to 0x80 (which satisfies both VBAR and
VTOR requirements).
Also, it is to be noted that not all the AArch32 M class have VTOR, thus
ARM_ZIMAGE_HEADER header depends on
CPU_AARCH32_CORTEX_R || CPU_AARCH32_CORTEX_A || CPU_CORTEX_M_HAS_VTOR.
The reason being the processors which does not have VBAR or VTOR, needs
to have exception vector table at a fixed address in the beginning of
ROM (Refer the comment in arch/arm/core/aarch32/cortex_m/CMakeLists.txt)
. They cannot support any headers.
Also, the first instruction in zImage header is to branch to the kernel
start address. This is to support booting in situations where the zImage
header need not be parsed.
In case of Arm v8M, the first two entries in the reset vector should be
"Initial value for the main stack pointer on reset" and "Start address
for the reset handler" (Refer Armv8M DDI0553B.vID16122022, B3.30,
Vector tables).
In case of Armv7M (ARM DDI 0403E. ID021621, B1.5.3 The vector table),
the first entry is "SP_main. This is the reset value of the Main stack
pointer.".
Thus when v7M or v8M starts from reset, it expects to see these values
at the default reset vector location.
See the following text from Armv7M (ARM DDI 0403E. ID021621, B1-526)
"On powerup or reset, the processor uses the entry at offset 0 as the
initial value for SP_main..."
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
This commit finish to fix the bug describe by 85e2a0679a68f02f7ef.
With the previous correction, the uptime read could be in the past:
if the counter rewinds just after testing ARRM flag, we had lost
some counts.
Signed-off-by: Julien D'Ascenzio <julien.dascenzio@paratronic.fr>
Change the dtsi order for the stm32L4plus serie,
starting with stm32l4p5-stm32l4q5 and stm32l4r5-stm32l4s5
Significant changes are on the SRAM size, the sdmmc2
and separated RTC-bbram registers.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
The SRAM1(total 192 KBytes) plus SRAM2: (total 64 KBytes)
plus SRAM3(total 512 KBytes) is available from 0x20000000 to
0x200BFFFF.
The SRAM size is only 768KB at address 0x20000000
The 16KB SRAM4 is located at address 0x28000000 so that no ram
is present from 0x200c0000 to 0x28000000.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
