jlaitine commented on code in PR #15929: URL: https://github.com/apache/nuttx/pull/15929#discussion_r1984719928
########## arch/risc-v/src/common/riscv_mtimer.c: ########## @@ -222,8 +221,11 @@ static int riscv_mtimer_start(struct oneshot_lowerhalf_s *lower, flags = up_irq_save(); mtime = riscv_mtimer_get_mtime(priv); - alarm = mtime + ts->tv_sec * priv->freq + - ts->tv_nsec * priv->freq / NSEC_PER_SEC; + + /* Align each tick start to cycle_per_tick boundary to avoid clock drift */ + + alarm = mtime / priv->cycle_per_tick * priv->cycle_per_tick + Review Comment: > What's I really care is the drift and accuracy from clock_gettime(riscv_mtimer_current). > > > the early wakeup could be fixed by tick+1 and roundup hardware count. This is already managed in wdog, as I pointed out in arm64 related tick counter PR. The issue is that if we count the ticks wrong in here, the lowest level, the fix doesn't save it! > Yes, I agree that timing error is hard to fix. so, let's come up a common solution to fix both arm and riscv platform. I think that the cleanest solution is to separate the tick timer and gettime, which the oneshot interface alarady supports. Another thing is, that why would the gettime ever go through the oneshot interface. It can just always return the time based on the best available timer. -- 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: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
