All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Cc: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Sagar Kadam <sagar.kadam@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Biju Das <biju.das.jz@bp.renesas.com>
Subject: Re: [PATCH 2/2] irqchip/sifive-plic: Add support for Renesas RZ/Five SoC
Date: Sat, 25 Jun 2022 17:05:59 +0100	[thread overview]
Message-ID: <87zgi0eniw.wl-maz@kernel.org> (raw)
In-Reply-To: <CA+V-a8tFn7aS-1jD6o9TX9kNDQ=4S3xWCXwkww3Es2+Red6vmA@mail.gmail.com>

On Sat, 25 Jun 2022 14:03:33 +0100,
"Lad, Prabhakar" <prabhakar.csengg@gmail.com> wrote:
> 
> [1  <text/plain; UTF-8 (7bit)>]
> Hi Marc,
> 
> On Sat, Jun 25, 2022 at 12:52 PM Marc Zyngier <maz@kernel.org> wrote:
> >

[...]

> > You are just reinventing the wheel we are already have, except that
> > yours is a bit square ;-). What really should happen is that the
> > set_type method should set the correct flow depending on the trigger
> > of the interrupt, and *never* have to check the configuration on the
> > handling path.
> >
> A Bit lost here..
> 
> We have the below chained handler:
> 
> static void plic_handle_irq(struct irq_desc *desc)
> {
>     struct plic_handler *handler = this_cpu_ptr(&plic_handlers);
>     struct irq_chip *chip = irq_desc_get_chip(desc);
>     void __iomem *claim = handler->hart_base + CONTEXT_CLAIM;
>     irq_hw_number_t hwirq;
> 
>     WARN_ON_ONCE(!handler->present);
> 
>     chained_irq_enter(chip, desc);
> 
>     while ((hwirq = readl(claim))) {
>         int err = generic_handle_domain_irq(handler->priv->irqdomain,
>                             hwirq);
>         if (unlikely(err))
>             pr_warn_ratelimited("can't find mapping for hwirq %lu\n",
>                     hwirq);
>     }
> 
>     chained_irq_exit(chip, desc);
> }
> 
> static void plic_irq_eoi(struct irq_data *d)
> {
>     struct plic_handler *handler = this_cpu_ptr(&plic_handlers);
> 
>     if (irqd_irq_masked(d)) {
>         plic_irq_unmask(d);
>         writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
>         plic_irq_mask(d);
>     } else {
>         writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
>     }
> }
> 
> Where it's claiming -> handling interrupt -> interrupt completion in
> eoi which is according to architecture.
> 
> 
> Now with fasteoi_ack flow If I introduce the below ack callback to
> issue interrupt completion.
> 
> static void plic_irq_ack(struct irq_data *d)
> {
>     struct plic_handler *handler = this_cpu_ptr(&plic_handlers);
> 
>     if (irqd_irq_masked(d)) {
>         plic_irq_unmask(d);
>         writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
>         plic_irq_mask(d);
>     } else {
>         writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
>     }
> }
> 
> Here we are issuing an interrupt completion first, and later in the
> handler  plic_handle_irq() we are claiming the interrupt by reading
> the claim register. With this we are not following [0].

Whatever [0] says doesn't really matter, since the HW is totally
busted.

> Do you think this flow is OK (interrupt completion -> Interrupt claim
> -> handle IRQ)?

You keep missing my point. Edge and Level *must* have different flows
and this also implies different callbacks. You can't just handle both
at once. You should have something like this (untested):

diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
index bb87e4c3b88e..5e072be32d9f 100644
--- a/drivers/irqchip/irq-sifive-plic.c
+++ b/drivers/irqchip/irq-sifive-plic.c
@@ -176,16 +176,52 @@ static void plic_irq_eoi(struct irq_data *d)
 	}
 }
 
+static int broken_set_type(struct irq_data *d, unsigned int type);
+
 static struct irq_chip plic_chip = {
 	.name		= "SiFive PLIC",
 	.irq_mask	= plic_irq_mask,
 	.irq_unmask	= plic_irq_unmask,
 	.irq_eoi	= plic_irq_eoi,
+	.irq_set_type	= broken_set_type,
+#ifdef CONFIG_SMP
+	.irq_set_affinity = plic_set_affinity,
+#endif
+};
+
+static void broken_eoi(struct irq_data *data) {}
+
+static struct irq_chip plic_chip_edge = {
+	.name		= "Edgy PLIC",
+	.irq_mask	= plic_irq_mask,
+	.irq_unmask	= plic_irq_unmask,
+	.irq_ack	= plic_irq_eoi,
+	.irq_eoi	= broken_eoi,
+	.irq_set_type	= broken_set_type,
 #ifdef CONFIG_SMP
 	.irq_set_affinity = plic_set_affinity,
 #endif
 };
 
