On Fri, Jul 16, 2021 at 8:43 PM Anup Patel <Anup.Patel@...> wrote:

Both MTIME and MTIMECMP are 64-bit wide registers from device perspective (i.e. from ACLINT specification perspective). The ACLINT specification does not mandate 32-bit or 64-bit accesses for RISC-V

HARTs. This means by default software will assume 64-bit accesses on RV64 and 32-bit accesses on RV32. We can certainly have an optional boolean DT property “mtimer,64bit-access-not-supported” which will force software to use 32-bit accesses on RV64 system.

While these registers are architecturally 64-bit registers, in many systems they will be accessed over a simple 32-bit bus that doesn't support 64-bit accesses.  This will probably be true in many systems (for example some (or maybe most?) SiFive SoCs such as the FU540 SoC).

  Who wants to spend the hardware on a 2x wide bus for negligible benefit.

  Plus some common bus standards won't support both 32-bit and 64-bit accesses, which complicates mapping and accessing 32-bit registers over a bus that only supports 64-bit accesses.  (Use of a 32-bit bus will tend to be true in both embedded and even high-end systems.  In the latter case the main coherent bus may be quite wide and capable of multi-width accesses, but no one wants to impose the complexity of interfacing to that bus onto all the SoC devices that have memory-mapped registers and want to have the simplest possible bus standard to interface to.)

The point of what was suggested as a result of the email discussions with Andrew a year ago, is that support for the common case should be required (e.g. 32-bit accesses) and then have a DT property that says 64-bit accesses may also be used by software.

Greg