-
Notifications
You must be signed in to change notification settings - Fork 6.7k
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
modules: hal_nordic: Add multi-instance DPPI and PPIB drivers #79857
Conversation
The following west manifest projects have changed revision in this Pull Request:
✅ All manifest checks OK Note: This message is automatically posted and updated by the Manifest GitHub Action. |
can you switch to zephyrproject-rtos/hal_nordic#232 ? |
40c536f
to
d13657a
Compare
The new nrfx_ppib driver can now be enabled, when the corrensponding device tree node has the okay status. Upstream PR: zephyrproject-rtos/zephyr#79857 Signed-off-by: Rafał Kuźnia <[email protected]>
The resource reservation definitions were moved to a separate header file. The PPIB and DPPI channel and group resources can now be statically allocated for each individual instance. Upstream PR: zephyrproject-rtos/zephyr#79857 Signed-off-by: Rafał Kuźnia <[email protected]>
The nrfx_gppi module is an abstraction over nrfx_ppi and nrfx_dppi drivers. It now has a Kconfig option that is separate from nrfx_dppi and by default it enables all PPI/DPPI instances, if available. Upstream PR: zephyrproject-rtos/zephyr#79857 Signed-off-by: Rafał Kuźnia <[email protected]>
#if defined(NRF53_SERIES) | ||
#define NRFX_DPPI0_CHANNELS_USED_BY_BT_CTLR BT_CTLR_USED_PPI_CHANNELS | ||
#define NRFX_DPPI0_GROUPS_USED_BY_BT_CTLR BT_CTLR_USED_PPI_GROUPS | ||
#elif defined(LUMOS_XXAA) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about replacing LUMOS_XXAA
with NRF54L_SERIES
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nika-nordic should LUMOX_XXAA
or NRF54L_SERIES
be preferred?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NRF54L_SERIES
is definitely better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll make a follow-up commit after this PR is merged.
* are to be built. | ||
*/ | ||
#if defined(CONFIG_BT_LL_SW_SPLIT) | ||
#include <bt_ctlr_used_resources.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please have a look here
https://github.com/nrfconnect/sdk-nrfxlib/blob/main/softdevice_controller/include/sdc_soc.h
Shouldn't it be here
#include <sdc_soc.h>
?
Because of that shouldn't we use macros SDC_xxxx_CHANNELS_USED_MASK
when defining
NRFX_xxxx_CHANNELS_USED_BY_xxxx
below ?
https://github.com/nrfconnect/sdk-nrfxlib/blob/main/softdevice_controller/include/sdc_soc.h#L40-L43
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This won't be added in upstream.
#define NRFX_PPI_GROUPS_USED_BY_BT_CTLR BT_CTLR_USED_PPI_GROUPS | ||
#endif /* defined(DPPI_PRESENT) */ | ||
#endif /* defined(CONFIG_BT_LL_SW_SPLIT) */ | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about including
https://github.com/nrfconnect/sdk-nrfxlib/blob/main/mpsl/include/mpsl.h
and providing
NRFX_xxxxxx_CHANNELS_USED_BY_MPSL
based on MPSL_xxxx_CHANNELS_USED_MASK
https://github.com/nrfconnect/sdk-nrfxlib/blob/main/mpsl/include/mpsl.h#L51-L54
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This won't be added in upstream.
The hal_nordic revision was updated to bring in NRFX v3.8.0. Aligned the uses of single-instance API to use multi-instance instead. Upstream PR: zephyrproject-rtos/zephyr#79857 Signed-off-by: Rafał Kuźnia <[email protected]>
Added a binding description for the PPIB peripheral and added the device tree nodes of the PPIB instances to the nRF54L15 and nRF54L20. Upstream PR: zephyrproject-rtos/zephyr#79857 Signed-off-by: Rafał Kuźnia <[email protected]>
The new nrfx_ppib driver can now be enabled, when the corrensponding device tree node has the okay status. Upstream PR: zephyrproject-rtos/zephyr#79857 Signed-off-by: Rafał Kuźnia <[email protected]>
The resource reservation definitions were moved to a separate header file. The PPIB and DPPI channel and group resources can now be statically allocated for each individual instance. Upstream PR: zephyrproject-rtos/zephyr#79857 Signed-off-by: Rafał Kuźnia <[email protected]>
The nrfx_gppi module is an abstraction over nrfx_ppi and nrfx_dppi drivers. It now has a Kconfig option that is separate from nrfx_dppi and by default it enables all PPI/DPPI instances, if available. Upstream PR: zephyrproject-rtos/zephyr#79857 Signed-off-by: Rafał Kuźnia <[email protected]>
@e-rk zephyrproject-rtos/hal_nordic#232 merged, please update SHA |
The hal_nordic revision was updated to bring in NRFX v3.8.0. Aligned the uses of single-instance API to use multi-instance instead. Signed-off-by: Rafał Kuźnia <[email protected]>
Added a binding description for the PPIB peripheral and added the device tree nodes of the PPIB instances to the nRF54L15 and nRF54L20. Signed-off-by: Rafał Kuźnia <[email protected]>
The new nrfx_ppib driver can now be enabled, when the corrensponding device tree node has the okay status. Signed-off-by: Rafał Kuźnia <[email protected]>
The resource reservation definitions were moved to a separate header file. The PPIB and DPPI channel and group resources can now be statically allocated for each individual instance. Signed-off-by: Rafał Kuźnia <[email protected]>
The nrfx_gppi module is an abstraction over nrfx_ppi and nrfx_dppi drivers. It now has a Kconfig option that is separate from nrfx_dppi and by default it enables all PPI/DPPI instances, if available. Signed-off-by: Rafał Kuźnia <[email protected]>
The nrfx_gppi module is an abstraction over nrfx_ppi and nrfx_dppi drivers. It now has a Kconfig option that is separate from nrfx_dppi and by default it enables all PPI/DPPI instances, if available. Upstream PR: zephyrproject-rtos/zephyr#79857 Signed-off-by: Rafał Kuźnia <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, a few nitpicking comments only.
@@ -107,13 +107,14 @@ static void ppi_rtc_to_ipc(union rtc_sync_channels channels, bool setup) | |||
/* Free DPPI and RTC channels */ | |||
static void free_resources(union rtc_sync_channels channels) | |||
{ | |||
nrfx_dppi_t dppi = NRFX_DPPI_INSTANCE(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not define this as static const
at the top of the file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This approach was suggested here: nrfconnect/sdk-nrf#18073 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't quite get how that justification given in the above comment applies to this case, but my point is that static const
would cause that this structure ends up in flash, so this would give some savings on its initialization that now needs to be performed at runtime and twice in this file. But it's just a detail. I'm not going to insist on changing this.
@@ -387,15 +387,17 @@ static int ppi_setup(const struct device *dev, uint8_t chan) | |||
|
|||
nrfy_rtc_event_enable(rtc, NRF_RTC_CHANNEL_INT_MASK(chan)); | |||
#ifdef DPPI_PRESENT | |||
result = nrfx_dppi_channel_alloc(&data->ppi_ch); | |||
nrfx_dppi_t dppi = NRFX_DPPI_INSTANCE(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be nice to add a comment that instance 0 is used here because COUNTER_RTC_WITH_PPI_WRAP
is currently only supported for nRF51/52/53/91 Series.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll try to add this in a follow up commit.
|
||
config NRFX_DPPI0 | ||
bool "DPPI0 driver instance" | ||
depends on $(dt_nodelabel_has_compat,dppic,$(DT_COMPAT_NORDIC_NRF_DPPIC)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that for consistency it would be good to use ddpic0
here and add such node label to nodes labeled as dppic
, like it is done for wdt0
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm reluctant to changing labels of nodes that existed for years, as it might break compatibility somewhere for no good reason really.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can extend the existing nodelabel like this:
dppic0: dppic: dppic {
...
};
in devicetree and update NRFX_DPPI0
to
depends on ($(dt_nodelabel_has_compat,dppic,$(DT_COMPAT_NORDIC_NRF_DPPIC)) || \
$(dt_nodelabel_has_compat,dppic0,$(DT_COMPAT_NORDIC_NRF_DPPIC)))
to keep backward compatibility
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't suggested changing a label but adding another one: dppic: dppic0: dppic@...
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll address this in a follow up commit then. I want to avoid adding more changes here, as it will block further activities related to nrfx v3.9.
@@ -101,7 +101,7 @@ zephyr_library_sources_ifdef(CONFIG_SOC_SERIES_NRF92X ${MDK_DIR}/system_nrf92.c | |||
zephyr_library_sources(nrfx_glue.c) | |||
zephyr_library_sources(${HELPERS_DIR}/nrfx_flag32_allocator.c) | |||
zephyr_library_sources_ifdef(CONFIG_RETAINED_MEM_NRF_RAM_CTRL ${HELPERS_DIR}/nrfx_ram_ctrl.c) | |||
zephyr_library_sources_ifdef(CONFIG_NRFX_DPPI ${HELPERS_DIR}/nrfx_gppi_dppi.c) | |||
zephyr_library_sources_ifdef(CONFIG_NRFX_GPPI ${HELPERS_DIR}/nrfx_gppi_dppi.c) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not seem to be necessary/beneficial.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you elaborate? Do you mean that CONFIG_NRFX_GPPI
kconfig is not beneficial or something else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NRFX_GPPI
enables NRFX_DPPI
, so the change is not really needed. But it causes that nrfx_gppi_dppi.c
will be compiled also for NRFX_PPI
, unnecessarily.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is possible to enable NRFX_DPPI without enabling any GPPI functionality now. Also NRFX_GPPI does more, as it is unified across the SoC families. Regardless of whether working with nRF52 or nRF54L or anything else, NRFX_GPPI will enable everything that's needed.
I just noticed that that NRFX_PPI
in the next line should be replaced with NRFX_GPPI
as well. I'll add this subsequent commit as well, if you don't mind.
#if defined(NRF53_SERIES) | ||
#define NRFX_DPPI0_CHANNELS_USED_BY_BT_CTLR BT_CTLR_USED_PPI_CHANNELS | ||
#define NRFX_DPPI0_GROUPS_USED_BY_BT_CTLR BT_CTLR_USED_PPI_GROUPS | ||
#elif defined(LUMOS_XXAA) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NRF54L_SERIES
is definitely better.
Added multi-instance DPPI driver and a new PPIB driver.