+static int broken_set_type(struct irq_data *d, unsigned int type)
+{
+	if (!plic_is_totaly_broken())
+		return 0;
+
+	if (type == IRQ_TYPE_EDGE_RISING)
+		irq_set_chip_handler_name_locked(d, plic_chip_edge,
+						 handle_fasteoi_ack_irq,
+						 "Edge");
+	else if (type == IRQ_TYPE_LEVEL_HIGH)
+		irq_set_chip_handler_name_locked(d, plic_chip,
+						 handle_fasteoi_irq,
+						 "Level");
+	else
+		return -EINVAL;
+
+	return 0;
+}
+
 static int plic_irqdomain_map(struct irq_domain *d, unsigned int irq,
 			      irq_hw_number_t hwirq)
 {

which applies the correct flow and chip depending on the trigger
information. This also implies that for chained PLICs, the secondary
PLIC output is handled as a level into the primary PLIC.

	M.

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

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Cc: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Sagar Kadam <sagar.kadam@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Biju Das <biju.das.jz@bp.renesas.com>
Subject: Re: [PATCH 2/2] irqchip/sifive-plic: Add support for Renesas RZ/Five SoC
Date: Sat, 25 Jun 2022 17:05:59 +0100	[thread overview]
Message-ID: <87zgi0eniw.wl-maz@kernel.org> (raw)
In-Reply-To: <CA+V-a8tFn7aS-1jD6o9TX9kNDQ=4S3xWCXwkww3Es2+Red6vmA@mail.gmail.com>

On Sat, 25 Jun 2022 14:03:33 +0100,
"Lad, Prabhakar" <prabhakar.csengg@gmail.com> wrote:
> 
> [1  <text/plain; UTF-8 (7bit)>]
> Hi Marc,
> 
> On Sat, Jun 25, 2022 at 12:52 PM Marc Zyngier <maz@kernel.org> wrote:
> >

[...]

> > You are just reinventing the wheel we are already have, except that
> > yours is a bit square ;-). What really should happen is that the
> > set_type method should set the correct flow depending on the trigger
> > of the interrupt, and *never* have to check the configuration on the
> > handling path.
> >
> A Bit lost here..
> 
> We have the below chained handler:
> 
> static void plic_handle_irq(struct irq_desc *desc)
> {
>     struct plic_handler *handler = this_cpu_ptr(&plic_handlers);
>     struct irq_chip *chip = irq_desc_get_chip(desc);
>     void __iomem *claim = handler->hart_base + CONTEXT_CLAIM;
>     irq_hw_number_t hwirq;
> 
>     WARN_ON_ONCE(!handler->present);
> 
>     chained_irq_enter(chip, desc);
> 
>     while ((hwirq = readl(claim))) {
>         int err = generic_handle_domain_irq(handler->priv->irqdomain,
>                             hwirq);
>         if (unlikely(err))
>             pr_warn_ratelimited("can't find mapping for hwirq %lu\n",
>                     hwirq);
>     }
> 
>     chained_irq_exit(chip, desc);
> }
> 
> static void plic_irq_eoi(struct irq_data *d)
> {
>     struct plic_handler *handler = this_cpu_ptr(&plic_handlers);
> 
>     if (irqd_irq_masked(d)) {
>         plic_irq_unmask(d);
>         writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
>         plic_irq_mask(d);
>     } else {
>         writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
>     }
> }
> 
> Where it's claiming -> handling interrupt -> interrupt completion in
> eoi which is according to architecture.
> 
> 
> Now with fasteoi_ack flow If I introduce the below ack callback to
> issue interrupt completion.
> 
> static void plic_irq_ack(struct irq_data *d)
> {
>     struct plic_handler *handler = this_cpu_ptr(&plic_handlers);
> 
>     if (irqd_irq_masked(d)) {
>         plic_irq_unmask(d);
>         writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
>         plic_irq_mask(d);
>     } else {
>         writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
>     }
> }
> 
> Here we are issuing an interrupt completion first, and later in the
> handler  plic_handle_irq() we are claiming the interrupt by reading
> the claim register. With this we are not following [0].

