PM Policy Event: Update to use uptime ticks and be "sticky" #80580
Conversation
This file contains hidden or 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
zephyrbot
requested review from
JordanYates,
ceolin,
nashif,
teburd and
tmleman
bjarki-andreasen
force-pushed
the
pm_policy_event_use_uptime_ticks
branch
from
679679c to
6e379e7
Compare
Contributor
Author
|
ping @ceolin |
ceolin
previously approved these changes
Dec 2, 2024
Member
ceolin
left a comment
ceolin
left a comment
There was a problem hiding this comment.
It looks good to me. It is easier to read too.
hubertmis
reviewed
Dec 3, 2024
include/zephyr/pm/policy.h
Outdated
Contributor
There was a problem hiding this comment.
Is it also valid to call pm_policy_event_update instead of unregister/register, or is that only allowed before the event time has passed?
Contributor
Author
There was a problem hiding this comment.
It is also valid to call pm_policy_event_update instead of unregister/register :) I will update the desc
Contributor
Author
There was a problem hiding this comment.
Updated to:
* CPU is woken up before the time passed in cycle to minimize event handling
* latency. Once woken up, the CPU will be kept awake until the event has been
* handled, which is signaled by pm_policy_event_unregister() or moving event
* into the future using pm_policy_event_update().
hubertmis
reviewed
Dec 4, 2024
include/zephyr/pm/policy.h
Outdated
Comment on lines
210
to
211
Member
There was a problem hiding this comment.
Could you clarify that if there is an unregistered past event, this function returns zero?
Contributor
Author
There was a problem hiding this comment.
Updated to:
/**
* @brief Returns the ticks until the next event
*
* If an event is registred, it will return the number of ticks until the next event, if the
* "next"/"oldest" registered event is in the past, it will return 0. Otherwise it returns -1.
*
* @retval >0 If next registered event is in the future
* @retval 0 If next registered event is now or in the past
* @retval -1 Otherwise
*/
6e379e7 to
8b3f619
Compare
Update events to use uptime ticks, which is a monotonic clock which in the same res as kernel ticks. This makes comparisons simple and removes the complexity of dealing with wrapping counter values. The wrapping is particularly problematic for events since this makes it quite complex to track if an event has occured in the past, or will occur in the future. This info is needed to know if an event has actually been handled or not. Signed-off-by: Bjarki Arge Andreasen <[email protected]>
bjarki-andreasen
force-pushed
the
pm_policy_event_use_uptime_ticks
branch
from
8b3f619 to
18f3e8f
Compare
hubertmis
approved these changes
Dec 6, 2024
ceolin
approved these changes
Dec 9, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
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.
Registering a pm policy event will now represent a single event in absolute time, which will remain active, preventing the system from suspending, until the event has been handled. To indicate an event has been handled, it must be updated to a time in the future, or unregistered.
To greatly simplify the events and the "sticky" logic, the time primitive used is updated to the monotonic uptime in ticks. This ensures an event can be determined to be in the past, since unlike the HW cycle, uptime can't wrap. Additionally, the kernel works in ticks, which aligns the resolution with the requirements of the kernel, and removes the need for conversions between pm and the kernel, see
pm_policy_next_event_ticks()before this PR.fixes: #80386