patrick/zephyr
1
0
Fork 0
Code Issues Pull requests Actions 8 Packages Projects Releases Wiki Activity

kernel/timer: Correctly clamp period argument

Browse source 
The period argument of a k_timer needs an offset of one tick from the
value computed in user code (because periods get reset from within the
ISR, see the comment above this code for an explanation).  When the
computed tick value was 1, it would become 0.  This is actually
perfectly correct as a k_timeout_t to be passed to z_add_timeout().

BUT: to k_timer's API, K_NO_WAIT means "never" (i.e. the same as
K_FOREVER) and not "as soon as possible", so the period timer would
not be reset.  This is sort of a wart, but it's the way the API has
been specified forever.

The upshot is that for the case of calling k_timer_start() with a
minimal period argument (i.e. one that produces "one tick"), the
period would be ignored and the timer would act like a one shot.  Fix
the clamp so it can't produce K_NO_WAIT.

This also adds a filter for absolute timeouts, which (while that's
sort of a pathological usage) were getting that one tick offset when
it wasn't appropriate.

Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This commit is contained in:
Andy Ross 2020-04-23 10:05:31 -07:00 committed by Carles Cufí
parent 84817f4906
commit 3e729b2b1c
1 changed files with 3 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
kernel/timer.c
View file

@ -126,7 +126,9 @@ void z_impl_k_timer_start(struct k_timer *timer, k_timeout_t duration,
* argument the same way k_sleep() does), but historical. The
* timer_api test relies on this behavior.
*/
period.ticks = MAX(period.ticks - 1, 0);
if (period.ticks != 0 && Z_TICK_ABS(period.ticks) < 0) {
period.ticks = MAX(period.ticks - 1, 1);
}
if (Z_TICK_ABS(duration.ticks) < 0) {
duration.ticks = MAX(duration.ticks - 1, 0);
}