Whatever [0] says doesn't really matter, since the HW is totally
busted.

> Do you think this flow is OK (interrupt completion -> Interrupt claim
> -> handle IRQ)?

You keep missing my point. Edge and Level *must* have different flows
and this also implies different callbacks. You can't just handle both
at once. You should have something like this (untested):

diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
index bb87e4c3b88e..5e072be32d9f 100644
--- a/drivers/irqchip/irq-sifive-plic.c
+++ b/drivers/irqchip/irq-sifive-plic.c
@@ -176,16 +176,52 @@ static void plic_irq_eoi(struct irq_data *d)
 	}
 }
 
+static int broken_set_type(struct irq_data *d, unsigned int type);
+
 static struct irq_chip plic_chip = {
 	.name		= "SiFive PLIC",
 	.irq_mask	= plic_irq_mask,
 	.irq_unmask	= plic_irq_unmask,
 	.irq_eoi	= plic_irq_eoi,
+	.irq_set_type	= broken_set_type,
+#ifdef CONFIG_SMP
+	.irq_set_affinity = plic_set_affinity,
+#endif
+};
+
+static void broken_eoi(struct irq_data *data) {}
+
+static struct irq_chip plic_chip_edge = {
+	.name		= "Edgy PLIC",
+	.irq_mask	= plic_irq_mask,
+	.irq_unmask	= plic_irq_unmask,
+	.irq_ack	= plic_irq_eoi,
+	.irq_eoi	= broken_eoi,
+	.irq_set_type	= broken_set_type,
 #ifdef CONFIG_SMP
 	.irq_set_affinity = plic_set_affinity,
 #endif
 };
 
+static int broken_set_type(struct irq_data *d, unsigned int type)
+{
+	if (!plic_is_totaly_broken())
+		return 0;
+
+	if (type == IRQ_TYPE_EDGE_RISING)
+		irq_set_chip_handler_name_locked(d, plic_chip_edge,
+						 handle_fasteoi_ack_irq,
+						 "Edge");
+	else if (type == IRQ_TYPE_LEVEL_HIGH)
+		irq_set_chip_handler_name_locked(d, plic_chip,
+						 handle_fasteoi_irq,
+						 "Level");
+	else
+		return -EINVAL;
+
+	return 0;
+}
+
 static int plic_irqdomain_map(struct irq_domain *d, unsigned int irq,
 			      irq_hw_number_t hwirq)
 {

which applies the correct flow and chip depending on the trigger
information. This also implies that for chained PLICs, the secondary
PLIC output is handled as a level into the primary PLIC.

	M.

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

  reply	other threads:[~2022-06-25 16:06 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-24 18:03 [PATCH 0/2] Add PLIC support for Renesas RZ/Five SoC Lad Prabhakar
2022-06-24 18:03 ` Lad Prabhakar
2022-06-24 18:03 ` [PATCH 1/2] dt-bindings: interrupt-controller: sifive,plic: Document " Lad Prabhakar
2022-06-24 18:03   ` Lad Prabhakar
2022-06-25 20:01   ` Krzysztof Kozlowski
2022-06-25 20:01     ` Krzysztof Kozlowski
2022-06-26  0:31     ` Lad, Prabhakar
2022-06-26  0:31       ` Lad, Prabhakar
2022-06-24 18:03 ` [PATCH 2/2] irqchip/sifive-plic: Add support for " Lad Prabhakar
2022-06-24 18:03   ` Lad Prabhakar
2022-06-25  9:03   ` Marc Zyngier
2022-06-25  9:03     ` Marc Zyngier
2022-06-25  9:54     ` Lad, Prabhakar
2022-06-25  9:54       ` Lad, Prabhakar
2022-06-25 11:52       ` Marc Zyngier
2022-06-25 11:52         ` Marc Zyngier
2022-06-25 13:03         ` Lad, Prabhakar
2022-06-25 13:03           ` Lad, Prabhakar
2022-06-25 16:05           ` Marc Zyngier [this message]
2022-06-25 16:05             ` Marc Zyngier
2022-06-26  0:34             ` Lad, Prabhakar
2022-06-26  0:34               ` Lad, Prabhakar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zgi0eniw.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=devicetree@vger.kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=prabhakar.csengg@gmail.com \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
    --cc=robh+dt@kernel.org \
    --cc=sagar.kadam@sifive.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.