All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Anup Patel <apatel@ventanamicro.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Atish Patra <atishp@atishpatra.org>,
	Alistair Francis <Alistair.Francis@wdc.com>,
	Anup Patel <anup@brainfault.org>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v13 4/7] RISC-V: Treat IPIs as normal Linux IRQs
Date: Wed, 30 Nov 2022 16:18:54 +0000	[thread overview]
Message-ID: <86bkoomn4h.wl-maz@kernel.org> (raw)
In-Reply-To: <20221129142449.886518-5-apatel@ventanamicro.com>

On Tue, 29 Nov 2022 14:24:46 +0000,
Anup Patel <apatel@ventanamicro.com> wrote:
> 
> 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>
> ---
>  arch/riscv/Kconfig                |   2 +
>  arch/riscv/include/asm/sbi.h      |  10 +-
>  arch/riscv/include/asm/smp.h      |  35 ++++---
>  arch/riscv/kernel/Makefile        |   1 +
>  arch/riscv/kernel/cpu-hotplug.c   |   3 +-
>  arch/riscv/kernel/irq.c           |   3 +-
>  arch/riscv/kernel/sbi-ipi.c       |  81 ++++++++++++++++
>  arch/riscv/kernel/sbi.c           | 106 +++-----------------
>  arch/riscv/kernel/smp.c           | 155 +++++++++++++++---------------
>  arch/riscv/kernel/smpboot.c       |   5 +-
>  drivers/clocksource/timer-clint.c |  65 ++++++++++---
>  drivers/irqchip/Kconfig           |   1 +
>  drivers/irqchip/irq-riscv-intc.c  |  55 +++++------
>  13 files changed, 287 insertions(+), 235 deletions(-)
>  create mode 100644 arch/riscv/kernel/sbi-ipi.c
>

[...]

> diff --git a/arch/riscv/kernel/sbi-ipi.c b/arch/riscv/kernel/sbi-ipi.c
> new file mode 100644
> index 000000000000..6466706b03a7
> --- /dev/null
> +++ b/arch/riscv/kernel/sbi-ipi.c
> @@ -0,0 +1,81 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Multiplex several IPIs over a single HW IPI.
> + *
> + * Copyright (c) 2022 Ventana Micro Systems Inc.
> + */
> +
> +#define pr_fmt(fmt) "riscv: " fmt
> +#include <linux/cpu.h>
> +#include <linux/init.h>
> +#include <linux/irq.h>
> +#include <linux/irqdomain.h>
> +#include <linux/percpu.h>
> +#include <asm/sbi.h>
> +
> +static int sbi_ipi_virq;
> +static DEFINE_PER_CPU_READ_MOSTLY(int, sbi_ipi_dummy_dev);
> +
> +static irqreturn_t sbi_ipi_handle(int irq, void *dev_id)
> +{
> +	csr_clear(CSR_IP, IE_SIE);
> +	ipi_mux_process();
> +	return IRQ_HANDLED;

Urgh... I really wish I hadn't seen this. This requires a chained
handler. You had it before, and yet you dropped it. Why?

Either you call ipi_mux_process() from your root interrupt controller,
or you implement a chained handler. But not this.

Same thing about the clint stuff.

	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: Anup Patel <apatel@ventanamicro.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Atish Patra <atishp@atishpatra.org>,
	Alistair Francis <Alistair.Francis@wdc.com>,
	Anup Patel <anup@brainfault.org>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v13 4/7] RISC-V: Treat IPIs as normal Linux IRQs
Date: Wed, 30 Nov 2022 16:18:54 +0000	[thread overview]
Message-ID: <86bkoomn4h.wl-maz@kernel.org> (raw)
In-Reply-To: <20221129142449.886518-5-apatel@ventanamicro.com>

