| Message ID | 20180725093649.32332-7-hch@lst.de |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | None | expand |
On Wed, Jul 25, 2018 at 11:36:49AM +0200, Christoph Hellwig wrote: > From: Palmer Dabbelt <palmer@dabbelt.com> > > This patch adds documentation for the platform-level interrupt > controller (PLIC) found in all RISC-V systems. This interrupt > controller routes interrupts from all the devices in the system to each > hart-local interrupt controller. > > Note: the DTS bindings for the PLIC aren't set in stone yet, as we might > want to change how we're specifying holes in the hart list. > > Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com> > --- > .../interrupt-controller/riscv,plic0.txt | 55 +++++++++++++++++++ > 1 file changed, 55 insertions(+) > create mode 100644 Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt > > diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt b/Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt > new file mode 100644 > index 000000000000..99cd359dbd43 > --- /dev/null > +++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt > @@ -0,0 +1,55 @@ > +RISC-V Platform-Level Interrupt Controller (PLIC) > +------------------------------------------------- > + > +The RISC-V supervisor ISA specification allows for the presence of a > +platform-level interrupt controller (PLIC). The PLIC connects all external > +interrupts in the system to all hart contexts in the system, via the external > +interrupt source in each hart's hart-local interrupt controller (HLIC). A hart > +context is a privilege mode in a hardware execution thread. For example, in > +an 4 core system with 2-way SMT, you have 8 harts and probably at least two > +privilege modes per hart; machine mode and supervisor mode. > + > +Each interrupt can be enabled on per-context basis. Any context can claim > +a pending enabled interrupt and then release it once it has been handled. > + > +Each interrupt has a configurable priority. Higher priority interrupts are > +serviced firs. Each context can specify a priority threshold. Interrupts > +with priority below this threshold will not cause the PLIC to raise its > +interrupt line leading to the context. > + > +While the PLIC supports both edge-triggered and level-triggered interrupts, > +interrupt handlers are oblivious to this distinction and therefor it is not > +specific in the PLIC device-tree binding. > + > +While the RISC-V ISA doesn't specify a memory layout for the PLIC, the > +"riscv,plic0" device is a concrete implementation of the PLIC that contains a > +specific memory layout. More details about the memory layout of the > +"riscv,plic0" device can be found as a comment in the device driver, or as part > +of the SiFive U5 Coreplex Series Manual (page 22 of the PDF of version 1.0) > +<https://www.sifive.com/documentation/coreplex/u5-coreplex-series-manual/> > + > +Required properties: > +- compatible : "riscv,plic0" Perhaps this should be 'sifive,plic0' Normally this would have an SoC specific compatible too. Sometimes we can get away without, but it doesn't seem like the PLIC is very tightly specified nor has common implementations. > +- #address-cells : should be <0> > +- #interrupt-cells : should be <1> > +- interrupt-controller : Identifies the node as an interrupt controller > +- reg : Should contain 1 register range (address and length) > +- interrupts-extended : Specifies which contexts are connected to the PLIC, > + with "-1" specifying that a context is not present. > + > +Example: > + > + plic: interrupt-controller@c000000 { > + #address-cells = <0>; > + #interrupt-cells = <1>; > + compatible = "riscv,plic0"; > + interrupt-controller; > + interrupts-extended = < > + &cpu0-intc 11 > + &cpu1-intc 11 &cpu1-intc 9 > + &cpu2-intc 11 &cpu2-intc 9 > + &cpu3-intc 11 &cpu3-intc 9 > + &cpu4-intc 11 &cpu4-intc 9>; > + reg = <0xc000000 0x4000000>; > + riscv,ndev = <10>; Not documented. > + }; > -- > 2.18.0 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jul 31, 2018 at 04:46:30PM -0600, Rob Herring wrote: > Perhaps this should be 'sifive,plic0' Excepet for the fact this the old name has already been in shipping hardware and release of qemu and other emulators it should. > Normally this would have an SoC specific compatible too. Sometimes we > can get away without, but it doesn't seem like the PLIC is very tightly > specified nor has common implementations. It is a giant f***cking mess to be honest. Adding a highlevel spec to the ISA but not a register layout is completely idotic, but if you look at the current riscv-sw list this decision is still defended by SiFive / the RISC-V foundation. The whole stale of the RISC-V platform Ecosystem is rather pathetic unfortunately, and people don't seem to be willing to learn from past good practice nor mistakes in ARM land. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Aug 1, 2018 at 1:12 AM Christoph Hellwig <hch@lst.de> wrote: > > On Tue, Jul 31, 2018 at 04:46:30PM -0600, Rob Herring wrote: > > Perhaps this should be 'sifive,plic0' > > Excepet for the fact this the old name has already been in shipping > hardware and release of qemu and other emulators it should. Not really my problem that they didn't follow the process and upstream their binding first. But this alone is just a string identifier, so I don't really care that much. If things are really a mess, then the next implementations will have to have better compatible strings. More likely, I'll just see folks trying to add various properties to deal with all the differences. You could always define a better compatible and leave 'riscv,plic0' as a fallback to avoid breaking things. > > Normally this would have an SoC specific compatible too. Sometimes we > > can get away without, but it doesn't seem like the PLIC is very tightly > > specified nor has common implementations. > > It is a giant f***cking mess to be honest. Adding a highlevel spec > to the ISA but not a register layout is completely idotic, but if you > look at the current riscv-sw list this decision is still defended by > SiFive / the RISC-V foundation. The whole stale of the RISC-V platform > Ecosystem is rather pathetic unfortunately, and people don't seem to > be willing to learn from past good practice nor mistakes in ARM land. Interrupt controllers are where the differentiation is. ;) Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Aug 01, 2018 at 12:26:31PM -0600, Rob Herring wrote: > Not really my problem that they didn't follow the process and upstream > their binding first. But this alone is just a string identifier, so I > don't really care that much. If things are really a mess, then the > next implementations will have to have better compatible strings. More > likely, I'll just see folks trying to add various properties to deal > with all the differences. > > You could always define a better compatible and leave 'riscv,plic0' as > a fallback to avoid breaking things. Is there any better way to define a compatible other than having duplicate IRQCHIP_DECLARE() statements? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 2, 2018 at 3:50 AM Christoph Hellwig <hch@lst.de> wrote: > > On Wed, Aug 01, 2018 at 12:26:31PM -0600, Rob Herring wrote: > > Not really my problem that they didn't follow the process and upstream > > their binding first. But this alone is just a string identifier, so I > > don't really care that much. If things are really a mess, then the > > next implementations will have to have better compatible strings. More > > likely, I'll just see folks trying to add various properties to deal > > with all the differences. > > > > You could always define a better compatible and leave 'riscv,plic0' as > > a fallback to avoid breaking things. > > Is there any better way to define a compatible other than having > duplicate IRQCHIP_DECLARE() statements? No, but you only need the fallback if the compatible is '"sifive,plic0", "riscv,plic0";'. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 01 Aug 2018 11:26:31 PDT (-0700), robh@kernel.org wrote: > On Wed, Aug 1, 2018 at 1:12 AM Christoph Hellwig <hch@lst.de> wrote: >> >> On Tue, Jul 31, 2018 at 04:46:30PM -0600, Rob Herring wrote: >> > Perhaps this should be 'sifive,plic0' >> >> Excepet for the fact this the old name has already been in shipping >> hardware and release of qemu and other emulators it should. > > Not really my problem that they didn't follow the process and upstream > their binding first. But this alone is just a string identifier, so I > don't really care that much. If things are really a mess, then the > next implementations will have to have better compatible strings. More > likely, I'll just see folks trying to add various properties to deal > with all the differences. > > You could always define a better compatible and leave 'riscv,plic0' as > a fallback to avoid breaking things. Ya, sorry about that. FWIW, we don't consider any of the bindings stable until they're actually accepted upstream, so it's on us to fix our bootloaders to match what actually lands upstream. Luckily there's not that much hardware out there and none of it is in production, so I'm OK forcing people to upgrade bootloaders to make this all work. I think it's probably best to leave the extra compat string out of the kernel proper, as then it'll never be enshrined as a RISC-V standard. >> > Normally this would have an SoC specific compatible too. Sometimes we >> > can get away without, but it doesn't seem like the PLIC is very tightly >> > specified nor has common implementations. >> >> It is a giant f***cking mess to be honest. Adding a highlevel spec >> to the ISA but not a register layout is completely idotic, but if you >> look at the current riscv-sw list this decision is still defended by >> SiFive / the RISC-V foundation. The whole stale of the RISC-V platform >> Ecosystem is rather pathetic unfortunately, and people don't seem to >> be willing to learn from past good practice nor mistakes in ARM land. > > Interrupt controllers are where the differentiation is. ;) Again, sorry about that :). The RISC-V platform specification really should have started a year ago, but I'm afraid there's just a bit too much going on on my end. If it helps any, we just submitted a plumbers dev room with one topic being the RISC-V platform spec, so I guess I'm in official trouble now it there isn't at least something to talk about by November... -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt b/Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt new file mode 100644 index 000000000000..99cd359dbd43 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt @@ -0,0 +1,55 @@ +RISC-V Platform-Level Interrupt Controller (PLIC) +------------------------------------------------- + +The RISC-V supervisor ISA specification allows for the presence of a +platform-level interrupt controller (PLIC). The PLIC connects all external +interrupts in the system to all hart contexts in the system, via the external +interrupt source in each hart's hart-local interrupt controller (HLIC). A hart +context is a privilege mode in a hardware execution thread. For example, in +an 4 core system with 2-way SMT, you have 8 harts and probably at least two +privilege modes per hart; machine mode and supervisor mode. + +Each interrupt can be enabled on per-context basis. Any context can claim +a pending enabled interrupt and then release it once it has been handled. + +Each interrupt has a configurable priority. Higher priority interrupts are +serviced firs. Each context can specify a priority threshold. Interrupts +with priority below this threshold will not cause the PLIC to raise its +interrupt line leading to the context. + +While the PLIC supports both edge-triggered and level-triggered interrupts, +interrupt handlers are oblivious to this distinction and therefor it is not +specific in the PLIC device-tree binding. + +While the RISC-V ISA doesn't specify a memory layout for the PLIC, the +"riscv,plic0" device is a concrete implementation of the PLIC that contains a +specific memory layout. More details about the memory layout of the +"riscv,plic0" device can be found as a comment in the device driver, or as part +of the SiFive U5 Coreplex Series Manual (page 22 of the PDF of version 1.0) +<https://www.sifive.com/documentation/coreplex/u5-coreplex-series-manual/> + +Required properties: +- compatible : "riscv,plic0" +- #address-cells : should be <0> +- #interrupt-cells : should be <1> +- interrupt-controller : Identifies the node as an interrupt controller +- reg : Should contain 1 register range (address and length) +- interrupts-extended : Specifies which contexts are connected to the PLIC, + with "-1" specifying that a context is not present. + +Example: + + plic: interrupt-controller@c000000 { + #address-cells = <0>; + #interrupt-cells = <1>; + compatible = "riscv,plic0"; + interrupt-controller; + interrupts-extended = < + &cpu0-intc 11 + &cpu1-intc 11 &cpu1-intc 9 + &cpu2-intc 11 &cpu2-intc 9 + &cpu3-intc 11 &cpu3-intc 9 + &cpu4-intc 11 &cpu4-intc 9>; + reg = <0xc000000 0x4000000>; + riscv,ndev = <10>; + };