jlaitine commented on code in PR #15929:
URL: https://github.com/apache/nuttx/pull/15929#discussion_r1984500335
##########
arch/risc-v/src/common/riscv_mtimer.c:
##########
@@ -211,19 +210,20 @@ static int riscv_mtimer_max_delay(struct
oneshot_lowerhalf_s *lower,
static int riscv_mtimer_start(struct oneshot_lowerhalf_s *lower,
oneshot_callback_t callback, void *arg,
- const struct timespec *ts)
+ clock_t ticks)
{
struct riscv_mtimer_lowerhalf_s *priv =
(struct riscv_mtimer_lowerhalf_s *)lower;
irqstate_t flags;
uint64_t mtime;
+ clock_t current;
uint64_t alarm;
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;
+ current = mtime * TICK_PER_SEC / priv->freq;
+ alarm = (current + ticks) * priv->freq / TICK_PER_SEC;
Review Comment:
> > No, there is absolutely no change in clock_gettime accuracy. The
accuracy is the tick accuracy. It is calculated from ticks:
> > clock_gettime->nxclock_gettime->clock_systime_timespec->clock_ticks2time
>
> with #15139 or tickless mode, the call chain is:
clock_gettime->nxclock_gettime->clock_systime_timespec->up_timer_gettime->ONESHOT_CURRENT->riscv_mtimer_current
>
> with your patch, the unit returned from riscv_mtimer_current change from
timespec to tick. So, let me quote the case I mention before again:
>
> > For example, let's assume mtime 1MHz and SCHED_CPULOAD_TICKSPERSEC=1000,
the accuracy of clock_gettime change from 1us to 1ms with this patch.
Ah! But this means that we should just keep also the ONESHOT_CURRENT
interface, and not remove it. We should just add the TICK interface.
Sorry for overlooking this, it was not implemented in e.g. arm64 which was
the other platform I am actively working on, so I didn't realize that. Let's
just keep them both.
--
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
