[PATCH v1 0/3] irqchip/sifive-plic: Fix T-HEAD PLIC edge trigger handling

[PATCH v1 0/3] irqchip/sifive-plic: Fix T-HEAD PLIC edge trigger handling

[Samuel Holland]

This is a follow-up to the series "[PATCH v2 0/2] Add PLIC support for
Renesas RZ/Five SoC"[1].

The change made there is also needed for the already-supported T-HEAD
C9xx PLIC. So this binding change is necessary before I can send the
Allwinner D1 devicetree.

[1]: https://lore.kernel.org/linux-riscv/20220626004326.8548-1-prabhakar.mahadev-lad.rj@bp.renesas.com/T/

Changes in v1:
 - Use a flag for enabling the changes instead of a variant ID
 - Use handle_edge_irq instead of handle_fasteoi_ack_irq
 - Do not set the handler name, as RISC-V selects GENERIC_IRQ_SHOW_LEVEL

Samuel Holland (3):
  dt-bindings: interrupt-controller: Require trigger type for T-HEAD
    PLIC
  irqchip/sifive-plic: Name the chip more generically
  irqchip/sifive-plic: Fix T-HEAD PLIC edge trigger handling

 .../sifive,plic-1.0.0.yaml                    | 31 ++++++-
 drivers/irqchip/irq-sifive-plic.c             | 91 +++++++++++++++++--
 2 files changed, 108 insertions(+), 14 deletions(-)

-- 
2.35.1

[PATCH v1 1/3] dt-bindings: interrupt-controller: Require trigger type for T-HEAD PLIC

[Samuel Holland]

The RISC-V PLIC specification unfortunately allows PLIC implementations
to ignore edges seen while an edge-triggered interrupt is being handled:

  Depending on the design of the device and the interrupt handler,
  in between sending an interrupt request and receiving notice of its
  handler’s completion, the gateway might either ignore additional
  matching edges or increment a counter of pending interrupts.

For PLICs with that misfeature, software needs to know the trigger type
of each interrupt. This allows it to work around the issue by completing
edge-triggered interrupts before handling them. Such a workaround is
required to avoid missing any edges.

The T-HEAD C9xx PLIC is an example of a PLIC with this behavior.

Signed-off-by: Samuel Holland <samuel@sholland.org>
---

 .../sifive,plic-1.0.0.yaml                    | 31 ++++++++++++++++---
 1 file changed, 27 insertions(+), 4 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 27092c6a86c4..3c589cbca851 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
@@ -26,9 +26,13 @@ description:
   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 therefore it is not
-  specified in the PLIC device-tree binding.
+  The PLIC supports both edge-triggered and level-triggered interrupts. For
+  edge-triggered interrupts, the RISC-V PLIC spec allows two responses to edges
+  seen while an interrupt handler is active; the PLIC may either queue them or
+  ignore them. In the first case, handlers are oblivious to the trigger type, so
+  it is not included in the interrupt specifier. In the second case, software
+  needs to know the trigger type, so it can reorder the interrupt flow to avoid
+  missing interrupts.
 
   While the RISC-V ISA doesn't specify a memory layout for the PLIC, the
   "sifive,plic-1.0.0" device is a concrete implementation of the PLIC that
@@ -65,7 +69,8 @@ properties:
     const: 0
 
   '#interrupt-cells':
-    const: 1
+    minimum: 1
+    maximum: 2
 
   interrupt-controller: true
 
@@ -91,6 +96,24 @@ required:
   - interrupts-extended
   - riscv,ndev
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - thead,c900-plic
+
+    then:
+      properties:
+        '#interrupt-cells':
+          const: 2
+
+    else:
+      properties:
+        '#interrupt-cells':
+          const: 1
+
 additionalProperties: false
 
 examples:
-- 
2.35.1

Re: [PATCH v1 1/3] dt-bindings: interrupt-controller: Require trigger type for T-HEAD PLIC

[Guo Ren]

On Mon, Jun 27, 2022 at 1:13 PM Samuel Holland <samuel@sholland.org> wrote:
>
> The RISC-V PLIC specification unfortunately allows PLIC implementations
> to ignore edges seen while an edge-triggered interrupt is being handled:
>
>   Depending on the design of the device and the interrupt handler,
>   in between sending an interrupt request and receiving notice of its
>   handler’s completion, the gateway might either ignore additional
>   matching edges or increment a counter of pending interrupts.
>
> For PLICs with that misfeature, software needs to know the trigger type
> of each interrupt. This allows it to work around the issue by completing
> edge-triggered interrupts before handling them. Such a workaround is
> required to avoid missing any edges.
>
> The T-HEAD C9xx PLIC is an example of a PLIC with this behavior.
Actually, C9xx support pulse signals which configed by
pad_plic_int_cfg_x for SoC vendor:

https://github.com/T-head-Semi/openc906/blob/main/C906_RTL_FACTORY/gen_rtl/plic/rtl/plic_int_kid.v
104: assign int_new_pending = pad_plic_int_cfg_x ? int_pulse
105:
        : level_int_pending;

They could put pad_plic_int_cfg_x into the SoC software config
registers region or bind them to constant values.

>
> Signed-off-by: Samuel Holland <samuel@sholland.org>
> ---
>
>  .../sifive,plic-1.0.0.yaml                    | 31 ++++++++++++++++---
>  1 file changed, 27 insertions(+), 4 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 27092c6a86c4..3c589cbca851 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
> @@ -26,9 +26,13 @@ description:
>    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 therefore it is not
> -  specified in the PLIC device-tree binding.
> +  The PLIC supports both edge-triggered and level-triggered interrupts. For
> +  edge-triggered interrupts, the RISC-V PLIC spec allows two responses to edges
> +  seen while an interrupt handler is active; the PLIC may either queue them or
> +  ignore them. In the first case, handlers are oblivious to the trigger type, so
> +  it is not included in the interrupt specifier. In the second case, software
> +  needs to know the trigger type, so it can reorder the interrupt flow to avoid
> +  missing interrupts.
>
>    While the RISC-V ISA doesn't specify a memory layout for the PLIC, the
>    "sifive,plic-1.0.0" device is a concrete implementation of the PLIC that
> @@ -65,7 +69,8 @@ properties:
>      const: 0
>
>    '#interrupt-cells':
> -    const: 1
> +    minimum: 1
> +    maximum: 2
>
>    interrupt-controller: true
>
> @@ -91,6 +96,24 @@ required:
>    - interrupts-extended
>    - riscv,ndev
>
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - thead,c900-plic
> +
> +    then:
> +      properties:
> +        '#interrupt-cells':
> +          const: 2
> +
> +    else:
> +      properties:
> +        '#interrupt-cells':
> +          const: 1
> +
>  additionalProperties: false
>
>  examples:
> --
> 2.35.1
>


-- 
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/

Re: [PATCH v1 1/3] dt-bindings: interrupt-controller: Require trigger type for T-HEAD PLIC

[Samuel Holland]

On 6/27/22 2:40 AM, Guo Ren wrote:
> On Mon, Jun 27, 2022 at 1:13 PM Samuel Holland <samuel@sholland.org> wrote:
>>
>> The RISC-V PLIC specification unfortunately allows PLIC implementations
>> to ignore edges seen while an edge-triggered interrupt is being handled:
>>
>>   Depending on the design of the device and the interrupt handler,
>>   in between sending an interrupt request and receiving notice of its
>>   handler’s completion, the gateway might either ignore additional
>>   matching edges or increment a counter of pending interrupts.
>>
>> For PLICs with that misfeature, software needs to know the trigger type
>> of each interrupt. This allows it to work around the issue by completing
>> edge-triggered interrupts before handling them. Such a workaround is
>> required to avoid missing any edges.
>>
>> The T-HEAD C9xx PLIC is an example of a PLIC with this behavior.
> Actually, C9xx support pulse signals which configed by
> pad_plic_int_cfg_x for SoC vendor:
> 
> https://github.com/T-head-Semi/openc906/blob/main/C906_RTL_FACTORY/gen_rtl/plic/rtl/plic_int_kid.v
> 104: assign int_new_pending = pad_plic_int_cfg_x ? int_pulse
> 105:
>         : level_int_pending;
> 
> They could put pad_plic_int_cfg_x into the SoC software config
> registers region or bind them to constant values.

The issue here is the "!int_active" condition for int_new_set_pending,
regardless of that configuration input.

For interrupt sources that send pulses, those pulses will be lost if they are
received while int_active is true. So the driver has to make sure int_active is
false _before_ servicing an interrupt, or it may miss the next one. This means
the driver needs to know which interrupt _sources_ send pulses and which ones
assert levels.

For level interrupts, pad_plic_int_cfg_x had better be 0, but that is a
hardware/firmware configuration concern. The driver should not have to care
about that.

(On the Allwinner D1, those inputs are memory mapped, which was the reason for
the stacked interrupt controller mentioned in my other reply. But while
pad_plic_int_cfg_x == 1 only works with edge interrupts, the pad_plic_int_cfg_x
== 0 choice works with either kind of interrupt source, so the stacked driver is
not really needed.)

Regards,
Samuel

Re: [PATCH v1 1/3] dt-bindings: interrupt-controller: Require trigger type for T-HEAD PLIC

[Guo Ren]

On Mon, Jun 27, 2022 at 10:14 PM Samuel Holland <samuel@sholland.org> wrote:
>
> On 6/27/22 2:40 AM, Guo Ren wrote:
> > On Mon, Jun 27, 2022 at 1:13 PM Samuel Holland <samuel@sholland.org> wrote:
> >>
> >> The RISC-V PLIC specification unfortunately allows PLIC implementations
> >> to ignore edges seen while an edge-triggered interrupt is being handled:
> >>
> >>   Depending on the design of the device and the interrupt handler,
> >>   in between sending an interrupt request and receiving notice of its
> >>   handler’s completion, the gateway might either ignore additional
> >>   matching edges or increment a counter of pending interrupts.
> >>
> >> For PLICs with that misfeature, software needs to know the trigger type
> >> of each interrupt. This allows it to work around the issue by completing
> >> edge-triggered interrupts before handling them. Such a workaround is
> >> required to avoid missing any edges.
> >>
> >> The T-HEAD C9xx PLIC is an example of a PLIC with this behavior.
> > Actually, C9xx support pulse signals which configed by
> > pad_plic_int_cfg_x for SoC vendor:
> >
> > https://github.com/T-head-Semi/openc906/blob/main/C906_RTL_FACTORY/gen_rtl/plic/rtl/plic_int_kid.v
> > 104: assign int_new_pending = pad_plic_int_cfg_x ? int_pulse
> > 105:
> >         : level_int_pending;
> >
> > They could put pad_plic_int_cfg_x into the SoC software config
> > registers region or bind them to constant values.
>
> The issue here is the "!int_active" condition for int_new_set_pending,
> regardless of that configuration input.
>
> For interrupt sources that send pulses, those pulses will be lost if they are
> received while int_active is true. So the driver has to make sure int_active is
> false _before_ servicing an interrupt, or it may miss the next one. This means
> the driver needs to know which interrupt _sources_ send pulses and which ones
> assert levels.
You are right, in plus mode, we can't receive any interrupt between
claim & complete, then the irq could be lost.

I think the design follows the sentence written by PLIC spec:
https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc

If the global interrupt source was edge-triggered, the gateway will
convert the first matching signal edge into an interrupt request.
Depending on the design of the device and the interrupt handler, in
between sending an interrupt request and receiving notice of its
handler’s completion, the gateway might either **ignore additional
matching edges** or increment a counter of pending interrupts.

Also, the hardware could easily support the feature, but the engineer
follows the first choice and disable the useful function. -_*!

>
> For level interrupts, pad_plic_int_cfg_x had better be 0, but that is a
> hardware/firmware configuration concern. The driver should not have to care
> about that.
>
> (On the Allwinner D1, those inputs are memory mapped, which was the reason for
> the stacked interrupt controller mentioned in my other reply. But while
> pad_plic_int_cfg_x == 1 only works with edge interrupts, the pad_plic_int_cfg_x
> == 0 choice works with either kind of interrupt source, so the stacked driver is
> not really needed.)
>
> Regards,
> Samuel
--
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/

Re: [PATCH v1 1/3] dt-bindings: interrupt-controller: Require trigger type for T-HEAD PLIC

[Guo Ren]

Reviewed-by: Guo Ren <guoren@kernel.org>

On Mon, Jun 27, 2022 at 1:13 PM Samuel Holland <samuel@sholland.org> wrote:
>
> The RISC-V PLIC specification unfortunately allows PLIC implementations
> to ignore edges seen while an edge-triggered interrupt is being handled:
>
>   Depending on the design of the device and the interrupt handler,
>   in between sending an interrupt request and receiving notice of its
>   handler’s completion, the gateway might either ignore additional
>   matching edges or increment a counter of pending interrupts.
>
> For PLICs with that misfeature, software needs to know the trigger type
> of each interrupt. This allows it to work around the issue by completing
> edge-triggered interrupts before handling them. Such a workaround is
> required to avoid missing any edges.
>
> The T-HEAD C9xx PLIC is an example of a PLIC with this behavior.
>
> Signed-off-by: Samuel Holland <samuel@sholland.org>
> ---
>
>  .../sifive,plic-1.0.0.yaml                    | 31 ++++++++++++++++---
>  1 file changed, 27 insertions(+), 4 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 27092c6a86c4..3c589cbca851 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
> @@ -26,9 +26,13 @@ description:
>    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 therefore it is not
> -  specified in the PLIC device-tree binding.
> +  The PLIC supports both edge-triggered and level-triggered interrupts. For
> +  edge-triggered interrupts, the RISC-V PLIC spec allows two responses to edges
> +  seen while an interrupt handler is active; the PLIC may either queue them or
> +  ignore them. In the first case, handlers are oblivious to the trigger type, so
> +  it is not included in the interrupt specifier. In the second case, software
> +  needs to know the trigger type, so it can reorder the interrupt flow to avoid
> +  missing interrupts.
>
>    While the RISC-V ISA doesn't specify a memory layout for the PLIC, the
>    "sifive,plic-1.0.0" device is a concrete implementation of the PLIC that
> @@ -65,7 +69,8 @@ properties:
>      const: 0
>
>    '#interrupt-cells':
> -    const: 1
> +    minimum: 1
> +    maximum: 2
>
>    interrupt-controller: true
>
> @@ -91,6 +96,24 @@ required:
>    - interrupts-extended
>    - riscv,ndev
>
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - thead,c900-plic
> +
> +    then:
> +      properties:
> +        '#interrupt-cells':
> +          const: 2
> +
> +    else:
> +      properties:
> +        '#interrupt-cells':
> +          const: 1
> +
>  additionalProperties: false
>
>  examples:
> --
> 2.35.1
>


-- 
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/

[PATCH v1 2/3] irqchip/sifive-plic: Name the chip more generically

[Samuel Holland]

The interface for SiFive's PLIC was adopted and clarified by RISC-V as
the standard PLIC interface. Now that several PLIC implementations by
different vendors share this same interface, it is somewhat misleading
to report "SiFive PLIC" to userspace, when no SiFive hardware may be
present. This is especially the case when some implementations are
subtly incompatible with the binding and behavior of the SiFive PLIC,
yet are similar enough to share a driver.

Signed-off-by: Samuel Holland <samuel@sholland.org>
---

 drivers/irqchip/irq-sifive-plic.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
index bb87e4c3b88e..90515865af08 100644
--- a/drivers/irqchip/irq-sifive-plic.c
+++ b/drivers/irqchip/irq-sifive-plic.c
@@ -28,6 +28,11 @@
  * The largest number supported by devices marked as 'sifive,plic-1.0.0', is
  * 1024, of which device 0 is defined as non-existent by the RISC-V Privileged
  * Spec.
+ *
+ * The PLIC behavior and memory map is futher formalized as an official RISC-V
+ * specification:
+ *
+ *     https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc
  */
 
 #define MAX_DEVICES			1024
@@ -177,12 +182,12 @@ static void plic_irq_eoi(struct irq_data *d)
 }
 
 static struct irq_chip plic_chip = {
-	.name		= "SiFive PLIC",
-	.irq_mask	= plic_irq_mask,
-	.irq_unmask	= plic_irq_unmask,
-	.irq_eoi	= plic_irq_eoi,
+	.name			= "PLIC",
+	.irq_mask		= plic_irq_mask,
+	.irq_unmask		= plic_irq_unmask,
+	.irq_eoi		= plic_irq_eoi,
 #ifdef CONFIG_SMP
-	.irq_set_affinity = plic_set_affinity,
+	.irq_set_affinity	= plic_set_affinity,
 #endif
 };
 
-- 
2.35.1

Re: [PATCH v1 2/3] irqchip/sifive-plic: Name the chip more generically

[Guo Ren]

Reviewed-by: Guo Ren <guoren@kernel.org>

On Mon, Jun 27, 2022 at 1:13 PM Samuel Holland <samuel@sholland.org> wrote:
>
> The interface for SiFive's PLIC was adopted and clarified by RISC-V as
> the standard PLIC interface. Now that several PLIC implementations by
> different vendors share this same interface, it is somewhat misleading
> to report "SiFive PLIC" to userspace, when no SiFive hardware may be
> present. This is especially the case when some implementations are
> subtly incompatible with the binding and behavior of the SiFive PLIC,
> yet are similar enough to share a driver.
>
> Signed-off-by: Samuel Holland <samuel@sholland.org>
> ---
>
>  drivers/irqchip/irq-sifive-plic.c | 15 ++++++++++-----
>  1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
> index bb87e4c3b88e..90515865af08 100644
> --- a/drivers/irqchip/irq-sifive-plic.c
> +++ b/drivers/irqchip/irq-sifive-plic.c
> @@ -28,6 +28,11 @@
>   * The largest number supported by devices marked as 'sifive,plic-1.0.0', is
>   * 1024, of which device 0 is defined as non-existent by the RISC-V Privileged
>   * Spec.
> + *
> + * The PLIC behavior and memory map is futher formalized as an official RISC-V
> + * specification:
> + *
> + *     https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc
>   */
>
>  #define MAX_DEVICES                    1024
> @@ -177,12 +182,12 @@ static void plic_irq_eoi(struct irq_data *d)
>  }
>
>  static struct irq_chip plic_chip = {
> -       .name           = "SiFive PLIC",
> -       .irq_mask       = plic_irq_mask,
> -       .irq_unmask     = plic_irq_unmask,
> -       .irq_eoi        = plic_irq_eoi,
> +       .name                   = "PLIC",
> +       .irq_mask               = plic_irq_mask,
> +       .irq_unmask             = plic_irq_unmask,
> +       .irq_eoi                = plic_irq_eoi,
>  #ifdef CONFIG_SMP
> -       .irq_set_affinity = plic_set_affinity,
> +       .irq_set_affinity       = plic_set_affinity,
>  #endif
>  };
>
> --
> 2.35.1
>


-- 
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/

Re: [PATCH v1 2/3] irqchip/sifive-plic: Name the chip more generically

[Marc Zyngier]

On 2022-06-27 06:12, Samuel Holland wrote:
> The interface for SiFive's PLIC was adopted and clarified by RISC-V as
> the standard PLIC interface. Now that several PLIC implementations by
> different vendors share this same interface, it is somewhat misleading
> to report "SiFive PLIC" to userspace, when no SiFive hardware may be
> present. This is especially the case when some implementations are
> subtly incompatible with the binding and behavior of the SiFive PLIC,
> yet are similar enough to share a driver.

Too late. This is ABI, and not changing, exactly because userspace
sees it.

         M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v1 2/3] irqchip/sifive-plic: Name the chip more generically

[Samuel Holland]

On 6/27/22 2:11 AM, Marc Zyngier wrote:
> On 2022-06-27 06:12, Samuel Holland wrote:
>> The interface for SiFive's PLIC was adopted and clarified by RISC-V as
>> the standard PLIC interface. Now that several PLIC implementations by
>> different vendors share this same interface, it is somewhat misleading
>> to report "SiFive PLIC" to userspace, when no SiFive hardware may be
>> present. This is especially the case when some implementations are
>> subtly incompatible with the binding and behavior of the SiFive PLIC,
>> yet are similar enough to share a driver.
> 
> Too late. This is ABI, and not changing, exactly because userspace
> sees it.

That makes sense. I will drop this patch.

Regards,
Samuel

[PATCH v1 3/3] irqchip/sifive-plic: Fix T-HEAD PLIC edge trigger handling

[Samuel Holland]

The T-HEAD PLIC ignores additional edges seen while an edge-triggered
interrupt is being handled. Because of this behavior, the driver needs
to complete edge-triggered interrupts in the .irq_ack callback before
handling them, instead of in the .irq_eoi callback afterward. Otherwise,
it could miss some interrupts.

Co-developed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Samuel Holland <samuel@sholland.org>
---

Changes in v1:
 - Use a flag for enabling the changes instead of a variant ID
 - Use handle_edge_irq instead of handle_fasteoi_ack_irq
 - Do not set the handler name, as RISC-V selects GENERIC_IRQ_SHOW_LEVEL

 drivers/irqchip/irq-sifive-plic.c | 76 +++++++++++++++++++++++++++++--
 1 file changed, 71 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
