Before we go ahead and change the MTIME resolution requirement in the platform spec, I would like to highlight following points (from past discussions) which led to mandating a fixed MTIME resolution

Given that the device-tree mechanism is apparently already in place, it honestly probably wouldn't be a big deal to just formalize that and not require any particular mtime resolution. I still prefer

It is late in my timezone, so please excuse that I respond only to the part that I feel is most critical to drive this forward. Well said and no disagreement there. In fact, I have suggested to the

Philipp, I am aware of the history of the platform working group / task group / subcommittee, as I have been regularly attending meetings since its inception in 2019, although I have a different

Linux discovers the timebase from device-tree and does not assume a fixed frequency: https://elixir.bootlin.com/linux/latest/source/arch/riscv/kernel/time.c#L14 regards ved

Yes. This gets to the heart of the difference between resolution and update frequency. For a given resolution one is free to update (with +1 increments) at an update frequency corresponding to the

I see what you mean. I was sort of mixed up by the term "default" as not normative. Does the timebase frequency being enumerated not suffice for the platform to convert time to ticks? regards ved

The draft says "Platform must support a default ACLINT MTIME counter resolution of 10ns" which I interpret to mean that 100,000 always corresponds to 1ms. The point of different frequencies just means

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

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

Yes. A spec update to allow higher update frequencies is in the works (along with the other changes that have been recently discussed and decided). Greg

So do we agree that the platform specification must not treat a implementation that has MTIME update frequency higher than 100 MHz as non-compliant. Removing this upper bound does not of course force

The required UART is not for exclusive use by firmwares so the OS can certainly use the UART but it is not mandatory for the OS to support the UART. Regards, Anup

Could you say a bit more about the OS aspect? Is the idea that an OS must be provided access to a UART, but has the option to ignore it in favor of other I/O methods? I don't think we should allow

Darius, The Platforms HSC writing the specs is a left-over (committees only provide governance) that is expected to be restructured in the future (once the initial set of specifications are through

Philipp, The Common Software Interface concept seems like it could be a promising idea, but at this point, that appears to be all it is: an idea. Whether that idea is fully realized into something

+ platforms mailing list Regards Kumar

Hi All, During our Platform HSC meeting today, one of the topics that came up for discussion was whether we should mandate the 16550 UART for all OS-A platforms and keep this requirement within the

But why mandate that it cannot be finer resolytion than 10ns. I can see a requirement to say minimum of 10ns but whats the rationalet to say must not be better than 10ns? regards ved

I can understand definining a minimum resolution but I do not understand why it needs to be capped to 10ns. I do not think the specification should define a maximum resolution. Which specter version