Skip to content
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

API for accessing mtime base clock #233

Open
sctincman opened this issue Mar 21, 2020 · 1 comment
Open

API for accessing mtime base clock #233

sctincman opened this issue Mar 21, 2020 · 1 comment

Comments

@sctincman
Copy link

It seems there is not a good platform independent way to determine what drives mtime and timer interrupts. From examples I've read, it seems people tend to #define the target board's timebase for mtime. However, this info does appear to be in the dts files, but just needs to be propagated to an API endpoint. For example, lfrclk drives mtime on the HiFive1-RevB, and lfrclk defines it's frequency in the dts.

A new entrypoint metal_cpu_get_mtime_timebase would be quite useful here to allow platform independent timer behavior.

A potential approach to this could be to have the platform's CPU driver direct this to the applicable subsystem that handles timers (clint0 for FE310), and this can then source the clockbase. Continuing this example on FE310, clint0 then knows that lfrclk would supply the clock here, and its node in the devicetree could hold a reference to the lfrclk node to supply the frequency to clint0

Would that scale to other platforms as well?

@sctincman
Copy link
Author

Addendum: there is already an API for getting the CPU's timebase, but this appears to be the baseclock for cpu/mcycle and not for mtime (eg, on FE310, this returns the 16 MHz base clock vs the 32.768 KHz RTC that is connected to mtime)

bsousi5 pushed a commit that referenced this issue Apr 8, 2020
Add PMP nodes to all targets except e20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant