From: Nam Cao <namcao@linutronix.de>
To: zhengyan <zhengyan@asrmicro.com>
Cc: tglx@linutronix.de, maz@kernel.org, linux-kernel@vger.kernel.org,
paul.walmsley@sifive.com, samuel.holland@sifive.com,
linux-riscv@lists.infradead.org, qiaozhou@asrmicro.com
Subject: Re: [PATCH] irqchip/sifive-plic: ensure interrupt is enable before EOI
Date: Mon, 24 Jun 2024 11:35:56 +0200 [thread overview]
Message-ID: <20240624093556.ZcZgu2GF@linutronix.de> (raw)
In-Reply-To: <20240624085341.3935-1-zhengyan@asrmicro.com>
On Mon, Jun 24, 2024 at 08:53:41AM +0000, zhengyan wrote:
> RISC-V PLIC cannot "end-of-interrupt" (EOI) disabled interrupts, as
> explained in the description of Interrupt Completion in the PLIC spec:
> "The PLIC signals it has completed executing an interrupt handler by
> writing the interrupt ID it received from the claim to the claim/complete
> register. The PLIC does not check whether the completion ID is the same
> as the last claim ID for that target. If the completion ID does not match
> an interrupt source that *is currently enabled* for the target, the
> completion is silently ignored."
>
> Commit 9c92006b896c ("irqchip/sifive-plic: Enable interrupt if needed
> before EOI")
> ensured that EOI is enable when irqd IRQD_IRQ_DISABLED is set, before
> EOI
>
> Commit 69ea463021be ("irqchip/sifive-plic: Fixup EOI failed when masked")
> ensured that EOI is successful by enabling interrupt first, before EOI.
>
> Commit a1706a1c5062 ("irqchip/sifive-plic: Separate the enable and mask
> operations") removed the interrupt enabling code from the previous
> commit, because it assumes that interrupt should already be enabled at the
> point of EOI.
>
> However, here still miss a corner case that if SMP is enabled. When
> someone need to set affinity from a cpu to another (Maybe like
> boardcast-tick) the original cpu when handle the EOI meanwhile the IE is
> disabled by plic_set_affinity
>
> So this patch ensure that won't happened
>
> Signed-off-by: zhengyan <zhengyan@asrmicro.com>
> ---
> drivers/irqchip/irq-sifive-plic.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
> index 9e22f7e378f5..e6acd134a691 100644
> --- a/drivers/irqchip/irq-sifive-plic.c
> +++ b/drivers/irqchip/irq-sifive-plic.c
> @@ -149,8 +149,10 @@ static void plic_irq_mask(struct irq_data *d)
> static void plic_irq_eoi(struct irq_data *d)
> {
> struct plic_handler *handler = this_cpu_ptr(&plic_handlers);
> + void __iomem *reg = handler->enable_base + (d->hwirq / 32) * sizeof(u32);
> + u32 hwirq_mask = 1 << (d->hwirq % 32);
>
> - if (unlikely(irqd_irq_disabled(d))) {
> + if (unlikely(irqd_irq_disabled(d)) || (readl(reg) & hwirq_mask) == 0) {
If we read interrupt enable state from hardware, then reading the
software state (irqd_irq_disabled) is redundant.
> plic_toggle(handler, d->hwirq, 1);
> writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
> plic_toggle(handler, d->hwirq, 0);
I have no knowledge about affinity stuff, so I don't really understand this
patch. But there is another idea regarding this "ignored EOI" problem:
always "complete" the interrupt while enabling. That would move this extra
complication out of the hot path, and also looks simpler in my opinion.
Something like the patch below. Would this solve this "affinity problem"
too?
Best regards,
Nam
diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
index 0a233e9d9607..63f2111ced4a 100644
--- a/drivers/irqchip/irq-sifive-plic.c
+++ b/drivers/irqchip/irq-sifive-plic.c
@@ -122,7 +122,15 @@ static inline void plic_irq_toggle(const struct cpumask *mask,
static void plic_irq_enable(struct irq_data *d)
{
+ struct plic_priv *priv = irq_data_get_irq_chip_data(d);
+
+ writel(0, priv->regs + PRIORITY_BASE + d->hwirq * PRIORITY_PER_ID);
+
+ writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
+
plic_irq_toggle(irq_data_get_effective_affinity_mask(d), d, 1);
+
+ writel(1, priv->regs + PRIORITY_BASE + d->hwirq * PRIORITY_PER_ID);
}
static void plic_irq_disable(struct irq_data *d)
@@ -148,13 +156,7 @@ static void plic_irq_eoi(struct irq_data *d)
{
struct plic_handler *handler = this_cpu_ptr(&plic_handlers);
- if (unlikely(irqd_irq_disabled(d))) {
- plic_toggle(handler, d->hwirq, 1);
- writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
- plic_toggle(handler, d->hwirq, 0);
- } else {
- writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
- }
+ writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
}
#ifdef CONFIG_SMP
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2024-06-24 9:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-24 8:53 [PATCH] irqchip/sifive-plic: ensure interrupt is enable before EOI zhengyan
2024-06-24 9:35 ` Nam Cao [this message]
2024-06-24 11:14 ` 答复: " Yan Zheng(严政)
2024-06-24 11:35 ` [PATCH v2] " zhengyan
2024-07-07 18:27 ` Nam Cao
2024-07-22 7:36 ` 答复: " Yan Zheng(严政)
2024-06-24 11:56 ` 答复: [PATCH] " Nam Cao
2024-06-24 12:43 ` 答复: " Yan Zheng(严政)
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=20240624093556.ZcZgu2GF@linutronix.de \
--to=namcao@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=maz@kernel.org \
--cc=paul.walmsley@sifive.com \
--cc=qiaozhou@asrmicro.com \
--cc=samuel.holland@sifive.com \
--cc=tglx@linutronix.de \
--cc=zhengyan@asrmicro.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox