k_cycle_get_32() API is useless in some Zephyr configurations

[pizi-nordic]

TL;DR:
CONFIG_USERSPACE=y + CONFIG_TIMER_READS_ITS_FREQUENCY_AT_RUNTIME=y = No reference for k_cycle_get_32().

The CONFIG_USERSPACE option introduces strong separation between the application and the
kernel memory. The CONFIG_TIMER_READS_ITS_FREQUENCY_AT_RUNTIME makes the CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC define useless leaving the sys_clock_hw_cycles_per_sec() function the only source of system timer frequency, which is needed to interpret data from k_cycle_get_32().

Unfortunately, the sys_clock_hw_cycles_per_sec() function directly reads the kernel memory (z_clock_hw_cycles_per_sec) triggering exception when called from user thread.

Please also note, that sys_clock_hw_cycles_per_sec() is used in multiple inline functions, so other timing-related API also fails with the mentioned configuration.

[pizi-nordic]

Currently this bug in connection with #15230 (which prevents the tests from not using userspace if platform supports it), blocks #16203, which is a fix for #15983.

[pizi-nordic]

FYI: @nashif, @andrewboie, @carlescufi

[andrewboie]

what I think is needed is a new, private z_ prefixed API, like z_sys_runtime_clock_hw_cycles_per_sec() which returns runtime calculated system clock frequency. make it a system call. and then wrap sys_clock_hw_cycles_per_sec to either call that or just return CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC

[pizi-nordic]

I would rather name it k_cycle_freq_get() in order to relate it to k_cycle_get_32(). IMHO on platforms witch clock speed known at compile time, it could be a static inline returning constant value and syscall on the others. What do you think?