Skip to content

Conversation

@bjarki-andreasen
Copy link
Contributor

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.

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.

Signed-off-by: Bjarki Arge Andreasen <[email protected]>
@bjarki-andreasen bjarki-andreasen force-pushed the nrf-lfclk-patch-option-order branch from 3b6089b to e38eae5 Compare November 14, 2025 11:03
@sonarqubecloud
Copy link

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.

4 participants