riscv: dts: tenstorrent: Add Atlantis platform
Subsystems (6)
v3 cover riscv: dts: tenstorrent: Add Atlantis platform
Add initial support for the Tenstorrent Atlantis platform, based on the Atlantis SoC featuring 8x RVA23-compliant Tenstorrent Ascalon-XG cores.
The series adds a bare bones device tree with the CPU, interrupt controllers and a UART.
Patches 1, 2, 3, 5, and 6 add compatibles or extensions to existing bindings.
Patch 4 adds a binding for the aclint timer device, with a new rationale for including it following discussion with Conor at Plumbers.
The series has been boot tested on QEMU and internal development platforms.
v2:
https://lore.kernel.org/linux-riscv/[email protected]/
Changes since v2:
- Fixes to prcm_rcpu and aplic dt nodes
- Drop uart1 clock override. UART now depends on a working PRCM driver
- Drop bootargs console=ttyS0 in favour of stdout-path
- Justify aclint mtimer bindings
Changes since v1:
- Rework mtimer bindings, fix reg property, update compatible and use priv spec as reference
- Drop Drew's sob from bindings patches I wrote
- Add Drew's co-developed-by to dts patch
- Correct aplic num-sources
Drew Fustini (1):
dt-bindings: riscv: add Smrnmi extension description
Joel Stanley (6):
dt-bindings: aplic: Add Tenstorrent Atlantis compatible
dt-bindings: imsics: Add Tenstorrent Atlantis compatible
dt-bindings: riscv: cpus: Add Tenstorrent Ascalon
dt-bindings: timer: Add RISC-V ACLINT mtimer bindings
dt-bindings: riscv: Add Tenstorrent Atlantis platform
riscv: dts: tenstorrent: Add Atlantis platform
MAINTAINERS | 1 + .../interrupt-controller/riscv,aplic.yaml | 1 + .../interrupt-controller/riscv,imsics.yaml | 1 + .../devicetree/bindings/riscv/cpus.yaml | 5 + .../devicetree/bindings/riscv/extensions.yaml | 6 + .../bindings/riscv/tenstorrent.yaml | 4 + .../bindings/timer/riscv,aclint-mtimer.yaml | 56 +++ arch/riscv/boot/dts/tenstorrent/Makefile | 1 + .../boot/dts/tenstorrent/atlantis-evb.dts | 29 ++ .../boot/dts/tenstorrent/atlantis-soc.dtsi | 473 ++++++++++++++++++ 10 files changed, 577 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml create mode 100644 arch/riscv/boot/dts/tenstorrent/atlantis-evb.dts create mode 100644 arch/riscv/boot/dts/tenstorrent/atlantis-soc.dtsi
Signature · 1 line
2.47.3
PATCH v3 1/7 dt-bindings: aplic: Add Tenstorrent Atlantis compatible
Add compatible for APLIC in Tenstorrent Atlantis SoC.
---
v3: No changes, pick up review tag
--- .../devicetree/bindings/interrupt-controller/riscv,aplic.yaml | 1 + 1 file changed, 1 insertion(+)
Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml +1 -0
@@ -29,6 +29,7 @@ properties: - enum: - qemu,aplic - spacemit,k3-aplic + - tenstorrent,atlantis-aplic - const: riscv,aplic reg:
Signature · 1 line
2.47.3
Re: [PATCH v3 1/7] dt-bindings: aplic: Add Tenstorrent Atlantis compatible
pw-bot: not-applicable
PATCH v3 2/7 dt-bindings: imsics: Add Tenstorrent Atlantis compatible
In reply to Joel StanleyAdd compatible for IMSICS in Tenstorrent Atlantis SoC.
---
v3: No changes, pick up review tags
--- .../devicetree/bindings/interrupt-controller/riscv,imsics.yaml | 1 + 1 file changed, 1 insertion(+)
Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml +1 -0
@@ -49,6 +49,7 @@ properties: - enum: - qemu,imsics - spacemit,k3-imsics + - tenstorrent,atlantis-imsics - const: riscv,imsics reg:
Signature · 1 line
2.47.3
PATCH v3 3/7 dt-bindings: riscv: cpus: Add Tenstorrent Ascalon
In reply to Joel StanleyAdd Tenstorrent Ascalon microarchitecture and the Tenstorrent Ascalon-XG core.
---
v3: No changes, pick up review tags
--- Documentation/devicetree/bindings/riscv/cpus.yaml | 5 +++++ 1 file changed, 5 insertions(+)
Documentation/devicetree/bindings/riscv/cpus.yaml +5 -0
@@ -75,6 +75,11 @@ properties: - sifive,x280 - const: sifive,rocket0 - const: riscv + - items: + - enum: + - tenstorrent,ascalon-xg + - const: tenstorrent,ascalon + - const: riscv - const: riscv # Simulator only description: Identifies that the hart uses the RISC-V instruction set
Signature · 1 line
2.47.3
PATCH v3 4/7 dt-bindings: timer: Add RISC-V ACLINT mtimer bindings
In reply to Joel StanleyDocument the RISC-V ACLINT mtimer and mtimecmp hardware, as described by the riscv-aclint specification, commit 4e570bfd3201f2 [2].
Multiple vendors are shipping silicon with the hardware as described by the specification, which was abandoned[1] as a standalone spec at v1.0-rc4. As we have multiple instances of hardware that implement the spec, the widespread implementation of the spec is de facto ratification, providing a stationary target for the bindings to document and an exception to the policy of not accepting things that are pre-ratification.
[1] https://lists.riscv.org/g/tech-aia/topic/connections_between_aia_and/107177435
[2] https://github.com/riscvarchive/riscv-aclint/blob/4e570bfd3201f2c09e5afd290b5091526b0f099a/riscv-aclint.adoc
---
v3:
- Rework commit message following discussion at LPC
- Add reg-names, rework description, fix example
--- MAINTAINERS | 1 + .../bindings/timer/riscv,aclint-mtimer.yaml | 56 +++++++++++++++++++ 2 files changed, 57 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml
MAINTAINERS +1 -0
@@ -24185,6 +24185,7 @@ S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/tenstorrent/linux.git F: Documentation/devicetree/bindings/clock/tenstorrent,atlantis-prcm-rcpu.yaml F: Documentation/devicetree/bindings/riscv/tenstorrent.yaml +F: Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml F: arch/riscv/boot/dts/tenstorrent/ F: drivers/clk/tenstorrent/ F: drivers/reset/reset-tenstorrent-atlantis.c
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +56 -0
56 lines not on this page · raw message
Signature · 1 line
2.47.3
Re: [PATCH v3 4/7] dt-bindings: timer: Add RISC-V ACLINT mtimer bindings
Quoted 68 lines · Joel Stanley
Document the RISC-V ACLINT mtimer and mtimecmp hardware, as described by the riscv-aclint specification, commit
4e570bfd3201f2[2].Multiple vendors are shipping silicon with the hardware as described by the specification, which was abandoned[1] as a standalone spec at v1.0-rc4. As we have multiple instances of hardware that implement the spec, the widespread implementation of the spec is de facto ratification, providing a stationary target for the bindings to document and an exception to the policy of not accepting things that are pre-ratification.
[1] https://lists.riscv.org/g/tech-aia/topic/connections_between_aia_and/107177435
[2] https://github.com/riscvarchive/riscv-aclint/blob/4e570bfd3201f2c09e5afd290b5091526b0f099a/riscv-aclint.adocSigned-off-by Joel Stanley <[email protected]>---
v3:
- Rework commit message following discussion at LPC
- Add reg-names, rework description, fix example--- MAINTAINERS | 1 + .../bindings/timer/riscv,aclint-mtimer.yaml | 56 +++++++++++++++++++ 2 files changed, 57 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yamlMAINTAINERS +1
-0@@ -24185,6 +24185,7 @@ S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/tenstorrent/linux.git F: Documentation/devicetree/bindings/clock/tenstorrent,atlantis-prcm-rcpu.yaml F: Documentation/devicetree/bindings/riscv/tenstorrent.yaml +F: Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml F: arch/riscv/boot/dts/tenstorrent/ F: drivers/clk/tenstorrent/ F: drivers/reset/reset-tenstorrent-atlantis.cDocumentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +25
-0@@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/riscv,aclint-mtimer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RISC-V Advanced Core Local Interruptor (ACLINT) timer + +maintainers: + - Joel Stanley <[email protected]> + +description: + The RISC-V ACLINT specification defines a set of memory mapped devices which + provide timer functionality for each hart on a multi-hart RISC-V platform. + The mtimer device has a single mtime register and one mtimecmp register per + hart. The specification is at https://github.com/riscvarchive/riscv-aclint/ + +properties: + compatible: + items: + - enum: + - tenstorrent,atlantis-aclint-mtimer + - const: riscv,aclint-mtimer + + reg:
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml line 35
Quoted 10 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +10
-0+ items: + - description: mtime register + - description: mtimecmp registers + + reg-names: + items: + - const: mtime + - const: mtimecmp + + interrupts-extended:
Use interrupts. git grep gives basically zero results for such syntax in the binding.
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml line 37
Quoted 2 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +2
-0+ minItems: 1 + maxItems: 4095
Best regards,
Krzysztof
Re: [PATCH v3 4/7] dt-bindings: timer: Add RISC-V ACLINT mtimer bindings
In reply to Joel StanleyQuoted 11 lines · Joel Stanley
Document the RISC-V ACLINT mtimer and mtimecmp hardware, as described by the riscv-aclint specification, commit
4e570bfd3201f2[2].Multiple vendors are shipping silicon with the hardware as described by the specification, which was abandoned[1] as a standalone spec at v1.0-rc4. As we have multiple instances of hardware that implement the spec, the widespread implementation of the spec is de facto ratification, providing a stationary target for the bindings to document and an exception to the policy of not accepting things that are pre-ratification.
Quoted 7 lines
[1] https://lists.riscv.org/g/tech-aia/topic/connections_between_aia_and/107177435
[2] https://github.com/riscvarchive/riscv-aclint/blob/4e570bfd3201f2c09e5afd290b5091526b0f099a/riscv-aclint.adocSigned-off-by Joel Stanley <[email protected]>---
v3:
- Rework commit message following discussion at LPC
Since I was one of the folks involved in that chat, I am okay with this obviously. I was convinced to change my mind about the use of the riscv vendor prefix because of the widespread adoption.
Quoted 41 lines
- Add reg-names, rework description, fix example
--- MAINTAINERS | 1 + .../bindings/timer/riscv,aclint-mtimer.yaml | 56 +++++++++++++++++++ 2 files changed, 57 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yamlMAINTAINERS +1
-0@@ -24185,6 +24185,7 @@ S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/tenstorrent/linux.git F: Documentation/devicetree/bindings/clock/tenstorrent,atlantis-prcm-rcpu.yaml F: Documentation/devicetree/bindings/riscv/tenstorrent.yaml +F: Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yamlF:
arch/riscv/boot/dts/tenstorrent/
F:drivers/clk/tenstorrent/
F:drivers/reset/reset-tenstorrent-atlantis.cDocumentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +13
-0@@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/riscv,aclint-mtimer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RISC-V Advanced Core Local Interruptor (ACLINT) timer + +maintainers: + - Joel Stanley <[email protected]> + +description: + The RISC-V ACLINT specification defines a set of memory mapped devices which
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml line 23
Quoted 10 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +10
-0+ provide timer functionality for each hart on a multi-hart RISC-V platform. + The mtimer device has a single mtime register and one mtimecmp register per + hart. The specification is at https://github.com/riscvarchive/riscv-aclint/ + +properties: + compatible: + items: + - enum: + - tenstorrent,atlantis-aclint-mtimer + - const: riscv,aclint-mtimer
So, what are we doing about thead,c900-aclint-mtimer.yaml?
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml line 28
Quoted 5 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +5
-0+ + 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/[email protected]/
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml line 41
Quoted 13 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +13
-0+ + 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.
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.
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.
Quoted 19 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +15
-0+ +additionalProperties: false + +examples: + - | + timer@a2180000 { + compatible = "tenstorrent,atlantis-aclint-mtimer", "riscv,aclint-mtimer"; + reg = <0xa2180000 0x8000>, <0xa2188000 0x8000>; + reg-names = "mtime", "mtimecmp"; + interrupts-extended = <&cpu1intc 7>, + <&cpu2intc 7>, + <&cpu3intc 7>, + <&cpu4intc 7>; + }; +...Signature · 1 line
2.47.3
Re: [PATCH v3 4/7] dt-bindings: timer: Add RISC-V ACLINT mtimer bindings
+cc people who might know more about the various hardware this binding supports.
Quoted 10 lines · Conor Dooley
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml line 23
Quoted 8 lines
+++
b/Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yamlDocumentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +6
-0+properties: + compatible: + items: + - enum: + - tenstorrent,atlantis-aclint-mtimer + - const: riscv,aclint-mtimerSo, 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.
Quoted 11 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml line 28
Quoted 6 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +5
-0+ + reg: + items: + - description: mtime register + - description: mtimecmp registersFor 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/[email protected]/
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.
Quoted 7 lines
Quoted 7 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +7
-0+ + reg-names: + items: + - const: mtime + - const: mtimecmp + + interrupts-extended:
Quoted 8 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml line 41
Quoted 6 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +6
-0+ minItems: 1 + maxItems: 4095 + +required: + - compatible + - regYou'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?
Quoted 2 lines
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
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.
Quoted 2 lines
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/[email protected]/
[3] https://lore.kernel.org/all/IA1PR20MB4953D36ABE26822B62415500BBBBA@IA1PR20MB4953.namprd20.prod.outlook.com/
Re: [PATCH v3 4/7] dt-bindings: timer: Add RISC-V ACLINT mtimer bindings
Quoted 58 lines · Joel Stanley
+cc people who might know more about the various hardware this binding supports.
Quoted 10 lines · Conor Dooley
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml line 23
Quoted 8 lines
+++
b/Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yamlDocumentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +6
-0+properties: + compatible: + items: + - enum: + - tenstorrent,atlantis-aclint-mtimer + - const: riscv,aclint-mtimerSo, 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.
Quoted 11 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml line 28
Quoted 6 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +5
-0+ + reg: + items: + - description: mtime register + - description: mtimecmp registersFor 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/[email protected]/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.
Quoted 7 lines
Quoted 7 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +7
-0+ + reg-names: + items: + - const: mtime + - const: mtimecmp + + interrupts-extended:Quoted 8 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml line 41
Quoted 6 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +6
-0+ minItems: 1 + maxItems: 4095 + +required: + - compatible + - regYou've also not made reg-names or interrupts-extended required.
Quoted 5 lines
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.
Quoted 19 lines
Quoted 2 lines
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-mtimerK3 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
Quoted 9 lines
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.
Quoted 11 lines
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.
Quoted 6 lines
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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 7 lines
Cheers,
Joel
[1] https://doc.nucleisys.com/nuclei_spec/isa/timer.html
[2] https://lore.kernel.org/all/[email protected]/
[3] https://lore.kernel.org/all/IA1PR20MB4953D36ABE26822B62415500BBBBA@IA1PR20MB4953.namprd20.prod.outlook.com/
Regards,
Inochi
Re: [PATCH v3 4/7] dt-bindings: timer: Add RISC-V ACLINT mtimer bindings
+CC Aleska,
Quoted 65 lines · Inochi Amaoto
Quoted 58 lines · Joel Stanley
+cc people who might know more about the various hardware this binding supports.
Quoted 10 lines · Conor Dooley
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml line 23
Quoted 8 lines
+++
b/Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yamlDocumentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +6
-0+properties: + compatible: + items: + - enum: + - tenstorrent,atlantis-aclint-mtimer + - const: riscv,aclint-mtimerSo, 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.
Quoted 11 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml line 28
Quoted 6 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +5
-0+ + reg: + items: + - description: mtime register + - description: mtimecmp registersFor 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/[email protected]/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.
Quoted 7 lines
Quoted 7 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +7
-0+ + reg-names: + items: + - const: mtime + - const: mtimecmp + + interrupts-extended:Quoted 8 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml line 41
Quoted 6 lines
Documentation/devicetree/bindings/timer/riscv,aclint-mtimer.yaml new file +6
-0+ minItems: 1 + maxItems: 4095 + +required: + - compatible + - regYou've also not made reg-names or interrupts-extended required.
Quoted 5 lines
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?
Quoted 27 lines
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.
Quoted 20 lines
Quoted 2 lines
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-mtimerK3 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.
/sigh. Aleksa, can we sort this out please as part of whatever revision is made to the mtimer patch in your series?
Quoted 28 lines
Quoted 8 lines
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-mtimerFor 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.
Quoted 15 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
I think we need to make reg-names mandatory and permit free ordering of the reg entries and make reg-names mandatory.
QEMU will need to be changed to add reg-names and U-Boot changed to use reg-names - I think neither should be controversial, since no hardware actually implementing this device follows the qemu/opensbi ordering.
Maybe the right thing to do is:
| items: | - enum [mtime, mtimecmp] | - const: mtimecmp
which forces mtime to be first when there are two items, not really problematic given there's currently no devices with two with a binding that need modification given the mips thing is not yet merged so we can update it to be like this.
Maybe for safety we abstain from retrofitting riscv,aclint-mtimer to the existing devices (although I still think they should be merged into one file) so that they don't run into U-Boot failures.
Cheers,
Conor.
Quoted 17 lines
Quoted 7 lines
Quoted 3 lines
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.
Quoted 7 lines
Cheers,
Joel
[1] https://doc.nucleisys.com/nuclei_spec/isa/timer.html
[2] https://lore.kernel.org/all/[email protected]/
[3] https://lore.kernel.org/all/IA1PR20MB4953D36ABE26822B62415500BBBBA@IA1PR20MB4953.namprd20.prod.outlook.com/Regards,
Inochi
PATCH v3 5/7 dt-bindings: riscv: add Smrnmi extension description
In reply to Joel StanleyFrom: Drew Fustini <[email protected]>
Add description for the Smrnmi extension (Resumable Non-Maskable Interrupts) as ratified in 35eb3948bf0b ("Merge pull request #1492 from riscv/smrnmi-ratified") of the riscv-isa-manual.
---
v3: No changes
--- Documentation/devicetree/bindings/riscv/extensions.yaml | 6 ++++++ 1 file changed, 6 insertions(+)
Documentation/devicetree/bindings/riscv/extensions.yaml +6 -0
@@ -214,6 +214,12 @@ properties: ratified at commit d70011dde6c2 ("Update to ratified state") of riscv-j-extension. + - const: smrnmi + description: | + The standard Smrnmi extension for Resumable Non-Maskable Interrupts + as ratified in commit 35eb3948bf0b ("Merge pull request #1492 from + riscv/smrnmi-ratified") of the riscv-isa-manual. + - const: smstateen description: | The standard Smstateen extension for controlling access to CSRs
Signature · 1 line
2.47.3
PATCH v3 6/7 dt-bindings: riscv: Add Tenstorrent Atlantis platform
In reply to Joel StanleyAdd compatible for the Tenstorrent Atlantis platform.
---
v3: No changes, pick up review tags
--- Documentation/devicetree/bindings/riscv/tenstorrent.yaml | 4 ++++ 1 file changed, 4 insertions(+)
Documentation/devicetree/bindings/riscv/tenstorrent.yaml +4 -0
@@ -22,6 +22,10 @@ properties: items: - const: tenstorrent,blackhole-card - const: tenstorrent,blackhole + - description: Tenstorrent Atlantis + items: + - const: tenstorrent,atlantis-evb + - const: tenstorrent,atlantis additionalProperties: true
Signature · 1 line
2.47.3
PATCH v3 7/7 riscv: dts: tenstorrent: Add Atlantis platform
In reply to Joel StanleyAdd initial support for the Tenstorrent Atlantis platform, based on the Atlantis SoC featuring 8x RVA23-compliant Tenstorrent Ascalon-XG cores.
The evb machine represents an internal bringup vehicle with just the interrupt controllers and a UART. This will be updated in time with a full featured machine once details are available.
The chosen node sets bootargs to earlycon=sbi to aid debugging early boot, as the platform may not have a bootloader to fill out the chosen node.
The m-mode IMSIC setting riscv,guest-index-bits looks strange, as m-mode devices don't have guest interrupt files. The spacing (stride) between m-mode files is the same 256KB as s-mode on Atlantis, so we set the property so software (eg OpenSBI) can derive the layout.
The SoC has a 8-way 64KB L1I, 4-way 256KB L1D, and a 24-way 12MB last level cache shared across all cores.
---
v3:
- Fix prcm_rcpu parent
- Delegate all aplic irqs
- Drop uart1 clock override
- Use earlycon=sbi, document rationale
- Fix mistakes in cache info
v2:
- Update mtimer compatible
- Add Drew's co-developed-by
- Correct aplic num-sources count
--- arch/riscv/boot/dts/tenstorrent/Makefile | 1 + .../boot/dts/tenstorrent/atlantis-evb.dts | 29 ++ .../boot/dts/tenstorrent/atlantis-soc.dtsi | 473 ++++++++++++++++++ 3 files changed, 503 insertions(+) create mode 100644 arch/riscv/boot/dts/tenstorrent/atlantis-evb.dts create mode 100644 arch/riscv/boot/dts/tenstorrent/atlantis-soc.dtsi
arch/riscv/boot/dts/tenstorrent/Makefile +1 -0
@@ -1,2 +1,3 @@ # SPDX-License-Identifier: GPL-2.0 dtb-$(CONFIG_ARCH_TENSTORRENT) += blackhole-card.dtb +dtb-$(CONFIG_ARCH_TENSTORRENT) += atlantis-evb.dtb
arch/riscv/boot/dts/tenstorrent/atlantis-evb.dts new file +29 -0
@@ -0,0 +1,29 @@ +// SPDX-License-Identifier: (GPL-2.0 OR MIT) +// Copyright 2026 Tenstorrent +/dts-v1/; + +#include "atlantis-soc.dtsi" + +/ { + model = "Tenstorrent Atlantis development platform"; + compatible = "tenstorrent,atlantis-evb", "tenstorrent,atlantis"; + + memory@0 { + device_type = "memory"; + reg = <0x0 0x00000000 0x0 0x80000000>, + <0x1 0x80000000 0x0 0x80000000>; + }; + + aliases { + serial0 = &uart1; + }; + + chosen { + bootargs = "earlycon=sbi"; + stdout-path = "serial0:115200"; + }; +}; + +&uart1 { + status = "okay"; +};
arch/riscv/boot/dts/tenstorrent/atlantis-soc.dtsi new file +473 -0
473 lines not on this page · raw message
Signature · 1 line
2.47.3
Quoted 97 lines · Joel Stanley
Add initial support for the Tenstorrent Atlantis platform, based on the Atlantis SoC featuring 8x RVA23-compliant Tenstorrent Ascalon-XG cores.
The evb machine represents an internal bringup vehicle with just the interrupt controllers and a UART. This will be updated in time with a full featured machine once details are available.
The chosen node sets bootargs to earlycon=sbi to aid debugging early boot, as the platform may not have a bootloader to fill out the chosen node.
The m-mode IMSIC setting riscv,guest-index-bits looks strange, as m-mode devices don't have guest interrupt files. The spacing (stride) between m-mode files is the same 256KB as s-mode on Atlantis, so we set the property so software (eg OpenSBI) can derive the layout.
The SoC has a 8-way 64KB L1I, 4-way 256KB L1D, and a 24-way 12MB last level cache shared across all cores.
Co-developed-by Drew Fustini <[email protected]>Signed-off-by Drew Fustini <[email protected]>Signed-off-by Joel Stanley <[email protected]>---
v3:
- Fixprcm_rcpuparent
- Delegate all aplic irqs
- Drop uart1 clock override
- Use earlycon=sbi, document rationale
- Fix mistakes in cache infov2:
- Update mtimer compatible
- Add Drew's co-developed-by
- Correct aplic num-sources count--- arch/riscv/boot/dts/tenstorrent/Makefile | 1 + .../boot/dts/tenstorrent/atlantis-evb.dts | 29 ++ .../boot/dts/tenstorrent/atlantis-soc.dtsi | 473 ++++++++++++++++++ 3 files changed, 503 insertions(+) create mode 100644 arch/riscv/boot/dts/tenstorrent/atlantis-evb.dts create mode 100644 arch/riscv/boot/dts/tenstorrent/atlantis-soc.dtsiarch/riscv/boot/dts/tenstorrent/Makefile +1
-0@@ -1,2 +1,3 @@ # SPDX-License-Identifier: GPL-2.0 dtb-$(CONFIG_ARCH_TENSTORRENT) += blackhole-card.dtb +dtb-$(CONFIG_ARCH_TENSTORRENT) += atlantis-evb.dtbarch/riscv/boot/dts/tenstorrent/atlantis-evb.dts new file +29
-0@@ -0,0 +1,29 @@ +// SPDX-License-Identifier: (GPL-2.0 OR MIT) +// Copyright 2026 Tenstorrent +/dts-v1/; + +#include "atlantis-soc.dtsi" + +/ { + model = "Tenstorrent Atlantis development platform"; + compatible = "tenstorrent,atlantis-evb", "tenstorrent,atlantis"; + + memory@0 { + device_type = "memory"; + reg = <0x0 0x00000000 0x0 0x80000000>, + <0x1 0x80000000 0x0 0x80000000>; + }; + + aliases { + serial0 = &uart1; + }; + + chosen { + bootargs = "earlycon=sbi"; + stdout-path = "serial0:115200"; + }; +}; + +&uart1 { + status = "okay"; +};arch/riscv/boot/dts/tenstorrent/atlantis-soc.dtsi new file +5
-0@@ -0,0 +1,473 @@ +// SPDX-License-Identifier: (GPL-2.0 OR MIT) +// Copyright 2026 Tenstorrent +/dts-v1/; + +#include <dt-bindings/interrupt-controller/irq.h>
arch/riscv/boot/dts/tenstorrent/atlantis-soc.dtsi line 15
Quoted 10 lines
arch/riscv/boot/dts/tenstorrent/atlantis-soc.dtsi new file +10
-0+#include <dt-bindings/clock/tenstorrent,atlantis-prcm-rcpu.h> + +/ { + model = "Tenstorrent Atlantis"; + compatible = "tenstorrent,atlantis"; + + #address-cells = <2>; + #size-cells = <2>; + + cpus {
Please add a cpus: label here (like below). It'll be useful if we need to refer to this node in the u-boot DT.
cpus: cpus {
};Quoted 7 lines
arch/riscv/boot/dts/tenstorrent/atlantis-soc.dtsi new file +7
-0+ #address-cells = <1>; + #size-cells = <0>; + timebase-frequency = <1000000000>; + + cpu0: cpu@0 { + compatible = "tenstorrent,ascalon-xg", "tenstorrent,ascalon", "riscv"; + reg = <0>;
Quoting Joel Stanley (2026-11-09 06:10:47)
Quoted 10 lines
Add initial support for the Tenstorrent Atlantis platform, based on the Atlantis SoC featuring 8x RVA23-compliant Tenstorrent Ascalon-XG cores.
The evb machine represents an internal bringup vehicle with just the interrupt controllers and a UART. This will be updated in time with a full featured machine once details are available.
The chosen node sets bootargs to earlycon=sbi to aid debugging early boot, as the platform may not have a bootloader to fill out the chosen node.
Does this mean OpenSBI uses a different uart from uart1?
If not that means both Linux in S-mode and OpenSBI in M-mode will both try to use uart1 at the same time. It might work by chance, but a much better solution would be to just use "earlycon". You already define chosen/stdout-path to point at uart1 and the driver for 'snps,dw-apb-uart' implements earlycon so it should work much the same.
/Emil