Lines Matching +full:local +full:- +full:timer +full:- +full:stop

10 If you grep through the kernel source you will find a number of architecture-
12 architecture-specific overrides of the sched_clock() function and some
17 on this timeline, providing facilities such as high-resolution timers.
23 -------------
31 n bits which count from 0 to (2^n)-1 and then wraps around to 0 and start over.
32 It will ideally NEVER stop ticking as long as the system is running. It
33 may stop during system suspend.
36 shall be as stable and correct as possible as compared to a real-world wall
46 When the wall-clock accuracy of the clock source isn't satisfactory, there
48 the user-visible time to RTC clocks in the system or against networked time
73 register counts up or down, and the timer clock rate, and then conjure all
76 Since a 32-bit counter at say 100 MHz will wrap around to zero after some 43
86 ------------
90 hardware timer registers.
96 system, it is ideal (and customary) to have one such event driving timer per
109 -------------
114 may not provide an implementation of sched_clock() on its own. If a local
124 much more often, especially by the scheduler. If you have to do trade-offs
138 The clock driving sched_clock() may stop or reset to zero during system
143 The sched_clock() function should be callable in any context, IRQ- and
144 NMI-safe and return a sane value in any context.
147 counter to derive a 64-bit nanosecond value, so for example on the ARM
149 sched_clock() nanosecond base from a 16- or 32-bit counter. Sometimes the
161 --------------------------------------
174 Enter timer-based delays. Using these, a timer read may be used instead of
175 a hard-coded loop for providing the desired delay.
178 function pointers and rate settings for this delay timer.