soc: nordic: nrf53: SOC_NRF53_CPUNET_ENABLE should not depend on !BT #79875
Conversation
zephyrbot
requested review from
anangl,
jaz1-nordic,
kl-cruz,
magp-nordic,
masz-nordic and
nika-nordic
sean-madigan
force-pushed
the
initialise_net_core_with_bt
branch
from
e28fa9c to
10f4857
Compare
… depend on !BT This causes issues as we still want the net core to be set up on initialisation if CONFIG_BT is enabled in many cases. The previous changes in zephyrproject-rtos/zephyr#74304 assumed that because this is also handled in `bt_hci_transport_setup` that it shouldn't be done on initialisation too. Also, I think that `bt_hci_transport_setup` should not be even controlling the network core state like it is currently and should be looked at being changed in a future PR. Upstream PR: zephyrproject-rtos/zephyr#79875 Signed-off-by: Sean Madigan <sean.madigan@nordicsemi.no>
Please create a GH issue to follow up, so that this request is not lost in the future... or do you already have PR you can link here? |
soc/nordic/nrf53/Kconfig
Outdated
There was a problem hiding this comment.
this is deprecated, why is it being changed?
There was a problem hiding this comment.
I'm trying to restore it's functionality to the commit before it was deprecated
There was a problem hiding this comment.
are you aware that this will be removed at some point because it is deprecated? Does all code ported to the new order work without any changes?
There was a problem hiding this comment.
This kconfig is not used anywhere. So it is fine we change it here or leave it.
soc/nordic/nrf53/Kconfig
Outdated
There was a problem hiding this comment.
this should not be needed: BT already enables cpunet core. Any out of tree code should be adapted accordingly.
There was a problem hiding this comment.
An example where we require 53 cpunet on boot with bluetooth - a multiprotocol application where I want to run another protocol on the cpunet before enabling bluetooth.
Also I do not believe bluetooth driver open/close should control cpunet state and if either of these should change it should be removed from this, rather than on boot. (However, this will require more work and for now I suggest keeping it how it was, with boot on init and on bt driver open)
There was a problem hiding this comment.
then, why doesn't this code request cpunet as BT code does? As I understand it, cpunet just needs to be booted once by the first requester, turned off by the last releaser. This is why the soc API is ref counted.
There was a problem hiding this comment.
also, what will happen once this deprecated option is removed?
There was a problem hiding this comment.
SOC_NRF53_CPUNET_ENABLE is not being deprecated is it, so this can be used
There was a problem hiding this comment.
@gmarull can we proceed this PR? waiting for it integrated to 2.8
The previous changes in zephyrproject-rtos#74304 assumed that because this is also handled in `bt_hci_transport_setup` that it shouldn't be done on initialisation too. However, if someone wants to develop their own app which uses BT and also wants to enable the CPUNET by default this KConfig should be available to them. Signed-off-by: Sean Madigan <sean.madigan@nordicsemi.no>
sean-madigan
force-pushed
the
initialise_net_core_with_bt
branch
from
10f4857 to
d24c9db
Compare
… depend on !BT The previous changes in zephyrproject-rtos/zephyr#74304 assumed that because this is also handled in `bt_hci_transport_setup` that it shouldn't be done on initialisation too. However, if someone wants to develop their own app which uses BT and also wants to enable the CPUNET by default this KConfig should be available to them. Upstream PR: zephyrproject-rtos/zephyr#79875 Signed-off-by: Sean Madigan <sean.madigan@nordicsemi.no>
… depend on !BT The previous changes in zephyrproject-rtos/zephyr#74304 assumed that because this is also handled in `bt_hci_transport_setup` that it shouldn't be done on initialisation too. However, if someone wants to develop their own app which uses BT and also wants to enable the CPUNET by default this KConfig should be available to them. Upstream PR: zephyrproject-rtos/zephyr#79875 Signed-off-by: Sean Madigan <sean.madigan@nordicsemi.no>
… depend on !BT The previous changes in zephyrproject-rtos/zephyr#74304 assumed that because this is also handled in `bt_hci_transport_setup` that it shouldn't be done on initialisation too. However, if someone wants to develop their own app which uses BT and also wants to enable the CPUNET by default this KConfig should be available to them. Upstream PR: zephyrproject-rtos/zephyr#79875 Signed-off-by: Sean Madigan <sean.madigan@nordicsemi.no>
… depend on !BT The previous changes in zephyrproject-rtos/zephyr#74304 assumed that because this is also handled in `bt_hci_transport_setup` that it shouldn't be done on initialisation too. However, if someone wants to develop their own app which uses BT and also wants to enable the CPUNET by default this KConfig should be available to them. Upstream PR: zephyrproject-rtos/zephyr#79875 Signed-off-by: Sean Madigan <sean.madigan@nordicsemi.no>
9 participants
This causes issues as we still want the net core to be set up on initialisation if CONFIG_BT is enabled in many cases.
The previous changes in
#74304 assumed that because this is also handled in
bt_hci_transport_setupthat it shouldn't be done on initialisation too.Also, I think that
bt_hci_transport_setupshould not be even controlling the network core state like it is currently and should be looked at being changed in a future PR.