On Tue, 29 Nov 2022 14:24:46 +0000,
Anup Patel <apatel@ventanamicro.com> wrote:
> 
> 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>
> ---
>  arch/riscv/Kconfig                |   2 +
>  arch/riscv/include/asm/sbi.h      |  10 +-
>  arch/riscv/include/asm/smp.h      |  35 ++++---
>  arch/riscv/kernel/Makefile        |   1 +
>  arch/riscv/kernel/cpu-hotplug.c   |   3 +-
>  arch/riscv/kernel/irq.c           |   3 +-
>  arch/riscv/kernel/sbi-ipi.c       |  81 ++++++++++++++++
>  arch/riscv/kernel/sbi.c           | 106 +++-----------------
>  arch/riscv/kernel/smp.c           | 155 +++++++++++++++---------------
>  arch/riscv/kernel/smpboot.c       |   5 +-
>  drivers/clocksource/timer-clint.c |  65 ++++++++++---
>  drivers/irqchip/Kconfig           |   1 +
>  drivers/irqchip/irq-riscv-intc.c  |  55 +++++------
>  13 files changed, 287 insertions(+), 235 deletions(-)
>  create mode 100644 arch/riscv/kernel/sbi-ipi.c
>

[...]

> diff --git a/arch/riscv/kernel/sbi-ipi.c b/arch/riscv/kernel/sbi-ipi.c
> new file mode 100644
> index 000000000000..6466706b03a7
> --- /dev/null
> +++ b/arch/riscv/kernel/sbi-ipi.c
> @@ -0,0 +1,81 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Multiplex several IPIs over a single HW IPI.
> + *
> + * Copyright (c) 2022 Ventana Micro Systems Inc.
> + */
> +
> +#define pr_fmt(fmt) "riscv: " fmt
> +#include <linux/cpu.h>
> +#include <linux/init.h>
> +#include <linux/irq.h>
> +#include <linux/irqdomain.h>
> +#include <linux/percpu.h>
> +#include <asm/sbi.h>
> +
> +static int sbi_ipi_virq;
> +static DEFINE_PER_CPU_READ_MOSTLY(int, sbi_ipi_dummy_dev);
> +
> +static irqreturn_t sbi_ipi_handle(int irq, void *dev_id)
> +{
> +	csr_clear(CSR_IP, IE_SIE);
> +	ipi_mux_process();
> +	return IRQ_HANDLED;

Urgh... I really wish I hadn't seen this. This requires a chained
handler. You had it before, and yet you dropped it. Why?

Either you call ipi_mux_process() from your root interrupt controller,
or you implement a chained handler. But not this.

Same thing about the clint stuff.

	M.

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

  reply	other threads:[~2022-11-30 16:19 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-29 14:24 [PATCH v13 0/7] RISC-V IPI Improvements Anup Patel
2022-11-29 14:24 ` Anup Patel
2022-11-29 14:24 ` [PATCH v13 1/7] RISC-V: Clear SIP bit only when using SBI IPI operations Anup Patel
2022-11-29 14:24   ` Anup Patel
2022-11-29 14:24 ` [PATCH v13 2/7] irqchip/riscv-intc: Allow drivers to directly discover INTC hwnode Anup Patel
2022-11-29 14:24   ` Anup Patel
2022-11-29 14:24 ` [PATCH v13 3/7] genirq: Add mechanism to multiplex a single HW IPI Anup Patel
2022-11-29 14:24   ` Anup Patel
2022-11-30 14:47   ` Marc Zyngier
2022-11-30 14:47     ` Marc Zyngier
2022-11-30 17:03     ` Anup Patel
2022-11-30 17:03       ` Anup Patel
2022-11-29 14:24 ` [PATCH v13 4/7] RISC-V: Treat IPIs as normal Linux IRQs Anup Patel
2022-11-29 14:24   ` Anup Patel
2022-11-30 16:18   ` Marc Zyngier [this message]
2022-11-30 16:18     ` Marc Zyngier
2022-11-30 17:14     ` Anup Patel
2022-11-30 17:14       ` Anup Patel
2022-11-30 18:02       ` Marc Zyngier
2022-11-30 18:02         ` Marc Zyngier
2022-11-30 18:14         ` Anup Patel
2022-11-30 18:14           ` Anup Patel
2022-11-29 14:24 ` [PATCH v13 5/7] RISC-V: Allow marking IPIs as suitable for remote FENCEs Anup Patel
2022-11-29 14:24   ` Anup Patel
2022-11-29 14:24 ` [PATCH v13 6/7] RISC-V: Use IPIs for remote TLB flush when possible Anup Patel
2022-11-29 14:24   ` Anup Patel
2022-11-29 14:24 ` [PATCH v13 7/7] RISC-V: Use IPIs for remote icache " Anup Patel
2022-11-29 14:24   ` 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=86bkoomn4h.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --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=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 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.