The clock/timer APIs are not application facing APIs, however, similar
to arch_ and a few other APIs they are available to implement drivers
and add support for new hardware and are documented and available to be
used outside of the clock/kernel subsystems.
Remove the leading z_ and provide them as clock_* APIs for someone
writing a new timer driver to use.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
@ -155,7 +155,7 @@ Kernel timing at the tick level is driven by a timer driver with a
@@ -155,7 +155,7 @@ Kernel timing at the tick level is driven by a timer driver with a
comparatively simple API.
* The driver is expected to be able to "announce" new ticks to the
kernel via the ``z_clock_announce()`` call, which passes an integer
kernel via the ``sys_clock_announce()`` call, which passes an integer
number of ticks that have elapsed since the last announce call (or
system boot). These calls can occur at any time, but the driver is
expected to attempt to ensure (to the extent practical given
staticuint32_tlast_announcement;/* last time we called z_clock_announce() */
staticuint32_tlast_announcement;/* last time we called sys_clock_announce() */
/*
*RequestatimeoutnZephyrticksinthefuturefromnow.
@ -126,7 +126,7 @@ static uint32_t last_announcement; /* last time we called z_clock_announce() */
@@ -126,7 +126,7 @@ static uint32_t last_announcement; /* last time we called z_clock_announce() */
@ -6,7 +6,7 @@ timeout is repeatedly rescheduled before it has a chance to fire. In
@@ -6,7 +6,7 @@ timeout is repeatedly rescheduled before it has a chance to fire. In
some implementations this may prevent the timer interrupt handler from
ever being invoked, which in turn prevents an announcement of ticks.
Lack of tick announcement propagates into a monotonic increase in the
value returned by z_clock_elapsed().
value returned by sys_clock_elapsed().
This test is not run in automatic test suites because it generally takes
minutes, hours, or days to fail, depending on the hardware clock rate