The mtime synchronization code sample is only for reference. A platform can have it’s own way (hardware/software) of synchronizing MTIME registers. The code sample shows a simple approach to

Hi Neel, You first question is already answered by Greg. Regarding second question/suggestion, I agree we should explicitly state how to disable a pending interrupt. Regards, Anup

From: Abner Chang <abner.chang@...> Signed-off-by: Abner Chang <renba.chang@...> --- contributors.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/contributors.adoc

From: Abner Chang <abner.chang@...> Initial description of PLIC CLINT section of Linux-2022 platform. On v6 commit, Remove the changes in Embedded-2022 section. On v5 commit, - Remove CLINT

From: Abner Chang <renba.chang@...> Signed-off-by: Abner Chang <renba.chang@...> --- contributors.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/contributors.adoc

From: Abner Chang <renba.chang@...> Initial description of PLIC CLINT section of Linux-2022 platform. On v6 commit, Remove the changes in Embedded-2022 section. On v5 commit, - Remove

Right, I'm attempting to refer to the effective timer resolution as opposed to the apparent timer unit period. I'm just making explicit what this relaxation implies about capabilities in real systems.

Signed-off-by: Paul Donahue pdonahue@... --- riscv-platform-spec.adoc | 101 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 101 insertions(+) diff --git

Updating changelog Signed-off-by: Paul Donahue pdonahue@... --- changelog.adoc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/changelog.adoc b/changelog.adoc index 7ec1b1f..cc69971

Adding myself to list of contributors. Signed-off-by: Paul Donahue pdonahue@... --- contributors.adoc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

At least at the platform level, the requirement of a single reference clock for all timers in a "system" (thus preventing first-order drift) may be a desirable requirement. -Josh

If you're interested in reading about pure software approaches to clock synchronization, I recommend looking at https://www.usenix.org/conference/nsdi18/presentation/geng. They focus on synchronizing

More recent ARM SBSA requires a 1 GHz counter resolution, but does not place any requirement on the actual measurable 'time" resolution (i.e. a minimum update frequency). So one can have 1 ns

One other issue with the "mtime" synchronization by SW approach is that this effectively places an upper limit on the achievable timer unit resolution. It'd be some equation based on the ordered

Note that the "update latency" between a write to "mtime" and a read of the hart-local "time" is unspecified. -Josh

Architecturally the 'time' CSR reads the same concept of "time" as the 'mtime' register. Simplistically the RDTIME pseudoinstruction reads what is in the 'mtime' register. One implementation is that

Hi, Minor comments: Should there be a mention that the user level "time" csr (0xC01) which is used by the rdtime pseudo-instruction will enable a read-only peek into the mtime register? Would this

Hi Josh, I have created a GitHub PR addressing your comments. Please check if you are okay with this. https://github.com/riscv/riscv-aclint/pull/2 Regards, Anup

Hi Josh, Indeed, I missed adding text regarding verifying delta and ensuring that it is within bounds. Thanks for pointing. I was thinking that aclint_mtime_sync() function should return the

Alistair Francis <Alistair.Francis@...> 於 2021年5月26日 週三 下午6:57寫道： Alistair, I can understand your concern just like I have to the server extension. The inflexible spec may lead