index 90515865af08..462a93b4b088 100644
--- a/drivers/irqchip/irq-sifive-plic.c
+++ b/drivers/irqchip/irq-sifive-plic.c
@@ -69,6 +69,7 @@ struct plic_priv {
 	struct cpumask lmask;
 	struct irq_domain *irqdomain;
 	void __iomem *regs;
+	bool needs_edge_handling;
 };
 
 struct plic_handler {
@@ -86,6 +87,9 @@ static int plic_parent_irq __ro_after_init;
 static bool plic_cpuhp_setup_done __ro_after_init;
 static DEFINE_PER_CPU(struct plic_handler, plic_handlers);
 
+static struct irq_chip plic_edge_chip;
+static struct irq_chip plic_chip;
+
 static void __plic_toggle(void __iomem *enable_base, int hwirq, int enable)
 {
 	u32 __iomem *reg = enable_base + (hwirq / 32) * sizeof(u32);
@@ -181,6 +185,40 @@ static void plic_irq_eoi(struct irq_data *d)
 	}
 }
 
+static int plic_irq_set_type(struct irq_data *d, unsigned int flow_type)
+{
+	struct plic_priv *priv = irq_data_get_irq_chip_data(d);
+
+	if (!priv->needs_edge_handling)
+		return IRQ_SET_MASK_OK_NOCOPY;
+
+	switch (flow_type) {
+	case IRQ_TYPE_EDGE_RISING:
+		irq_set_chip_handler_name_locked(d, &plic_edge_chip,
+						 handle_edge_irq, NULL);
+		break;
+	case IRQ_TYPE_LEVEL_HIGH:
+		irq_set_chip_handler_name_locked(d, &plic_chip,
+						 handle_fasteoi_irq, NULL);
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return IRQ_SET_MASK_OK;
+}
+
+static struct irq_chip plic_edge_chip = {
+	.name			= "PLIC",
+	.irq_ack		= plic_irq_eoi,
+	.irq_mask		= plic_irq_mask,
+	.irq_unmask		= plic_irq_unmask,
+#ifdef CONFIG_SMP
+	.irq_set_affinity	= plic_set_affinity,
+#endif
+	.irq_set_type		= plic_irq_set_type,
+};
+
 static struct irq_chip plic_chip = {
 	.name			= "PLIC",
 	.irq_mask		= plic_irq_mask,
@@ -189,8 +227,22 @@ static struct irq_chip plic_chip = {
 #ifdef CONFIG_SMP
 	.irq_set_affinity	= plic_set_affinity,
 #endif
+	.irq_set_type		= plic_irq_set_type,
 };
 
+static int plic_irq_domain_translate(struct irq_domain *d,
+				     struct irq_fwspec *fwspec,
+				     unsigned long *hwirq,
+				     unsigned int *type)
+{
+	struct plic_priv *priv = d->host_data;
+
+	if (priv->needs_edge_handling)
+		return irq_domain_translate_twocell(d, fwspec, hwirq, type);
+	else
+		return irq_domain_translate_onecell(d, fwspec, hwirq, type);
+}
+
 static int plic_irqdomain_map(struct irq_domain *d, unsigned int irq,
 			      irq_hw_number_t hwirq)
 {
@@ -211,7 +263,7 @@ static int plic_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
 	unsigned int type;
 	struct irq_fwspec *fwspec = arg;
 
-	ret = irq_domain_translate_onecell(domain, fwspec, &hwirq, &type);
+	ret = plic_irq_domain_translate(domain, fwspec, &hwirq, &type);
 	if (ret)
 		return ret;
 
@@ -225,7 +277,7 @@ static int plic_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
 }
 
 static const struct irq_domain_ops plic_irqdomain_ops = {
-	.translate	= irq_domain_translate_onecell,
+	.translate	= plic_irq_domain_translate,
 	.alloc		= plic_irq_domain_alloc,
 	.free		= irq_domain_free_irqs_top,
 };
@@ -286,8 +338,9 @@ static int plic_starting_cpu(unsigned int cpu)
 	return 0;
 }
 
-static int __init plic_init(struct device_node *node,
-		struct device_node *parent)
+static int __init __plic_init(struct device_node *node,
+			      struct device_node *parent,
+			      bool needs_edge_handling)
 {
 	int error = 0, nr_contexts, nr_handlers = 0, i;
 	u32 nr_irqs;
@@ -298,6 +351,8 @@ static int __init plic_init(struct device_node *node,
 	if (!priv)
 		return -ENOMEM;
 
+	priv->needs_edge_handling = needs_edge_handling;
+
 	priv->regs = of_iomap(node, 0);
 	if (WARN_ON(!priv->regs)) {
 		error = -EIO;
@@ -415,6 +470,17 @@ static int __init plic_init(struct device_node *node,
 	return error;
 }
 
+static int __init plic_init(struct device_node *node,
+			    struct device_node *parent)
+{
+	return __plic_init(node, parent, false);
+}
 IRQCHIP_DECLARE(sifive_plic, "sifive,plic-1.0.0", plic_init);
 IRQCHIP_DECLARE(riscv_plic0, "riscv,plic0", plic_init); /* for legacy systems */
-IRQCHIP_DECLARE(thead_c900_plic, "thead,c900-plic", plic_init); /* for firmware driver */
+
+static int __init plic_edge_init(struct device_node *node,
+				     struct device_node *parent)
+{
+	return __plic_init(node, parent, true);
+}
+IRQCHIP_DECLARE(thead_c900_plic, "thead,c900-plic", plic_edge_init);
-- 
2.35.1

Re: [PATCH v1 3/3] irqchip/sifive-plic: Fix T-HEAD PLIC edge trigger handling

[Marc Zyngier]

On Mon, 27 Jun 2022 06:12:57 +0100,
Samuel Holland <samuel@sholland.org> wrote:
> 
> The T-HEAD PLIC ignores additional edges seen while an edge-triggered
> interrupt is being handled. Because of this behavior, the driver needs
> to complete edge-triggered interrupts in the .irq_ack callback before
> handling them, instead of in the .irq_eoi callback afterward. Otherwise,
> it could miss some interrupts.
> 
> Co-developed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Signed-off-by: Samuel Holland <samuel@sholland.org>
> ---
> 
> Changes in v1:
>  - Use a flag for enabling the changes instead of a variant ID
>  - Use handle_edge_irq instead of handle_fasteoi_ack_irq
>  - Do not set the handler name, as RISC-V selects GENERIC_IRQ_SHOW_LEVEL

Where is the Renesas handling gone? Can you, at the very least work,
with Lad instead of proposing an alternative series that ignores the
goal of the first one, however good it is (and it is admittedly
better)?

>
>  drivers/irqchip/irq-sifive-plic.c | 76 +++++++++++++++++++++++++++++--
>  1 file changed, 71 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
> index 90515865af08..462a93b4b088 100644
> --- a/drivers/irqchip/irq-sifive-plic.c
> +++ b/drivers/irqchip/irq-sifive-plic.c
> @@ -69,6 +69,7 @@ struct plic_priv {
>  	struct cpumask lmask;
>  	struct irq_domain *irqdomain;
>  	void __iomem *regs;
> +	bool needs_edge_handling;
>  };
>  
>  struct plic_handler {
> @@ -86,6 +87,9 @@ static int plic_parent_irq __ro_after_init;
>  static bool plic_cpuhp_setup_done __ro_after_init;
>  static DEFINE_PER_CPU(struct plic_handler, plic_handlers);
>  
> +static struct irq_chip plic_edge_chip;
> +static struct irq_chip plic_chip;
> +
>  static void __plic_toggle(void __iomem *enable_base, int hwirq, int enable)
>  {
>  	u32 __iomem *reg = enable_base + (hwirq / 32) * sizeof(u32);
> @@ -181,6 +185,40 @@ static void plic_irq_eoi(struct irq_data *d)
>  	}
>  }
>  
> +static int plic_irq_set_type(struct irq_data *d, unsigned int flow_type)
> +{
> +	struct plic_priv *priv = irq_data_get_irq_chip_data(d);
> +
> +	if (!priv->needs_edge_handling)
> +		return IRQ_SET_MASK_OK_NOCOPY;
> +
> +	switch (flow_type) {
> +	case IRQ_TYPE_EDGE_RISING:
> +		irq_set_chip_handler_name_locked(d, &plic_edge_chip,
> +						 handle_edge_irq, NULL);
> +		break;
> +	case IRQ_TYPE_LEVEL_HIGH:
> +		irq_set_chip_handler_name_locked(d, &plic_chip,
> +						 handle_fasteoi_irq, NULL);
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	return IRQ_SET_MASK_OK;
> +}
> +
> +static struct irq_chip plic_edge_chip = {
> +	.name			= "PLIC",
> +	.irq_ack		= plic_irq_eoi,
> +	.irq_mask		= plic_irq_mask,
> +	.irq_unmask		= plic_irq_unmask,
> +#ifdef CONFIG_SMP
> +	.irq_set_affinity	= plic_set_affinity,
> +#endif
> +	.irq_set_type		= plic_irq_set_type,
> +};
> +
>  static struct irq_chip plic_chip = {
>  	.name			= "PLIC",
>  	.irq_mask		= plic_irq_mask,
> @@ -189,8 +227,22 @@ static struct irq_chip plic_chip = {
>  #ifdef CONFIG_SMP
>  	.irq_set_affinity	= plic_set_affinity,
>  #endif
> +	.irq_set_type		= plic_irq_set_type,
>  };
>  
> +static int plic_irq_domain_translate(struct irq_domain *d,
> +				     struct irq_fwspec *fwspec,
> +				     unsigned long *hwirq,
> +				     unsigned int *type)
> +{
> +	struct plic_priv *priv = d->host_data;
> +
> +	if (priv->needs_edge_handling)
> +		return irq_domain_translate_twocell(d, fwspec, hwirq, type);
> +	else
> +		return irq_domain_translate_onecell(d, fwspec, hwirq, type);
> +}
> +
>  static int plic_irqdomain_map(struct irq_domain *d, unsigned int irq,
>  			      irq_hw_number_t hwirq)
>  {
> @@ -211,7 +263,7 @@ static int plic_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
>  	unsigned int type;
>  	struct irq_fwspec *fwspec = arg;
>  
> -	ret = irq_domain_translate_onecell(domain, fwspec, &hwirq, &type);
> +	ret = plic_irq_domain_translate(domain, fwspec, &hwirq, &type);
>  	if (ret)
>  		return ret;
>  
> @@ -225,7 +277,7 @@ static int plic_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
>  }
>  
>  static const struct irq_domain_ops plic_irqdomain_ops = {
> -	.translate	= irq_domain_translate_onecell,
> +	.translate	= plic_irq_domain_translate,
>  	.alloc		= plic_irq_domain_alloc,
>  	.free		= irq_domain_free_irqs_top,
>  };
> @@ -286,8 +338,9 @@ static int plic_starting_cpu(unsigned int cpu)
>  	return 0;
>  }
>  
> -static int __init plic_init(struct device_node *node,
> -		struct device_node *parent)
> +static int __init __plic_init(struct device_node *node,
> +			      struct device_node *parent,
> +			      bool needs_edge_handling)
>  {
>  	int error = 0, nr_contexts, nr_handlers = 0, i;
>  	u32 nr_irqs;
> @@ -298,6 +351,8 @@ static int __init plic_init(struct device_node *node,
>  	if (!priv)
>  		return -ENOMEM;
>  
> +	priv->needs_edge_handling = needs_edge_handling;
> +
>  	priv->regs = of_iomap(node, 0);
>  	if (WARN_ON(!priv->regs)) {
>  		error = -EIO;
> @@ -415,6 +470,17 @@ static int __init plic_init(struct device_node *node,
>  	return error;
>  }
>  
> +static int __init plic_init(struct device_node *node,
> +			    struct device_node *parent)
> +{
> +	return __plic_init(node, parent, false);
> +}
>  IRQCHIP_DECLARE(sifive_plic, "sifive,plic-1.0.0", plic_init);
>  IRQCHIP_DECLARE(riscv_plic0, "riscv,plic0", plic_init); /* for legacy systems */
> -IRQCHIP_DECLARE(thead_c900_plic, "thead,c900-plic", plic_init); /* for firmware driver */
> +
> +static int __init plic_edge_init(struct device_node *node,
> +				     struct device_node *parent)
> +{
> +	return __plic_init(node, parent, true);
> +}
> +IRQCHIP_DECLARE(thead_c900_plic, "thead,c900-plic", plic_edge_init);

No. You are breaking existing platforms with established DTs. You must
at least be able to run a new kernel with an old DT. Ideally the
opposite too, but it is hard to retrofit this.

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH v1 3/3] irqchip/sifive-plic: Fix T-HEAD PLIC edge trigger handling

[Samuel Holland]

On 6/27/22 2:27 AM, Marc Zyngier wrote:
> On Mon, 27 Jun 2022 06:12:57 +0100,
> Samuel Holland <samuel@sholland.org> wrote:
>>
>> The T-HEAD PLIC ignores additional edges seen while an edge-triggered
>> interrupt is being handled. Because of this behavior, the driver needs
>> to complete edge-triggered interrupts in the .irq_ack callback before
>> handling them, instead of in the .irq_eoi callback afterward. Otherwise,
>> it could miss some interrupts.
>>
>> Co-developed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>> Signed-off-by: Samuel Holland <samuel@sholland.org>
>> ---
>>
>> Changes in v1:
>>  - Use a flag for enabling the changes instead of a variant ID
>>  - Use handle_edge_irq instead of handle_fasteoi_ack_irq
>>  - Do not set the handler name, as RISC-V selects GENERIC_IRQ_SHOW_LEVEL
> 
> Where is the Renesas handling gone? Can you, at the very least work,
> with Lad instead of proposing an alternative series that ignores the
> goal of the first one, however good it is (and it is admittedly
> better)?

Sorry, I have reached out to them, and will not send anything more until I hear
back. I thought it was clear that RZ/Five support becomes a trivial patch on top
of this, but I did not include it because there was some unresolved discussion
over what the compatible string should be.

>>
>>  drivers/irqchip/irq-sifive-plic.c | 76 +++++++++++++++++++++++++++++--
>>  1 file changed, 71 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
>> index 90515865af08..462a93b4b088 100644
>> --- a/drivers/irqchip/irq-sifive-plic.c
>> +++ b/drivers/irqchip/irq-sifive-plic.c
>> @@ -69,6 +69,7 @@ struct plic_priv {
>>  	struct cpumask lmask;
>>  	struct irq_domain *irqdomain;
>>  	void __iomem *regs;
>> +	bool needs_edge_handling;
>>  };
>>  
>>  struct plic_handler {
>> @@ -86,6 +87,9 @@ static int plic_parent_irq __ro_after_init;
>>  static bool plic_cpuhp_setup_done __ro_after_init;
>>  static DEFINE_PER_CPU(struct plic_handler, plic_handlers);
>>  
>> +static struct irq_chip plic_edge_chip;
>> +static struct irq_chip plic_chip;
>> +
>>  static void __plic_toggle(void __iomem *enable_base, int hwirq, int enable)
>>  {
>>  	u32 __iomem *reg = enable_base + (hwirq / 32) * sizeof(u32);
>> @@ -181,6 +185,40 @@ static void plic_irq_eoi(struct irq_data *d)
>>  	}
>>  }
>>  
>> +static int plic_irq_set_type(struct irq_data *d, unsigned int flow_type)
>> +{
>> +	struct plic_priv *priv = irq_data_get_irq_chip_data(d);
>> +
>> +	if (!priv->needs_edge_handling)
>> +		return IRQ_SET_MASK_OK_NOCOPY;
>> +
>> +	switch (flow_type) {
>> +	case IRQ_TYPE_EDGE_RISING:
>> +		irq_set_chip_handler_name_locked(d, &plic_edge_chip,
>> +						 handle_edge_irq, NULL);
>> +		break;
>> +	case IRQ_TYPE_LEVEL_HIGH:
>> +		irq_set_chip_handler_name_locked(d, &plic_chip,
>> +						 handle_fasteoi_irq, NULL);
>> +		break;
>> +	default:
>> +		return -EINVAL;
>> +	}
>> +
>> +	return IRQ_SET_MASK_OK;
>> +}
>> +
>> +static struct irq_chip plic_edge_chip = {
>> +	.name			= "PLIC",
>> +	.irq_ack		= plic_irq_eoi,
>> +	.irq_mask		= plic_irq_mask,
>> +	.irq_unmask		= plic_irq_unmask,
>> +#ifdef CONFIG_SMP
>> +	.irq_set_affinity	= plic_set_affinity,
>> +#endif
>> +	.irq_set_type		= plic_irq_set_type,
>> +};
>> +
>>  static struct irq_chip plic_chip = {
>>  	.name			= "PLIC",
>>  	.irq_mask		= plic_irq_mask,
>> @@ -189,8 +227,22 @@ static struct irq_chip plic_chip = {
>>  #ifdef CONFIG_SMP
>>  	.irq_set_affinity	= plic_set_affinity,
>>  #endif
>> +	.irq_set_type		= plic_irq_set_type,
>>  };
>>  
>> +static int plic_irq_domain_translate(struct irq_domain *d,
>> +				     struct irq_fwspec *fwspec,
>> +				     unsigned long *hwirq,
>> +				     unsigned int *type)
>> +{
>> +	struct plic_priv *priv = d->host_data;
>> +
>> +	if (priv->needs_edge_handling)
>> +		return irq_domain_translate_twocell(d, fwspec, hwirq, type);
>> +	else
>> +		return irq_domain_translate_onecell(d, fwspec, hwirq, type);
>> +}
>> +
>>  static int plic_irqdomain_map(struct irq_domain *d, unsigned int irq,
>>  			      irq_hw_number_t hwirq)
>>  {
>> @@ -211,7 +263,7 @@ static int plic_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
>>  	unsigned int type;
>>  	struct irq_fwspec *fwspec = arg;
>>  
>> -	ret = irq_domain_translate_onecell(domain, fwspec, &hwirq, &type);
>> +	ret = plic_irq_domain_translate(domain, fwspec, &hwirq, &type);
>>  	if (ret)
>>  		return ret;
>>  
>> @@ -225,7 +277,7 @@ static int plic_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
>>  }
>>  
>>  static const struct irq_domain_ops plic_irqdomain_ops = {
>> -	.translate	= irq_domain_translate_onecell,
>> +	.translate	= plic_irq_domain_translate,
>>  	.alloc		= plic_irq_domain_alloc,
>>  	.free		= irq_domain_free_irqs_top,
>>  };
>> @@ -286,8 +338,9 @@ static int plic_starting_cpu(unsigned int cpu)
>>  	return 0;
>>  }
>>  
>> -static int __init plic_init(struct device_node *node,
>> -		struct device_node *parent)
>> +static int __init __plic_init(struct device_node *node,
>> +			      struct device_node *parent,
>> +			      bool needs_edge_handling)
>>  {
>>  	int error = 0, nr_contexts, nr_handlers = 0, i;
>>  	u32 nr_irqs;
>> @@ -298,6 +351,8 @@ static int __init plic_init(struct device_node *node,
>>  	if (!priv)
>>  		return -ENOMEM;
>>  
>> +	priv->needs_edge_handling = needs_edge_handling;
>> +
>>  	priv->regs = of_iomap(node, 0);
>>  	if (WARN_ON(!priv->regs)) {
>>  		error = -EIO;
>> @@ -415,6 +470,17 @@ static int __init plic_init(struct device_node *node,
>>  	return error;
>>  }
>>  
>> +static int __init plic_init(struct device_node *node,
>> +			    struct device_node *parent)
>> +{
>> +	return __plic_init(node, parent, false);
>> +}
>>  IRQCHIP_DECLARE(sifive_plic, "sifive,plic-1.0.0", plic_init);
>>  IRQCHIP_DECLARE(riscv_plic0, "riscv,plic0", plic_init); /* for legacy systems */
>> -IRQCHIP_DECLARE(thead_c900_plic, "thead,c900-plic", plic_init); /* for firmware driver */
>> +
>> +static int __init plic_edge_init(struct device_node *node,
>> +				     struct device_node *parent)
>> +{
>> +	return __plic_init(node, parent, true);
>> +}
>> +IRQCHIP_DECLARE(thead_c900_plic, "thead,c900-plic", plic_edge_init);
> 
> No. You are breaking existing platforms with established DTs. You must
> at least be able to run a new kernel with an old DT. Ideally the
> opposite too, but it is hard to retrofit this.

Thankfully, there are no established DTs for this platform. Upstreaming for
Allwinner D1 (the only documented user of this compatible) has been blocked by
its non-coherent DMA, which is just now getting resolved, including with other
major binding changes[1].

If you are referring more generally to DTs "in the wild", those all use
#interrupt-cells = <2> already, albeit with a stacked interrupt controller on
top that turned out not to be necessary[2].

Regards,
Samuel

[1]: https://lore.kernel.org/linux-riscv/20220619203212.3604485-2-heiko@sntech.de/
[2]:
https://github.com/smaeul/linux/blob/riscv/d1-wip/arch/riscv/boot/dts/allwinner/sun20i-d1.dtsi