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