From: <Conor.Dooley@microchip.com>
To: <apatel@ventanamicro.com>, <palmer@dabbelt.com>,
<paul.walmsley@sifive.com>, <tglx@linutronix.de>,
<maz@kernel.org>, <daniel.lezcano@linaro.org>
Cc: <atishp@atishpatra.org>, <Alistair.Francis@wdc.com>,
<anup@brainfault.org>, <linux-riscv@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v8 4/7] RISC-V: Treat IPIs as normal Linux IRQs
Date: Fri, 26 Aug 2022 18:48:42 +0000 [thread overview]
Message-ID: <8f4ae429-0f12-2096-c07b-fe43b3abb4fe@microchip.com> (raw)
In-Reply-To: <20220820065446.389788-5-apatel@ventanamicro.com>
On 20/08/2022 07:54, Anup Patel wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> Currently, the RISC-V kernel provides arch specific hooks (i.e.
> struct riscv_ipi_ops) to register IPI handling methods. The stats
> gathering of IPIs is also arch specific in the RISC-V kernel.
>
> Other architectures (such as ARM, ARM64, and MIPS) have moved away
> from custom arch specific IPI handling methods. Currently, these
> architectures have Linux irqchip drivers providing a range of Linux
> IRQ numbers to be used as IPIs and IPI triggering is done using
> generic IPI APIs. This approach allows architectures to treat IPIs
> as normal Linux IRQs and IPI stats gathering is done by the generic
> Linux IRQ subsystem.
>
> We extend the RISC-V IPI handling as-per above approach so that arch
> specific IPI handling methods (struct riscv_ipi_ops) can be removed
> and the IPI handling is done through the Linux IRQ subsystem.
>
> Signed-off-by: Anup Patel <apatel@ventanamicro.com>
> +void riscv_ipi_set_virq_range(int virq, int nr)
> +{
> + int i, err;
>
> - if (ops & (1 << IPI_IRQ_WORK)) {
> - stats[IPI_IRQ_WORK]++;
> - irq_work_run();
> - }
> + if (WARN_ON(ipi_virq_base))
> + return;
>
> -#ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
> - if (ops & (1 << IPI_TIMER)) {
> - stats[IPI_TIMER]++;
> - tick_receive_broadcast();
> - }
> -#endif
> - BUG_ON((ops >> IPI_MAX) != 0);
> + WARN_ON(nr < IPI_MAX);
> + nr_ipi = min(nr, IPI_MAX);
> + ipi_virq_base = virq;
> +
> + /* Request IPIs */
> + for (i = 0; i < nr_ipi; i++) {
> + err = request_percpu_irq(ipi_virq_base + i, handle_IPI,
> + "IPI", &ipi_virq_base);
FWIW, ?sparse? does not like this:
arch/riscv/kernel/smp.c:163:50: warning: incorrect type in argument 4 (different address spaces)
arch/riscv/kernel/smp.c:163:50: expected void [noderef] __percpu *percpu_dev_id
arch/riscv/kernel/smp.c:163:50: got int *
> + WARN_ON(err);
>
> - /* Order data access and bit testing. */
> - mb();
> + ipi_desc[i] = irq_to_desc(ipi_virq_base + i);
> + irq_set_status_flags(ipi_virq_base + i, IRQ_HIDDEN);
> }
> +
> + /* Enabled IPIs for boot CPU immediately */
> + riscv_ipi_enable();
> }
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2022-08-26 19:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-20 6:54 [PATCH v8 0/7] RISC-V IPI Improvements Anup Patel
2022-08-20 6:54 ` [PATCH v8 1/7] RISC-V: Clear SIP bit only when using SBI IPI operations Anup Patel
2022-08-20 6:54 ` [PATCH v8 2/7] irqchip/riscv-intc: Allow drivers to directly discover INTC hwnode Anup Patel
2022-08-20 6:54 ` [PATCH v8 3/7] genirq: Add mechanism to multiplex a single HW IPI Anup Patel
2022-08-20 6:54 ` [PATCH v8 4/7] RISC-V: Treat IPIs as normal Linux IRQs Anup Patel
2022-08-26 18:48 ` Conor.Dooley [this message]
2022-08-26 18:57 ` Marc Zyngier
2022-08-29 4:43 ` Anup Patel
2022-08-20 6:54 ` [PATCH v8 5/7] RISC-V: Allow marking IPIs as suitable for remote FENCEs Anup Patel
2022-08-20 6:54 ` [PATCH v8 6/7] RISC-V: Use IPIs for remote TLB flush when possible Anup Patel
2022-08-20 6:54 ` [PATCH v8 7/7] RISC-V: Use IPIs for remote icache " Anup Patel
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=8f4ae429-0f12-2096-c07b-fe43b3abb4fe@microchip.com \
--to=conor.dooley@microchip.com \
--cc=Alistair.Francis@wdc.com \
--cc=anup@brainfault.org \
--cc=apatel@ventanamicro.com \
--cc=atishp@atishpatra.org \
--cc=daniel.lezcano@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=maz@kernel.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox