Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[nrf fromlist] Bluetooth: Controller: Allow 0 ISO TX/RX buffer count #1527

Closed
wants to merge 1,500 commits into from

Conversation

yuxCai
Copy link
Contributor

@yuxCai yuxCai commented Feb 23, 2024

Upstream PR: zephyrproject-rtos/zephyr#69382

There is no need to allocate TX/RX buffers when the device is an receiver/transmitter only.

gmarull and others added 30 commits February 8, 2024 12:12
Add a new operation that allows erasing pages.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
(cherry picked from commit a99b5ca)
…r nRF54H series

Add basic support to flash application and/or radio core for nRF54H
series. Note that features like merged hexes present in nRF53 series is
not supported.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
(cherry picked from commit 6b987d3)
Add targets that allows building for the Application and Radio cores
in the nRF54H20 SoC on the nRF54H20 PDK board.

Signed-off-by: Grzegorz Swiderski <[email protected]>
Signed-off-by: Gerard Marull-Paretas <[email protected]>
Signed-off-by: Andrzej Głąbek <[email protected]>
(cherry picked from commit 38520a9)
Similar to nRF54L15, the MDK files in HAL for this SoC are not
compatible with C++98, so currently the test cannot be performed
on this SoC.

Signed-off-by: Andrzej Głąbek <[email protected]>
(cherry picked from commit 00566d6)
…iant

Add STRUCT_SECTION_ITERABLE_NAMED_ALTERNATE() for structures
ordered by name in a custom section.

Signed-off-by: Christopher Friedt <[email protected]>
(cherry picked from commit 903f628)
Add tests for the newly added
STRUCT_SECTION_ITERABLE_NAMED_ALTERNATE(). This type of
section should be iterated with
STRUCT_SECTION_FOREACH_ALTERNATE().

Signed-off-by: Christopher Friedt <[email protected]>
(cherry picked from commit 28dccf2)
Add support for mutable devices. Mutable devices are those which
can be modified after declaration, in-place, in kernel mode.

In order for a device to be mutable, the following must be true

  * `CONFIG_DEVICE_MUTABLE` must be y-selected
  * the Devicetree bindings for the device must include
    `mutable.yaml`
  * the Devicetree node must include the `zephyr,mutable` property

Signed-off-by: Christopher Friedt <[email protected]>
(cherry picked from commit afc5911)
The Device Multiplexer (devmux) is a pseudo-device that can
be used to select between multiple included sub-devices.

It is experimental, but its current use is in system
remediation. Take for example, the scenario where the
system console and log subsystem both have the uart backend
enabled. The case may arise, where the chosen backing uart
could be an abstraction of another very high-bandwidth bus
- such as a PCIe BAR, a UDP socket, or even even just memory.

If the "service" (for lack of a better term) that backs this
abstract "uart" experiences an error, it is of critical
importance to be able to switch the system console, uart log
backend, or whatever to another uart (semi-transparently) in
order to bring up a shell, continue to view system logs, or
even just support user console I/O.

Signed-off-by: Christopher Friedt <[email protected]>
(cherry picked from commit 37e1945)
This testsuite exercises a number of things. Namely

  * `mutable` devices (i.e. those backed in SRAM)
  * `uart_emul` support for interrupt mode (receive only)
  * `devmux` capabilities of multiplexing several uarts
  * switching the system console between several uart backends

Testing Done:
```
west build -p auto -b qemu_riscv64 -t run \
  tests/drivers/console_switching/
...
*** Booting Zephyr OS build zephyr-v3.4.0-3988-gaaefb2d764ea ***
Running TESTSUITE console_switching
================================================================
START - test_read
read "Hello, uart_emul0!" from uart_emul0
read "Hello, uart_emul1!" from uart_emul1
read "Hello, uart_emul0!" from uart_emul0
read "Hello, uart_emul1!" from uart_emul1
 PASS - test_read in 0.005 seconds
================================================================
START - test_write
wrote "Hello, uart_emul0!" to uart_emul0
wrote "Hello, uart_emul1!" to uart_emul1
wrote "Hello, uart_emul0!" to uart_emul0
wrote "Hello, uart_emul1!" to uart_emul1
 PASS - test_write in 0.003 seconds
================================================================
TESTSUITE console_switching succeeded

------ TESTSUITE SUMMARY START ------

SUITE PASS - 100.00% [console_switching]: pass = 2, fail = 0,...
 - PASS - [console_switching.test_read] duration = 0.005 seconds
 - PASS - [console_switching.test_write] duration = 0.003 seconds

------ TESTSUITE SUMMARY END ------

===============================================================
PROJECT EXECUTION SUCCESSFUL
```

Signed-off-by: Christopher Friedt <[email protected]>
(cherry picked from commit b13ec70)
The init_entry struct got modified to add a union with a non const dev
pointer in afc5911. Some old compiler (such as GCC 4) seems to
require a pair of brackets to correctly initialize the field in the
union. Add those brackets to the initializers in device.h and init.h to
maintain compatibility.

Signed-off-by: Fabio Baltieri <[email protected]>
(cherry picked from commit 153f38a)
Add a custom driver that takes care of loading and launching RISC-V VPR
cores found on the new nRF54 SoCs.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
(cherry picked from commit d1468b8)
Add a new snippet that allows to build any application with the
capability to boot the PPR core found in some nRF54 SoCs.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
(cherry picked from commit 245da8a)
As it is not required (e.g. RISC-V nRF54H port does not provide soc.h)

Signed-off-by: Gerard Marull-Paretas <[email protected]>
(cherry picked from commit d230542)
…core

Add nrfx configuration file to make the nrfx HAL work for
nRF54H PPR core.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
Signed-off-by: Andrzej Głąbek <[email protected]>
(cherry picked from commit 270ae63)
…ddr_int|hex

dt_chosen_partition_addr_int|hex allow obtaining the absolute address of
a partition, which is the result of the grandparent node address plus
the partition node address.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
(cherry picked from commit 018cf08)
…n dir

Because both, RISC-V and ARM cores share the same pinctrl driver. The
top level common folder will disappear with the introduction of HWMv2,
where multi-arch SoCs will be well supported.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
(cherry picked from commit d7dc942)
…on folder

Because RISC-V cores also need to include this file, so it is no longer
ARM specific.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
(cherry picked from commit 1a6b886)
Add initial support for the VPR RISC-V core found in the new nRF54 SoCs.

Signed-off-by: Carlo Caione <[email protected]>
Signed-off-by: Gerard Marull-Paretas <[email protected]>
(cherry picked from commit ba16e3d)
Add support for the nRF54H PPR (Peripheral Processor), based on the VPR
RISC-V core.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
(cherry picked from commit 426bbf5)
Add a board that allows to build for the nRF54H20 PPR RISC-V core.

Signed-off-by: Grzegorz Swiderski <[email protected]>
Signed-off-by: Gerard Marull-Paretas <[email protected]>
(cherry picked from commit 117194a)
…figuration API

First, the API ops are available only if
CONFIG_UART_USE_RUNTIME_CONFIGURE=y, but the driver was not guarding the
code. Also, according to the API specs, these functions are optional,
and the interface already returns -ENOSYS if they are not implemented.
To solve both problems, just drop the dummy implementation.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
(cherry picked from commit b548a73)
…-bits

Unlike SPI nodes, I2C nodes (i2c20, i2c21, i2c22 and i2c30) did not have
this required property.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
(cherry picked from commit bf4a021)
This reverts commit 780b128.
"drivers: ieee802154: nrf: cache radio channel"

Implementation affected RCP devices in openthread as MAC layer
does not call `Receive()` functions after transmit is done.

Additionally, after sending a frame to a new channel (for example
while discovery operation), radio switches to RX state immediately
after TX, but continues to listen on old channel for about 5ms,
until MAC layer calls `Receive` operation, forcing to change the
channel.

Signed-off-by: Maciej Baczmanski <[email protected]>
(cherry picked from commit dbe74b3)
- Fix bug where status was only sent for legacy adv

Signed-off-by: Alexander Svensen <[email protected]>
(cherry picked from commit 199487b)
Signed-off-by: Alexander Svensen <[email protected]>
* Update the HW models module to
c744f2c762aad79e59bd7e99002f2fcab0a2f288

Including the following:
* docs: UART: several minor fixes
* UART(E): Add peripherals and connect to (D)PPI

Signed-off-by: Alberto Escolar Piedras <[email protected]>
(cherry picked from commit 85d3ad1)
Signed-off-by: Ivan Iushkov <[email protected]>
* Update the HW models module to
a08acc7d3a853f890df2bf82167c02ab2153ffe7

Including the following:
* a08acc7 UART(E): Duty cycle warnings due to Rx while Rx Off
* aa1f38d UART(E): FIFO backend Minor bugfix
* 8b0819f UART(E): Add Loopback backend
* bc648f2 UART(E): Update RTS pin level as soon as the conf is changed
* b39e448 UART(E): Detect receiver opening mid frame

Signed-off-by: Alberto Escolar Piedras <[email protected]>
(cherry picked from commit 992c04c)
Signed-off-by: Ivan Iushkov <[email protected]>
* Update the HW models module to
6b6ae3652c92c95edd945dce6ad9ef9892aab89b

Including the following:
* 6b6ae36 UART: Minor optimization
* afe84c1 fake timer: Minor speed optimization for nrf52
* a5a4dfd RTC: Fix counter value when CLEAR after STOP

Signed-off-by: Alberto Escolar Piedras <[email protected]>
(cherry picked from commit 33d4b6d)
Signed-off-by: Ivan Iushkov <[email protected]>
* Update the HW models module to
d17c9d749c817d2522468fa3c0eee3705feb8951

Including the following:
* d17c9d7 UART: Bugfix: Support STARTRX while Rx is stopping
* d982e76 UART: Minor bugfix: Fix 2 warning messages
* eda7af9 UART: Bugfix: Handle task STOPTX while stopping
* b8ea63b UART: BugFix: Support STARTTx even if Tx is not Off
* c0d28cc nrf_common: Add replacement for nrf_dma_accessible_check()
* feb91bb nrfx_common replacement: nrfx_get_irq_number() Add missing peri
* c95d9af Makefile: By default lets build both 52833 and 5340 targets
* cf41110 UART: FIFO backend: Check for failure of fcntl

Signed-off-by: Alberto Escolar Piedras <[email protected]>
(cherry picked from commit c9d489d)
Signed-off-by: Ivan Iushkov <[email protected]>
* Update the HW models module to
52d0b4b7b7431d8da6222cc3b17a8afdcb099baf

Including the following:
* 52d0b4b UART: FIFO backend: Do not error out if other side disconnects Rx
* 3582b68 UART: FIFO backend: Avoid possible race
* 414f160 AAR: Fix UBSAN warnings
* 24f5d3d PPI: Fix UBSAN warning

Signed-off-by: Alberto Escolar Piedras <[email protected]>
(cherry picked from commit 189d4d4)
Signed-off-by: Ivan Iushkov <[email protected]>
…n adv.c/scan.c

during local testling, UBSAN reported the following warnings:
- bluetooth/host/adv.c:2067:19: runtime error: shift exponent
255 is too large for 32-bit type 'long unsigned int'
- bluetooth/host/scan.c:828:18: runtime error: shift exponent
255 is too large for 32-bit type 'long unsigned int'

It turned out that we can't use BIT() macro directly on
bt_hci_evt_le_per_advertising_report::cte_type field.
According to Core Spec, `cte_type = 0xFF` corresponds
to `No contstant tone extension`.

Added separate function to convert CTE bit field from
HCI format to bt_df_cte_type
Signed-off-by: Ivan Iushkov <[email protected]>
(cherry picked from commit b1e9f86)
Signed-off-by: Ivan Iushkov <[email protected]>
@yuxCai yuxCai changed the title [nrf fromlist] Bluetooth: Controller: Allow setting ISO TX/RX buffer count to 0 [nrf fromlist] Bluetooth: Controller: Allow 0 ISO TX/RX buffer count Feb 23, 2024
Copy link
Contributor

@cvinayak cvinayak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Refer to reviews upstream

Upstream PR: zephyrproject-rtos/zephyr#69382

There is no need to allocate TX/RX buffers when the device is an receiver/transmitter only.

Signed-off-by: Yuxuan Cai <[email protected]>
Copy link
Contributor

@Thalley Thalley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.