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:
Nicolas Pitre 2023-03-22 14:30:28 -04:00 committed by Fabio Baltieri
parent 38d9da7266
commit c25a40baee

View file

@ -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