doc: recommend sys_clock_cycle_get_64() when clock rate is really fast
Timer clocks as high as 300MHz exist out there making sys_clock_cycle_get_32() wrap within 15 seconds. Some tests don't like that and possibly other usages too. Synthesizing a 64-bit counter is cheap enough, even on 32-bit systems, to work around this annoyance. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
This commit is contained in:
parent
38d9da7266
commit
c25a40baee
1 changed files with 11 additions and 0 deletions
|
|
@ -128,6 +128,12 @@ extern void sys_clock_disable(void);
|
|||
* user-facing API is owned by the architecture, not the driver. The
|
||||
* rate must match CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC.
|
||||
*
|
||||
* @note
|
||||
* If the counter clock is large enough for this to wrap its full range
|
||||
* within a few seconds (i.e. CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC is greater
|
||||
* than 50Mhz) then it is recommended to also implement
|
||||
* sys_clock_cycle_get_64().
|
||||
*
|
||||
* @return The current cycle time. This should count up monotonically
|
||||
* through the full 32 bit space, wrapping at 0xffffffff. Hardware
|
||||
* with fewer bits of precision in the timer is expected to synthesize
|
||||
|
|
@ -142,6 +148,11 @@ uint32_t sys_clock_cycle_get_32(void);
|
|||
* Not all hardware has 64 bit counters. This function need be
|
||||
* implemented only if CONFIG_TIMER_HAS_64BIT_CYCLE_COUNTER is set.
|
||||
*
|
||||
* @note
|
||||
* If the counter clock is large enough for sys_clock_cycle_get_32() to wrap
|
||||
* its full range within a few seconds (i.e. CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC
|
||||
* is greater than 50Mhz) then it is recommended to implement this API.
|
||||
*
|
||||
* @return The current cycle time. This should count up monotonically
|
||||
* through the full 64 bit space, wrapping at 2^64-1. Hardware with
|
||||
* fewer bits of precision in the timer is generally not expected to
|
||||
|
|
|
|||
Loading…
Reference in a new issue