Re: [PATCH v3 10/11] riscv: dts: spacemit: add initial device tree of SpacemiT K3 SoC

[Samuel Holland <samuel.holland@sifive.com>]

Hi Guodong,

On 2026-01-09 3:58 AM, Guodong Xu wrote:
> Hi, Samuel
> 
> On Fri, Jan 9, 2026 at 2:19 AM Samuel Holland <samuel.holland@sifive.com> wrote:
>>
>> On 2026-01-08 6:26 AM, Guodong Xu wrote:
>>> SpacemiT K3 is equipped with 8 X100 cores, which are RVA23 compliant.
>>> Add nodes of uarts, timer and interrupt-controllers.
>>>
>>> Signed-off-by: Guodong Xu <guodong@riscstar.com>
>>> ---
>>> v3: Remove "supm" from the riscv,isa-extensions list.
>>> v2: Remove aliases from k3.dtsi, they should be in board DTS.
>>>     Updated riscv,isa-extensions with new extensions from the extensions.yaml
>>> ---
>>>  arch/riscv/boot/dts/spacemit/k3.dtsi | 548 +++++++++++++++++++++++++++++++++++
>>>  1 file changed, 548 insertions(+)
>>>
>>> diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
>>> new file mode 100644
>>> index 0000000000000000000000000000000000000000..be9335fba32cb9e81915b2b91cf08c55a5e96809
>>> --- /dev/null
>>> +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
>>> [...]
>>> +                     reg = <0x0 0xe0400000 0x0 0x00200000>;
>>> +                     interrupt-controller;
>>> +                     #interrupt-cells = <0>;
>>> +                     msi-controller;
>>> +                     #msi-cells = <0>;
>>> +                     interrupts-extended = <&cpu0_intc 9>, <&cpu1_intc 9>,
>>> +                                           <&cpu2_intc 9>, <&cpu3_intc 9>,
>>> +                                           <&cpu4_intc 9>, <&cpu5_intc 9>,
>>> +                                           <&cpu6_intc 9>, <&cpu7_intc 9>;
>>> +                     riscv,num-ids = <511>;
>>> +                     riscv,num-guest-ids = <511>;
>>> +                     riscv,hart-index-bits = <4>;
>>> +                     riscv,guest-index-bits = <6>;
>>> +             };
>>> +
>>> +             saplic: interrupt-controller@e0804000 {
>>> +                     compatible = "spacemit,k3-aplic", "riscv,aplic";
>>> +                     reg = <0x0 0xe0804000 0x0 0x4000>;
>>> +                     msi-parent = <&simsic>;
>>> +                     #interrupt-cells = <2>;
>>> +                     interrupt-controller;
>>> +                     riscv,num-sources = <512>;
>>> +             };
>>
>> Does the chip also have M-mode IMSIC and APLIC instances? Those need to be
>> represented in the devicetree as well, for M-mode firmware to access them, just
>> like the CLINT below.
> 
> Yes, the K3 chip does have M-mode IMSIC and APLIC instances. Currently, the
> boot firmware (U-Boot) transfers information about these nodes to OpenSBI.
> However, you are correct that they should be properly described in the DT.
> 
> In the next version, I will add the M-mode APLIC (maplic) and IMSIC (mimsic)
> nodes to k3.dtsi, for topology representation and potential firmware usage.
> I will set their status to "disabled" because exposing them as "okay" to Linux
> causes access faults during driver probing.
> 
> Please let me know if this approach (adding them but keeping them disabled)
> looks okay to you.

I think this is a reasonable compromise.

Personally, I think of the DTS files in the Linux repository as the "static"
devicetree, which should describe a "complete" view of the hardware--that is, as
seen from the highest privilege level. Then it is the responsibility of that
highly-privileged software to modify the FDT as needed to provide a limited view
of the hardware to lower-privileged software. And this modification is exactly
what OpenSBI does before it passes the FDT to U-Boot. So the "static" devicetree
would not disable these M-mode-only devices.

However, I recognize that people want to use the DTB files generated by the
Linux build process with Linux directly, ignoring the firmware-provided FDT. In
that cases the M-mode-only devices need to be disabled. And then you need a
-u-boot.dtsi file to set `status = "okay"` for the firmware build. I think
that's a reasonable compromise to make the "static" devicetree as complete as
possible while still being usable directly in S-mode in some cases. (It still
breaks if some peripheral is assigned to a different supervisor domain, or some
DRAM is reserved by M-mode, etc., which is why I really recommend using the
firmware FDT and not a file.)

Regards,
Samuel