The agtimer(4/arm64) delay(9) implementation is quite complicated. This patch simplifies it.
Am I missing something here? There's no reason to implement the busy-loop like this, right? ok? Index: agtimer.c =================================================================== RCS file: /cvs/src/sys/arch/arm64/dev/agtimer.c,v retrieving revision 1.23 diff -u -p -r1.23 agtimer.c --- agtimer.c 25 Jul 2023 18:16:19 -0000 1.23 +++ agtimer.c 8 Aug 2023 02:24:57 -0000 @@ -323,32 +323,12 @@ agtimer_cpu_initclocks(void) void agtimer_delay(u_int usecs) { - uint64_t clock, oclock, delta, delaycnt; - uint64_t csec, usec; - volatile int j; + uint64_t cycles, start; - if (usecs > (0x80000000 / agtimer_frequency)) { - csec = usecs / 10000; - usec = usecs % 10000; - - delaycnt = (agtimer_frequency / 100) * csec + - (agtimer_frequency / 100) * usec / 10000; - } else { - delaycnt = agtimer_frequency * usecs / 1000000; - } - if (delaycnt <= 1) - for (j = 100; j > 0; j--) - ; - - oclock = agtimer_readcnt64(); - while (1) { - for (j = 100; j > 0; j--) - ; - clock = agtimer_readcnt64(); - delta = clock - oclock; - if (delta > delaycnt) - break; - } + start = agtimer_readcnt64(); + cycles = (uint64_t)usecs * agtimer_frequency / 1000000; + while (agtimer_readcnt64() - start < cycles) + CPU_BUSY_CYCLE(); } void