The AIA specification is modular. It is not mandatory to implement all parts of AIA. For example, low-end embedded Linux systems having only MMIO devices will want to skip AIA IMSIC (MSI

Agree, we should make AIA mandatory. Would the following work? AIA: Mandatory (Required) PLIC + CLINT: Deprecated -- Regards Kumar

I'm confused by this. If we specify that the frequency is communicated via the "timebase-frequency" DT property, then all operating systems will know to look for that. My mental model is that OS

Yes. But specifying an approach that is very specific to Linux may not work with other OS. In this case, "timebase-frequency" DT property is specific to Linux. Other OS may or may not adopt the same

I this leaving this unspecified makes this standard too weak. There should be a standard way of discovering how to use a standard CSR. The way I see it, there are a few ways of going about this: *

Isn't one of the main points of these platform specs to specify the details of how platforms communicate information (like the timebase) to operating systems?

This is exactly the intent of the RVA22 profile. Tbd but the required extensions in the profile spec may be sufficient for both the Linux Base and Server platform specs. Worst case one or both may

The minimum ISA required is specified by RVA22 profile. I think platform spec should only specify any ISA requirements if any required ISA extensions are not specified by the profile. Pasting the

In order to allow the existing hardware to comply with the Linux2022 spec, we should add additional clarification. It is recommended that platforms shall implement the time CSR. In absence of time

Hi Darius, Firstly, the purpose of the platform spec is to define a minimal set of "Required" features that will be needed to define a platform or an extension. By this definition, all requirements

I would like to make a suggestion regarding the organization and structure of the Platform Specification that I think might make it easier to understand and eliminate some of the ambiguity around

Recommendations are non-normative. If we mandate a watchdog time, it will be a guarantee that every compatible device implements it — whether necessary or not. That said, I don't see the watchdog

We also need to specify where this DT comes from (I believe a1), and what other properties are valid. For example, the devicetree may specify the memory used by the SBI which is not to be used (and

Thank you for the link. Documentation/devicetree/bindings/riscv/cpus.yaml only defines where the property is not allowed. It does *not* define how this property is to be used and what its meaning

It refers to the hardware clock which is used to drive the counter and not the RTC.

This property is defined in the cpus node for riscv: https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/riscv/cpus.yaml. We can refer to this in the platform spec.

I am planning to add an implementation note in the next version of the patch which will provide more details about how the software can use it. Thanks, Mayuresh.

Mayuresh Chitale <mchitale@...> 於 2021年4月11日 週日 下午11:03寫道： What Clock refers to here? The oscillator to the system peripherals or the RTC which is optional for Linux2022 but has

Am 24. April 2021 20:37:58 MESZ schrieb Sean Anderson <seanga2@...>: [1] is about saving configuration data in the SoC. It is not about the format in which the data is presented by the