Fix arm64 tick timer #292
Merged
Fix arm64 tick timer #292
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
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
jlaitine
commented
Sep 27, 2024
jlaitine
force-pushed
the
fix_arm64_tick_timer
branch
from
42bc72e to
16f1b3c
Compare
pussuw
approved these changes
Sep 27, 2024
jlaitine
force-pushed
the
fix_arm64_tick_timer
branch
2 times, most recently
from
67ef15b to
8ee2973
Compare
…ss build Signed-off-by: Jukka Laitinen <[email protected]>
…k timer This fixes two issues with the tick timer 1) Each tick was longer than the requested period. This is because setting the compare register was done by first reading the current time, and only after that setting the compare register. In addition, when handling the timer interrupts in arch_alarm.c / oneshot_callback, the current_tick is first read, all the tick handling is done and only after that the next tick is started. The whole tick processing time was added to the total tick time. 2) When the compare time is not aligned with tick period, and is drifting, eventually any call to ONESHOT_TICK_CURRENT would either return the current tick, or the next one, depending on the rounding of division by the cycle_per_tick. This again leads to oneshot_callback randomly handling two ticks at a time, which breaks all wdog based timers, causing them to randomly timeout too early. The issues are fixed as follows: Align the compare time register to be evenly divisible by cycle_per_tick. This will lead arm64_tick_current always to return the currently ongoing tick, fixing 2). Also calculating the next tick's start from the aligned current count will fix 1), as there is no time drift in the start cycle. Signed-off-by: Jukka Laitinen <[email protected]>
…d condition nxsem_tickwait correctly sleeps more than 1 tick. But nxsem_tickwait_uninterruptible may wake up to a signal (with -EINTR), in which case the tick + 1 must also be taken into account. Otherwise the nxsem_tickwait_uninterruptible may wake up 1 tick too early. Also fix the nxsem_tickwait to return with -ETIMEDOUT if called with delay 0. This is similar to e.g. posix sem_timedwait. Signed-off-by: Jukka Laitinen <[email protected]>
jlaitine
force-pushed
the
fix_arm64_tick_timer
branch
from
8ee2973 to
f81554d
Compare
|
Updated to clean cherry-picks from upstream |
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.
Summary
WIP: fixed arm64 tick timer
Not going to merge before upstreaming. The first patch (arch alarm) is just cleanup to make it understandable to myself. The two others actually correct something.
Impact
Testing