jlaitine commented on code in PR #13984:
URL: https://github.com/apache/nuttx/pull/13984#discussion_r1793713563
##########
arch/arm64/src/common/arm64_arch_timer.c:
##########
@@ -286,9 +286,8 @@ static int arm64_tick_start(struct oneshot_lowerhalf_s
*lower,
priv->running = this_cpu();
- next_cycle =
- arm64_arch_timer_count() / priv->cycle_per_tick * priv->cycle_per_tick +
- ticks * priv->cycle_per_tick;
+ next_cycle = (clock_systime_ticks() + ticks) *
Review Comment:
This puts bsck the timer drift; there is an unknown delay between tick
interrupt taken and this one called, which caises the drift.
The current code fixes the drift issue by flooring the current time to an
even multiple of tick time; thus also the next_cycle is at even multiple of
tick time, and each cycle is exactly of correct length. Also querying the
current tick always then returns the same number during the tick period.
##########
sched/semaphore/sem_tickwait.c:
##########
@@ -150,7 +150,7 @@ int nxsem_tickwait(FAR sem_t *sem, uint32_t delay)
int nxsem_tickwait_uninterruptible(FAR sem_t *sem, uint32_t delay)
{
- clock_t end = clock_systime_ticks() + delay + 1;
+ clock_t end = clock_systime_ticks() + delay;
Review Comment:
This has nothing to do with timer drift; this change adds back the bug where
tickwait_uninterruptible may wake up one tick too early in case it receives a
signal.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
