Skip to content

kernel: timeout: add syscall for runtime clk freq #16302

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

andrewboie
Copy link
Contributor

If the system sets its clock frequency at runtime, this is
stored in a variable that can't be directly read by user
mode. For this case only, add a system call to fetch its
value and modify the definition of
sys_clock_hw_cycles_per_sec() to use it.

Since this is now a system call, store in a temporary variable
inside z_ms_to_ticks(). The syscall overhead only applies
when called from user mode, other contexts are completely
inlined.

Fixes: #16238

Signed-off-by: Andrew Boie [email protected]

@andrewboie
Copy link
Contributor Author

@nashif CI failures seem to be related to some mocking we have which is pulling in sys_clock.h without generating any syscall headers...what do you recommend about this

@ioannisg
Copy link
Member

Do we want to back-port this to 1.14?

@carlescufi
Copy link
Member

@andrewboie thanks for this PR! There's a test failing due to a missing include path apparently

Copy link
Collaborator

@andyross andyross left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make sense. This API really only exists for the benefit of the HPET driver. And note that there's no way to actually set the runtime value of the HPET clock. We just choose to not know what it is at build time and get it from the hardware for, I dunno, cross-device binary portability. Which Zephyr never does in any other context.

I wonder if this might be an appropriate time to yank the whole abstraction out and replace it with a simple assert that CONFIG_SYS_CLOCK_CYCLES_PER_SEC matches the value probed from hardware during timer init....

If the system sets its clock frequency at runtime, this is
stored in a variable that can't be directly read by user
mode. For this case only, add a system call to fetch its
value and modify the definition of
sys_clock_hw_cycles_per_sec() to use it.

Since this is now a system call, store in a temporary variable
inside z_ms_to_ticks(). The syscall overhead only applies
when called from user mode, other contexts are completely
inlined.

Added stub syscall header for mocking framework, to get rid
of inclusion errors.

Fixes: zephyrproject-rtos#16238

Signed-off-by: Andrew Boie <[email protected]>
@andrewboie andrewboie force-pushed the sys-clock-freq-syscall branch from d4a0a3f to 0de849e Compare May 22, 2019 18:29
@zephyrbot
Copy link
Collaborator

Found the following issues, please fix and resubmit:

License issues

In most cases you do not need to do anything here, especially if the files
reported below are going into ext/ and if license was approved for inclusion
into ext/ already. Fix any missing license/copyright issues. The license
exception if a JFYI for the maintainers and can be overriden when merging the
pull request.

  • subsys/testsuite/ztest/include/syscalls/sys_clock.h missing copyright.

@carlescufi carlescufi merged commit fd49cf7 into zephyrproject-rtos:master May 22, 2019
@andrewboie andrewboie deleted the sys-clock-freq-syscall branch October 2, 2019 18:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

k_cycle_get_32() API is useless in some Zephyr configurations
8 participants