Cortex-M SysTick: extend support for low-power mode features #84102
+238
−53
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The Cortex-M SysTick supported collaboration with a so-called "IDLE timer" to work even in low-power modes, when the SoC may disable its clock. Rename "IDLE timer" to "low-power mode timer" to better reflect what this timer is used for, and transform the single option into a Kconfig choice to allow other behaviors to be implemented and chosen. Signed-off-by: Mathieu Choplain <[email protected]>
Add support for a hook-based low-power mode timer to the Cortex-M SysTick driver, in addition to the existing Counter API-based timer. This is useful on platforms such as the STM32WB0 where the wake-up timer is too limited for a Counter API driver to be implemented on top of it. Signed-off-by: Mathieu Choplain <[email protected]>
…mode Modify the Cortex-M SysTick driver to work when the SoC resets SysTick in low-power mode. This adds an invisible Kconfig symbol that must be selected by SoCs with such behavior. Signed-off-by: Mathieu Choplain <[email protected]>
mathieuchopstm
force-pushed
the
systick_lpm_improvements
branch
from
b398cdf to
e080448
Compare
JarmouniA
reviewed
Jan 17, 2025
There was a problem hiding this comment.
LPTIM is an STM32-specific name, should be replaced by Low Power Timer.
There was a problem hiding this comment.
As defined in the comment, LPTIM is used here as an acronym, not as reference to the STM32-specific hardware (WB0 doesn't even have it). I'm fine with changing to LPtim / LPMTIM / <your proposal here> to avoid confusion though.
There was a problem hiding this comment.
Yes I think it should be changed in order to avoid confusion.
|
For the record, the commits of this PR are used on https://github.com/mathieuchopstm/zephyr/tree/wb0_deepstop_poc to implement Deepstop suspend-to-RAM low-power mode on STM32WB0 series. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR aims to improve several aspects of the Cortex-M SysTick driver related to low-power mode/PM, mainly for support of Deepstop LPM on STM32WB0 series.
The existing implementation supports a companion "IDLE timer", but it must implement the Counter API, which can be a poor fit depending on the hardware. However, the only things the SysTick drivers requests from the companion time is:
This PR implements a simple ("hook-based") API that the SysTick driver can use to perform these two functions in place of the Counter API timer, which is useful when the platform-specific timer is a poor fit for the Counter API.
Another limitation of the driver is that it expects SysTick to remain powered in low-power modes, which is not true on some SoCs. This PR creates a new Kconfig symbol which, if selected, modifies the SysTick driver such that it stops the counter cleanly before low-power mode entry, and restarts it after low-power mode exit.
This PR is a proposal, hence the DNM label - I don't think the changes are large enough to warrant the RFC label. Comments are nonetheless welcome and highly appreciated 😄