Skip to content

Conversation

@bjarki-andreasen
Copy link
Contributor

@bjarki-andreasen bjarki-andreasen commented Nov 14, 2025

The clock options used within the driver are supposed to be ordered from lowest to highest power consumption, so the lowest/default option is the most power efficient. The order was reversed to make the init code of the lfclk a bit simpler, and this was accounted for in the clock option lookup function. However, the common nrf clock control request/release feature would request the lowest index, not the lowest clock option, so the lfclk would default to its highest power consumption mode.

The clock option init and lookup has been refactored to be sorted from lowest to highest power consumption, and comments have been adjusted accordingly.

Upstream PR #: 99382

@bjarki-andreasen bjarki-andreasen changed the title [nrf fromlist] drivers: clock_control nrf_lfclk: patch clock option o… [nrf fromlist] drivers: clock_control nrf_lfclk: patch clock option order Nov 14, 2025
@bjarki-andreasen bjarki-andreasen force-pushed the nrf-lfclk-patch-option-order branch from ea6da96 to 79ef9e6 Compare November 14, 2025 11:04
@nordic-piks nordic-piks requested review from a team November 14, 2025 11:32
@nordic-piks
Copy link
Contributor

Works fine at CI:

13:33:53  INFO    - 1/2 [email protected]/nrf54h20/cpuapp benchmarks.multicore.idle_clock_control.app PASSED (device: 001051180995, 40.903s <zephyr>)
13:33:53  INFO    -                                    benchmarks.multicore.idle_clock_control.app.test_measure_and_data_dump_power_consumption_clock_control PASSED
13:34:06  INFO    - 2/2 [email protected]/nrf54h20/cpurad benchmarks.multicore.idle_clock_control.rad PASSED (device: 001051100381, 39.155s <zephyr>)
13:34:06  INFO    -                                    benchmarks.multicore.idle_clock_control.rad.test_measure_and_data_dump_power_consumption_clock_control PASSED

…rder

The clock options used within the driver are supposed to be ordered
from lowest to highest power consumption, so the lowest/default
option is the most power efficient. The order was reversed to make
the init code of the lfclk a bit simpler, and this was accounted for
in the clock option lookup function. However, the common nrf clock
control request/release feature would request the lowest index, not
the lowest clock option, so the lfclk would default to its highest
power consumption mode.

The clock option init and lookup has been refactored to be sorted
from lowest to highest power consumption, and comments have been
adjusted accordingly.

Upstream PR #: 99382

Signed-off-by: Bjarki Arge Andreasen <[email protected]>
@bjarki-andreasen bjarki-andreasen force-pushed the nrf-lfclk-patch-option-order branch from 79ef9e6 to b35cb6c Compare November 14, 2025 13:19
@karl-nordic
Copy link
Contributor

@bjarki-andreasen Side task:
LFXO startup time. {*startup_time_us = dev_data->lfxo_startup_time_us;}
Is it anyhow used by clock controller ? Some time ago, there was discussion that this parameter is not utilized by anyone.
The conclusion from the dissuasion was to not use this parameter in BICR. It will be there, but customers will just not fill it.
Is that an issue for clock control ?

@carlescufi
Copy link
Contributor

@bjarki-andreasen Side task: LFXO startup time. {*startup_time_us = dev_data->lfxo_startup_time_us;} Is it anyhow used by clock controller ? Some time ago, there was discussion that this parameter is not utilized by anyone. The conclusion from the dissuasion was to not use this parameter in BICR. It will be there, but customers will just not fill it. Is that an issue for clock control ?

Note that @bjarki-andreasen is off for two weeks, so this will have to wait

@carlescufi carlescufi merged commit 7c6f855 into nrfconnect:main Nov 17, 2025
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants