CONFIG_TICKLESS_KERNEL makes z_clock_set_timeout doesn't work

[vonhust]

@andyross @nashif @ruuddw

in timeout.c, the function will call the clock driver wrapper z_clock_set_timerout in legacy_api.h.

void z_clock_set_timeout(s32_t ticks, bool idle)
{
#ifdef CONFIG_TICKLESS_KERNEL
	if (idle) {
		_timer_idle_enter(ticks);
	} else {
		_set_time(ticks == K_FOREVER ? 0 : ticks);
	}
#endif
}

According to the code, if TICKLESS_KERNEL is not configured, z_clock_set_timeout will do nothing, which means the timeout mechnism will fail.

I already observed the failure in tests/kernel/profiling/profiling_api caused by the changes in clock driver (legacy_api.h)

BTW in line 46 of legacy_api.h

#ifdef TICKLESS_KERNEL shoud be #ifdef CONFIG_TICKLESS_KERNEL ?

[andyross]

z_clock_set_timeout() is an internal API between the kernel and timer driver, and indeed it's a noop if TICKLESS_KERNEL is not defined. When TICKLESS_KERNEL=n, the driver is expected to deliver regular ticks on its own, and doesn't need the kernel to tell it when to schedule the next z_clock_announce().

[vonhust]

So, how about the case TICKLESS_IDLE? When TICKLESS_IDLE is configured and TICKLESS_KERNEL not configured, z_clock_set_timeout should not be noop. For ARC, in arcv2_timer0.c, z_clock_idle_exit and _timer_idle_enter should be a couple. If z_clock_set_timeout is a noop, it means _timer_idle_enter will not be called. Then the call to z_clock_idle_exit in interrupt handling will cause problem. For ARM’s systick driver, I see similar logic. From: Andy Ross [mailto:[email protected]] Sent: 2018年11月10日 10:59 To: zephyrproject-rtos/zephyr <[email protected]> Cc: Wayne Ren <[email protected]>; Author <[email protected]> Subject: Re: [zephyrproject-rtos/zephyr] CONFIG_TICKLESS_KERNEL makes z_clock_set_timeout doesn't work (#11129) z_clock_set_timeout() is an internal API between the kernel and timer driver, and indeed it's a noop if TICKLESS_KERNEL is not defined. When TICKLESS_KERNEL=n, the driver is expected to deliver regular ticks on its own, and doesn't need the kernel to tell it when to schedule the next z_clock_announce(). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_zephyrproject-2Drtos_zephyr_issues_11129-23issuecomment-2D437553118&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=uIRv5OnfaYG5_34mbrNlSdByDrbpAfi15TvQ5YKDOG8&m=pp23sMXXMBOlOyLo6j8rLrTZeiLPcDM4jl4VL5iRUvc&s=ONrCojiUjcOdTCgMhLNvXGu7H8AR4jgnPPpvgJ0CLqE&e=>, or mute the thread<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AFB9O5cX8jNJEjgT9tZxTVuIvXeGULhYks5utkDlgaJpZM4YP9Iq&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=uIRv5OnfaYG5_34mbrNlSdByDrbpAfi15TvQ5YKDOG8&m=pp23sMXXMBOlOyLo6j8rLrTZeiLPcDM4jl4VL5iRUvc&s=sMDEv_Q2Z_oy6BeBNTHCXcHIzjYFaJKekjNW_1_rR9I&e=>.

[andyross]

Check the new drivers in #10556, hopefully that will be clearer. I think the problem is that you're looking at only half the change (the API refactoring) and getting confused about the shim layer needed to make the older drivers work.