From: Anup Patel <anup@brainfault.org> To: Marc Zyngier <maz@kernel.org> Cc: Conor.Dooley@microchip.com, apatel@ventanamicro.com, palmer@dabbelt.com, paul.walmsley@sifive.com, tglx@linutronix.de, daniel.lezcano@linaro.org, atishp@atishpatra.org, Alistair.Francis@wdc.com, 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: Mon, 29 Aug 2022 10:13:21 +0530 [thread overview] Message-ID: <CAAhSdy13G2fjtVMQCMHf0vJff9i1q1Gg_WKQ942Qr9bmQ0NeBg@mail.gmail.com> (raw) In-Reply-To: <69e58f4dc2b74415a32a97998e862479@kernel.org> On Sat, Aug 27, 2022 at 12:27 AM Marc Zyngier <maz@kernel.org> wrote: > > On 2022-08-26 19:48, Conor.Dooley@microchip.com wrote: > > 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 * > > Huh, well spotted. This will totally give the wrong sort of > result, as this is used as a percpu variable from the irq > core code. > > The arm64 code passes instead a pointer to the CPU number, which > is not very useful, but at least not completely wrong. > > I'm sure the RISC-V code has some sort of semi-useful data to > stuff in there instead of this. Unlike arm64, we don't have any percpu data in arch/riscv/kernel/smp.c which can be passed here. For now, I will just add dummy percpu data to make sparse happy. I hope this is okay ? Regards, Anup > > M. > -- > Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Anup Patel <anup@brainfault.org> To: Marc Zyngier <maz@kernel.org> Cc: Conor.Dooley@microchip.com, apatel@ventanamicro.com, palmer@dabbelt.com, paul.walmsley@sifive.com, tglx@linutronix.de, daniel.lezcano@linaro.org, atishp@atishpatra.org, Alistair.Francis@wdc.com, 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: Mon, 29 Aug 2022 10:13:21 +0530 [thread overview] Message-ID: <CAAhSdy13G2fjtVMQCMHf0vJff9i1q1Gg_WKQ942Qr9bmQ0NeBg@mail.gmail.com> (raw) In-Reply-To: <69e58f4dc2b74415a32a97998e862479@kernel.org> On Sat, Aug 27, 2022 at 12:27 AM Marc Zyngier <maz@kernel.org> wrote: > > On 2022-08-26 19:48, Conor.Dooley@microchip.com wrote: > > 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 * > > Huh, well spotted. This will totally give the wrong sort of > result, as this is used as a percpu variable from the irq > core code. > > The arm64 code passes instead a pointer to the CPU number, which > is not very useful, but at least not completely wrong. > > I'm sure the RISC-V code has some sort of semi-useful data to > stuff in there instead of this. Unlike arm64, we don't have any percpu data in arch/riscv/kernel/smp.c which can be passed here. For now, I will just add dummy percpu data to make sparse happy. I hope this is okay ? Regards, Anup > > M. > -- > Jazz is not dead. It just smells funny... _______________________________________________ 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-29 4:43 UTC|newest] Thread overview: 22+ 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 ` 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 ` 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 ` 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 ` Anup Patel 2022-08-20 6:54 ` [PATCH v8 4/7] RISC-V: Treat IPIs as normal Linux IRQs Anup Patel 2022-08-20 6:54 ` Anup Patel 2022-08-26 18:48 ` Conor.Dooley 2022-08-26 18:48 ` Conor.Dooley 2022-08-26 18:57 ` Marc Zyngier 2022-08-26 18:57 ` Marc Zyngier 2022-08-29 4:43 ` Anup Patel [this message] 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 ` 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 ` Anup Patel 2022-08-20 6:54 ` [PATCH v8 7/7] RISC-V: Use IPIs for remote icache " Anup Patel 2022-08-20 6:54 ` 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=CAAhSdy13G2fjtVMQCMHf0vJff9i1q1Gg_WKQ942Qr9bmQ0NeBg@mail.gmail.com \ --to=anup@brainfault.org \ --cc=Alistair.Francis@wdc.com \ --cc=Conor.Dooley@microchip.com \ --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: linkBe 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.