> Date: Thu, 10 Aug 2023 16:01:10 -0500
> From: Scott Cheloha
>
> On Tue, Aug 08, 2023 at 08:00:47PM +0200, Mark Kettenis wrote:
> > > From: Dale Rahn
> > > Date: Tue, 8 Aug 2023 12:36:45 -0400
> > >
> > > Switching the computation of cycles/delaycnt to a proper 64 value math
> > > instead of
On Tue, Aug 08, 2023 at 08:00:47PM +0200, Mark Kettenis wrote:
> > From: Dale Rahn
> > Date: Tue, 8 Aug 2023 12:36:45 -0400
> >
> > Switching the computation of cycles/delaycnt to a proper 64 value math
> > instead of the '32 bit safe' complex math is likely a good idea.
> > However I am not
> From: Dale Rahn
> Date: Tue, 8 Aug 2023 12:36:45 -0400
>
> Switching the computation of cycles/delaycnt to a proper 64 value math
> instead of the '32 bit safe' complex math is likely a good idea.
> However I am not completely convinced that switching to 'yield' (current
> CPU_BUSY_CYCLE
Switching the computation of cycles/delaycnt to a proper 64 value math
instead of the '32 bit safe' complex math is likely a good idea.
However I am not completely convinced that switching to 'yield' (current
CPU_BUSY_CYCLE implementation) for every loop of a 'short wait' in the wait
loop makes
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:
