Re: [PATCH v2 4/9] dt-bindings: interrupt-controller: Add RISC-V incoming MSI controller

From: Anup Patel
Date: Sun Feb 19 2023 - 22:15:46 EST


On Thu, Jan 5, 2023 at 4:51 AM Conor Dooley <conor@xxxxxxxxxx> wrote:
>
> Hey Anup,
>
> On Tue, Jan 03, 2023 at 07:44:04PM +0530, Anup Patel wrote:
> > We add DT bindings document for the RISC-V incoming MSI controller
> > (IMSIC) defined by the RISC-V advanced interrupt architecture (AIA)
> > specification.
> >
> > Signed-off-by: Anup Patel <apatel@xxxxxxxxxxxxxxxx>
> > + The IMSIC is a per-CPU (or per-HART) device with separate interrupt file
> > + for each privilege level (machine or supervisor).
>
> > + The device tree of a RISC-V platform will have one IMSIC device tree node
> > + for each privilege level (machine or supervisor) which collectively describe
> > + IMSIC interrupt files at that privilege level across CPUs (or HARTs).
>
> > +examples:
> > + - |
> > + // Example 1 (Machine-level IMSIC files with just one group):
> > +
> > + imsic_mlevel: interrupt-controller@24000000 {
> > + compatible = "riscv,qemu-imsics", "riscv,imsics";
> > + interrupts-extended = <&cpu1_intc 11>,
> > + <&cpu2_intc 11>,
> > + <&cpu3_intc 11>,
> > + <&cpu4_intc 11>;
> > + reg = <0x28000000 0x4000>;
> > + interrupt-controller;
> > + #interrupt-cells = <0>;
> > + msi-controller;
> > + riscv,num-ids = <127>;
> > + };
> > +
> > + - |
> > + // Example 2 (Supervisor-level IMSIC files with two groups):
> > +
> > + imsic_slevel: interrupt-controller@28000000 {
> > + compatible = "riscv,qemu-imsics", "riscv,imsics";
> > + interrupts-extended = <&cpu1_intc 9>,
> > + <&cpu2_intc 9>,
> > + <&cpu3_intc 9>,
> > + <&cpu4_intc 9>;
> > + reg = <0x28000000 0x2000>, /* Group0 IMSICs */
> > + <0x29000000 0x2000>; /* Group1 IMSICs */
> > + interrupt-controller;
> > + #interrupt-cells = <0>;
> > + msi-controller;
> > + riscv,num-ids = <127>;
> > + riscv,group-index-bits = <1>;
> > + riscv,group-index-shift = <24>;
> > + };
>
> How is, say linux, meant to know which of the per-level imsic DT nodes
> applies to it?
> I had a quick look in the driver, but could see no mechanism for it.
> Apologies if I missed something obvious!

This is very straightforward. We simply look at the local interrupt number
in the "interrupts-extended" DT property.

Currently, we use the same technique in PLIC driver to distinguish
M-mode PLIC context from S-mode PLIC context.

Regards,
Anup