| Message ID | 20211125152233.162868-1-geert@linux-m68k.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | dt-bindings: interrupt-controller: sifive, plic: Fix number of interrupts | expand |
On 25 Nov 2021, at 15:22, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > To improve human readability and enable automatic validation, the tuples > in "interrupts-extended" properties should be grouped using angle > brackets. As the DT bindings lack an upper bound on the number of > interrupts, thus assuming one, proper grouping is currently flagged as > an error. > > Fix this by adding the missing "maxItems", limiting it to 9 interrupts > (one interrupt for a system management core, and two interrupts per core > for other cores), which should be sufficient for now. This is SiFive’s IP, so is this actually true? I would imagine it’s just parameterised and could be generated with as many targets as fit in the MMIO space, and that this is thus inaccurate. Besides, such a function change should be made separately from the grouping change. The same goes for your equivalent sifive,clint0 patch. Jess > Group the tuples in the example. > > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> > --- > .../interrupt-controller/sifive,plic-1.0.0.yaml | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml > index 08d5a57ce00ff446..198b373f984f3438 100644 > --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml > +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml > @@ -61,6 +61,7 @@ properties: > > interrupts-extended: > minItems: 1 > + maxItems: 9 > description: > Specifies which contexts are connected to the PLIC, with "-1" specifying > that a context is not present. Each node pointed to should be a > @@ -89,12 +90,11 @@ examples: > #interrupt-cells = <1>; > compatible = "sifive,fu540-c000-plic", "sifive,plic-1.0.0"; > 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>; > + 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>; > }; > -- > 2.25.1 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
Hi Jessica, On Thu, Nov 25, 2021 at 5:08 PM Jessica Clarke <jrtc27@jrtc27.com> wrote: > On 25 Nov 2021, at 15:22, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > To improve human readability and enable automatic validation, the tuples > > in "interrupts-extended" properties should be grouped using angle > > brackets. As the DT bindings lack an upper bound on the number of > > interrupts, thus assuming one, proper grouping is currently flagged as > > an error. Rob: Is this a bug in the tooling that should be fixed? Regardless, specifying a real upper limit is always a good idea. > > Fix this by adding the missing "maxItems", limiting it to 9 interrupts > > (one interrupt for a system management core, and two interrupts per core > > for other cores), which should be sufficient for now. > > This is SiFive’s IP, so is this actually true? I would imagine it’s > just parameterised and could be generated with as many targets as fit > in the MMIO space, and that this is thus inaccurate. Besides, such a Yes, this is implementation-defined. I just used the maximum value currently in use. drivers/irqchip/irq-sifive-plic.c has #define MAX_CONTEXTS 15872, which matches the value of CONTEXT_PER_HART and the available address space in the driver and in [1]. Would you be more comfortable with "maxItems: 15872"? Or do you prefer setting the maximum based on the compatible value (2 for k210, 9 for fu540, 4 for jh7100[2])? > function change should be made separately from the grouping change. OK, will split in v2. > The same goes for your equivalent sifive,clint0 patch. OK. > > Group the tuples in the example. > > > > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> > > --- > > .../interrupt-controller/sifive,plic-1.0.0.yaml | 12 ++++++------ > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml > > index 08d5a57ce00ff446..198b373f984f3438 100644 > > --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml > > +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml > > @@ -61,6 +61,7 @@ properties: > > > > interrupts-extended: > > minItems: 1 > > + maxItems: 9 > > description: > > Specifies which contexts are connected to the PLIC, with "-1" specifying > > that a context is not present. Each node pointed to should be a [1] https://static.dev.sifive.com/U54-MC-RVCoreIP.pdf [2] The PLIC memory map in https://github.com/starfive-tech/JH7100_Docs/blob/main/vic_u7_manual_with_creativecommons.pdf indicate other values of ENABLE_PER_HART and CONTEXT_PER_HART? Is memory the map correct? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Fri, Nov 26, 2021 at 2:28 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Jessica, > > On Thu, Nov 25, 2021 at 5:08 PM Jessica Clarke <jrtc27@jrtc27.com> wrote: > > On 25 Nov 2021, at 15:22, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > To improve human readability and enable automatic validation, the tuples > > > in "interrupts-extended" properties should be grouped using angle > > > brackets. As the DT bindings lack an upper bound on the number of > > > interrupts, thus assuming one, proper grouping is currently flagged as > > > an error. > > Rob: Is this a bug in the tooling that should be fixed? > Regardless, specifying a real upper limit is always a good idea. > > > > Fix this by adding the missing "maxItems", limiting it to 9 interrupts > > > (one interrupt for a system management core, and two interrupts per core > > > for other cores), which should be sufficient for now. > > > > This is SiFive’s IP, so is this actually true? I would imagine it’s > > just parameterised and could be generated with as many targets as fit > > in the MMIO space, and that this is thus inaccurate. Besides, such a > > Yes, this is implementation-defined. I just used the maximum value > currently in use. > > drivers/irqchip/irq-sifive-plic.c has #define MAX_CONTEXTS 15872, > which matches the value of CONTEXT_PER_HART and the available address > space in the driver and in [1]. > Would you be more comfortable with "maxItems: 15872"? > Or do you prefer setting the maximum based on the compatible value > (2 for k210, 9 for fu540, 4 for jh7100[2])? Yes, 15872 is an appropriate value for "maxItems". Regards, Anup > > > function change should be made separately from the grouping change. > > OK, will split in v2. > > > The same goes for your equivalent sifive,clint0 patch. > > OK. > > > > Group the tuples in the example. > > > > > > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> > > > --- > > > .../interrupt-controller/sifive,plic-1.0.0.yaml | 12 ++++++------ > > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml > > > index 08d5a57ce00ff446..198b373f984f3438 100644 > > > --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml > > > +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml > > > @@ -61,6 +61,7 @@ properties: > > > > > > interrupts-extended: > > > minItems: 1 > > > + maxItems: 9 > > > description: > > > Specifies which contexts are connected to the PLIC, with "-1" specifying > > > that a context is not present. Each node pointed to should be a > > [1] https://static.dev.sifive.com/U54-MC-RVCoreIP.pdf > [2] The PLIC memory map in > https://github.com/starfive-tech/JH7100_Docs/blob/main/vic_u7_manual_with_creativecommons.pdf > indicate other values of ENABLE_PER_HART and CONTEXT_PER_HART? > Is memory the map correct? > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Fri, Nov 26, 2021 at 2:58 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Jessica, > > On Thu, Nov 25, 2021 at 5:08 PM Jessica Clarke <jrtc27@jrtc27.com> wrote: > > On 25 Nov 2021, at 15:22, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > To improve human readability and enable automatic validation, the tuples > > > in "interrupts-extended" properties should be grouped using angle > > > brackets. As the DT bindings lack an upper bound on the number of > > > interrupts, thus assuming one, proper grouping is currently flagged as > > > an error. > > Rob: Is this a bug in the tooling that should be fixed? The grouping or upper bound? The tools default to minItems == maxItems, so you be getting 'maxItems: 1' here. For grouping, I plan to make this not matter for validation. I'm working on making the validation operate on dtbs and we lose any source grouping with that. I'll probably switch the kernel to use dtbs as well because I don't want to maintain both. Still, I think the grouping is good from a source consistency POV. > Regardless, specifying a real upper limit is always a good idea. Yes. A 'should be enough for now' limit is better than none IMO, too. > > > > Fix this by adding the missing "maxItems", limiting it to 9 interrupts > > > (one interrupt for a system management core, and two interrupts per core > > > for other cores), which should be sufficient for now. > > > > This is SiFive’s IP, so is this actually true? I would imagine it’s > > just parameterised and could be generated with as many targets as fit > > in the MMIO space, and that this is thus inaccurate. Besides, such a > > Yes, this is implementation-defined. I just used the maximum value > currently in use. > > drivers/irqchip/irq-sifive-plic.c has #define MAX_CONTEXTS 15872, > which matches the value of CONTEXT_PER_HART and the available address > space in the driver and in [1]. > Would you be more comfortable with "maxItems: 15872"? Always good to have a real value rather than an unknown implementation limit. Rob
diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml index 08d5a57ce00ff446..198b373f984f3438 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml @@ -61,6 +61,7 @@ properties: interrupts-extended: minItems: 1 + maxItems: 9 description: Specifies which contexts are connected to the PLIC, with "-1" specifying that a context is not present. Each node pointed to should be a @@ -89,12 +90,11 @@ examples: #interrupt-cells = <1>; compatible = "sifive,fu540-c000-plic", "sifive,plic-1.0.0"; 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>; + 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>; };
To improve human readability and enable automatic validation, the tuples in "interrupts-extended" properties should be grouped using angle brackets. As the DT bindings lack an upper bound on the number of interrupts, thus assuming one, proper grouping is currently flagged as an error. Fix this by adding the missing "maxItems", limiting it to 9 interrupts (one interrupt for a system management core, and two interrupts per core for other cores), which should be sufficient for now. Group the tuples in the example. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- .../interrupt-controller/sifive,plic-1.0.0.yaml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)