kernel: fix k_sleep in no multi-threading mode

[KushnerovMikhail]

Fix k_sleep implementation for no multi-threading mode.
Fixes #81210

Absolute value of timeout expiration was fed to the k_busy_wait() function instead of delta value. That caused bug like incrementing of sleep time in geometric progression (while actual function argument is constant) during program running.

You can check it by simple program with CONFIG_MULTITHREADING=n option:

#include <zephyr/kernel.h>

int main (void)
{
	uint32_t new_ticks = 0;
	uint32_t old_ticks = sys_clock_tick_get_32();

	while (1) {
		k_sleep(K_MSEC(1000));
		new_ticks = sys_clock_tick_get_32();
		printf("%u\n", new_ticks - old_ticks);
		old_ticks = new_ticks;
	}

	return 0;
}

Output from qemu_riscv64
Before fix:
100
200
400
800
...

After fix:
100
100
100
100
...

[peter-mitsis]

If we have already passed the absolute point in time (Z_TICKS_ABS(ticks) < sys_clock_tick_get_32()), we should set ticks_to_wait to 0, otherwise we are waiting when we should not be waiting.

[KushnerovMikhail]

Thanks for the comment. Fixed it

[mmahadevan108]

@peter-mitsis , is this a fix that is needed for the upcoming 4.0 release?

[peter-mitsis]

@mmahadevan108 - I think this would be worthwhile for 4.0.

[dkalowsk]

@KushnerovMikhail or @peter-mitsis can you please file an Issue so it can be tracked to a detail in the release-notes?

[rruuaanng]

Are they possible to be negative number?

(Just a question.)

[KushnerovMikhail]

Not really understand question.

If you talking about Z_TICK_ABS(ticks), than it can. But negative values are caught by previous if.
If you talking about ticks_to_wait, I think there is no meaning in waiting negative time. So, I make it unsigned.
sys_clock_tick_get_32(), of course, can not be negative.

[mmahadevan108]

Moving the milestone to 4.1. Please add the backport-v4.0 label if this is critical for 4.0