Re: [PATCH v3 4/7] dt-bindings: timer: Add RISC-V ACLINT mtimer bindings

[Inochi Amaoto <inochiama@gmail.com>]

On Wed, Nov 11, 2026 at 03:34:26PM +1030, Joel Stanley wrote:
> +cc people who might know more about the various hardware this binding supports.
> 
> On Tue, 10 Nov 2026 at 05:59, Conor Dooley <conor@kernel.org> wrote:
> > > +++ b/Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml
> 
> > > +properties:
> > > +  compatible:
> > > +    items:
> > > +      - enum:
> > > +          - tenstorrent,atlantis-aclint-mtimer
> > > +      - const: riscv,aclint-mtimer
> >
> > So, what are we doing about thead,c900-aclint-mtimer.yaml?
> 
> Once we agree on this binding, I planned to submit a change to bring
> over the devices that implement the common binding. I can do that up
> front instead.
> 
> >
> > > +
> > > +  reg:
> > > +    items:
> > > +      - description: mtime register
> > > +      - description: mtimecmp registers
> >
> > For example, I note that you have mtime and mtimecmp in the opposite
> > order to how the mips folks have had to add the mtime region to that
> > file:
> > https://lore.kernel.org/all/20261103-p8700-dts-v2-6-3ac5d49f2c37@htecgroup.com/
> 
> This is the order OpenSBI has used since v1.0, when support was added
> about five years ago. It reads mtime followed by mtimecmp when there
> are no reg-names:
> 
>  https://github.com/riscv-software-src/opensbi/blob/v1.9/lib/utils/timer/fdt_timer_mtimer.c#L79
> 
> QEMU also generates a dt with mtime followed by mtimecmp, and without reg-names.
> 
> The MIPS ordering works because it specifies reg-names. OpenSBI uses
> reg-names to parse the reg property so it would continue working, but
> u-boot takes index 0 as mtime and ignores reg-names.
> 
> > > +
> > > +  reg-names:
> > > +    items:
> > > +      - const: mtime
> > > +      - const: mtimecmp
> > > +
> > > +  interrupts-extended:
> > > +    minItems: 1
> > > +    maxItems: 4095
> > > +
> > > +required:
> > > +  - compatible
> > > +  - reg
> >
> > You've also not made reg-names or interrupts-extended required.
> 
> That was intentional. A mtimer device without harts attached won't
> have interrupts (opensbi supports this), but I haven't come across a
> system that uses it this way. I have no preference here, what do you
> think?
> 

I think reg-names is required. The spec archive does not requrire the core
implement both MTIME and MTIMECMP. So using reg-name will let the DT parser
does not reply on the order and leave the room for MTIMECMP only devices.

interrupts-extended should also be required, it is kind of weird for 
a zero-interrupt timer.

> > I think we should swap the regs around and make these two required at a
> > minimum, but also "initialise" this file by renaming the existing file.
> 
> Bringing over the other devices sounds like a good idea to me. And I
> appreciate the spelling.
> 
> The nuclei/anlogic boards document mtime[1] support:
> 
>  - nuclei,ux900-aclint-mtimer
>  - anlogic,dr1v90-aclint-mtimer
> 
> K3 has a mtime register (at 0xf181bff8, by experimentation on hardware):
> 
>  - spacemit,k3-aclint-mtimer
> 
> MIPS has it, as per their patch[2]:
> 
>  - gf,mips-p8700-aclint-mtimer
> 
> Note that MIPS have mips,p8700-aclint-mtimer in opensbi.
> 
> T-Head has no mtime[3], just a set of mtimecmp registers. Sophgo are
> unknown, can we assume it is the same design as T-Head?
> 
>  - thead,c900-aclint-mtimer
>  - sophgo,sg2042-aclint-mtimer
>  - sophgo,sg2044-aclint-mtimer
> 

For T-HEAD, IIRC all the design share the same layout. C9XX use the same
layout for both C906/C910/C920. Sophgo is just a SoC vendor, not the
core vendor.

> There are two options for T-Head:
> 
> 1) Leave it in its own binding, because it doesn't have mtime registers.
> 
> 2) Use this binding with an optional reg property for the mtime
> region, which means putting the optional part last.
> 
> If we go with 1 we can preserve the mtime, mtimecmp ordering, matching
> u-boot, opensbi, qemu. If we go with 2 we put mtime last and make
> reg-names required.
> 
> The current K3 and Anlogic current device trees would need an update
> to their reg property to describe mtime when adding the riscv
> compatible.
> 
> I lean towards 1 because it reduces churn in firmware.
> 

I prefer 2. as the ACLINT is designed for modularity, it should 
tolerate one that does not have MTIME.

> > My ~assumption~hope is that all of the devices in that file have
> > implemented the aclint spec at the -rc1 revision that we're citing here.
> 
> (-rc4). Yep, we can move the majority of the compatibles into this
> binding. The T-Head family might be the exception.
> 
> Cheers,
> 
> Joel
> 
> [1] https://doc.nucleisys.com/nuclei_spec/isa/timer.html
> [2] https://lore.kernel.org/all/20261103-p8700-dts-v2-6-3ac5d49f2c37@htecgroup.com/
> [3] https://lore.kernel.org/all/IA1PR20MB4953D36ABE26822B62415500BBBBA@IA1PR20MB4953.namprd20.prod.outlook.com/

Regards,
Inochi

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv