On Tue, Nov 16, 2021 at 12:49:11PM -0500, Jonathan Behrens wrote:
>Adding more configuration options increases complexity. Under the current
>draft, if software wants an interrupt 1ms in the future it can set mtimecmp
>to the value of mtime plus 100,000. If we make the resolution of mtime vary

I hope I am reading the right current draft. The current draft states:
"The ACLINT MTIME update frequency (i.e. hardware clock) must be between 10 MHz and 100 MHz, and updates must be strictly monotonic."

So a value of 100,000 could mean a delay between 100ms to 1 ms. So per current draft it would be wrong for software to assume 100,000 implies 1ms.

>between systems, then we have to do a bunch more specification and
>implementation work to pipe that information around. Based on Greg's
>message it sounds like that may be happening, but I also see the appeal of
>just picking the extremely simple option that works well enough for
>everyone's case (even if it isn't some people's top pick)
>

An enumeration of MTIME frequency is needed per current draft. I beleive the device-tree binding for RISC-V uses the timebase-frequency property under the cpus node.
https://github.com/riscv-non-isa/riscv-device-tree-doc/blob/master/bindings/riscv/cpus.txt
Is further specification needed?

regards
ved