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

Reply via email to