From: linux@armlinux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC 3/2] ARM: improve arch_irq_work_has_interrupt()
Date: Mon, 14 Nov 2016 16:57:44 +0000 [thread overview]
Message-ID: <20161114165744.GP1041@n2100.armlinux.org.uk> (raw)
In-Reply-To: <2e14b943-e3a5-6993-48c7-68200c8b08a2@arm.com>
On Mon, Nov 14, 2016 at 04:30:57PM +0000, Marc Zyngier wrote:
> Hi Russell,
>
> On 14/11/16 15:36, Russell King - ARM Linux wrote:
> > Following on from the previous patch, I think this makes more sense to
> > determine whether we can support IRQ work interrupts.
> >
> > Whether we can support them or not depends on two things:
> >
> > (a) whether the kernel has support for receiving IPIs
> > (b) whether it's possible to send an IPI to CPUs including the raising CPU.
> >
> > (a) is a function of how the kernel is built - and in the case of ARM, it
> > depends whether the kernel is built with SMP enabled or not.
> > (b) is a property of the interrupt controller.
> >
> > It hasn't ever been a function of the CPU or architecture.
> >
> > Commit 059e232089e4 ("irqchip/gic: Allow self-SGIs for SMP on UP
> > configurations") changes the GIC IPI code such that we can raise
> > SGIs on uniprocessor systems running on a SMP kernel, which means
> > we can support IRQ work interrupts here as well.
> >
> > So, we shouldn't be using cpu_smp() (or its previous is_smp() here
> > at all. Use a flag to indicate whether we can IPI and use that to
> > indicate whether we support irq work interrupts.
> >
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > ---
> > arch/arm/include/asm/irq_work.h | 11 +++++++++--
> > arch/arm/kernel/irq.c | 0
> > arch/arm/kernel/smp.c | 3 +++
> > drivers/irqchip/irq-gic.c | 17 +++++++++++++----
> > 4 files changed, 25 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/irq_work.h b/arch/arm/include/asm/irq_work.h
> > index 2dc8d7995b48..d7262a3c2f2e 100644
> > --- a/arch/arm/include/asm/irq_work.h
> > +++ b/arch/arm/include/asm/irq_work.h
> > @@ -1,11 +1,18 @@
> > #ifndef __ASM_ARM_IRQ_WORK_H
> > #define __ASM_ARM_IRQ_WORK_H
> >
> > -#include <asm/smp_plat.h>
> > +extern bool irq_controller_can_ipi;
> > +#define irq_controller_can_ipi irq_controller_can_ipi
> >
> > static inline bool arch_irq_work_has_interrupt(void)
> > {
> > - return cpu_smp();
> > +#ifdef CONFIG_SMP
> > + /* This depends on the IRQ controller */
> > + return irq_controller_can_ipi;
> > +#else
> > + /* The kernel is not built to support IPIs */
> > + return false;
> > +#endif
> > }
> >
> > #endif /* _ASM_ARM_IRQ_WORK_H */
> > diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> > index 7dd14e8395e6..1fa9412cc4aa 100644
> > --- a/arch/arm/kernel/smp.c
> > +++ b/arch/arm/kernel/smp.c
> > @@ -473,6 +473,9 @@ void __init set_smp_cross_call(void (*fn)(const struct cpumask *, unsigned int))
> > __smp_cross_call = fn;
> > }
> >
> > +/* This indicates whether the IRQ controller can IPI (including self-IPI) */
> > +bool irq_controller_can_ipi;
>
> We probably need to initialize this to false, since we have at least 4
> other users of set_smp_cross_call() in the tree.
C programming 101: BSS variables are initialised to zero at the start
of the program.
> > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> > index d6c404b3584d..abe8d5807c0f 100644
> > --- a/drivers/irqchip/irq-gic.c
> > +++ b/drivers/irqchip/irq-gic.c
> > @@ -1187,9 +1187,6 @@ static int __init __gic_init_bases(struct gic_chip_data *gic,
> > */
> > for (i = 0; i < NR_GIC_CPU_IF; i++)
> > gic_cpu_map[i] = 0xff;
> > -#ifdef CONFIG_SMP
> > - set_smp_cross_call(gic_raise_softirq);
> > -#endif
> > cpuhp_setup_state_nocalls(CPUHP_AP_IRQ_GIC_STARTING,
> > "AP_IRQ_GIC_STARTING",
> > gic_starting_cpu, NULL);
> > @@ -1207,8 +1204,20 @@ static int __init __gic_init_bases(struct gic_chip_data *gic,
> > }
> >
> > ret = gic_init_bases(gic, irq_start, handle);
> > - if (ret)
> > + if (ret) {
> > kfree(name);
> > + return ret;
> > + }
> > +
> > + if (gic == &gic_data[0]) {
> > +#ifdef CONFIG_SMP
> > + set_smp_cross_call(gic_raise_softirq);
> > +#ifdef irq_controller_can_ipi
> > + if (nr_cpu_ids == 1 || hweight8(gic_cpu_map[0]) == 1)
> > + irq_controller_can_ipi = true;
>
> Am I missing something, or is there any sane configuration where this
> isn't true?
I hope not, but I want to duplicate here the conditions where
gic_raise_softirq() actually _works_ so we stop running into corner
cases where we get "irq work fails" etc.
> Also, maybe it would make some sense to have a more
> streamlined interface to the architecture code. Something along the
> lines of:
>
> diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h
> index 3d6dc8b..45612d2 100644
> --- a/arch/arm/include/asm/smp.h
> +++ b/arch/arm/include/asm/smp.h
> @@ -48,6 +48,16 @@ extern void smp_init_cpus(void);
> */
> extern void set_smp_cross_call(void (*)(const struct cpumask *, unsigned int));
>
> +#ifdef CONFIG_SMP
> +#define setup_smp_ipi(f,i) \
> + do { \
> + set_smp_cross_call(f); \
> + irq_controller_can_ipi = (i); \
> + } while(0)
> +#else
> +#define setup_smp_ipi(f,i) do { } while (0)
> +#endif
> +
> /*
> * Called from platform specific assembly code, this is the
> * secondary CPU entry point.
>
> with the similar entry point for arm64?
I'd prefer to keep the two things separate, but we should definitely
provide a stub for set_smp_cross_call() for when SMP is disabled.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
next prev parent reply other threads:[~2016-11-14 16:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-14 12:57 [PATCH 2/2] ARM: rename is_smp() Russell King
2016-11-14 13:24 ` Gregory CLEMENT
2016-11-14 13:38 ` Russell King - ARM Linux
2016-11-14 15:36 ` [PATCH RFC 3/2] ARM: improve arch_irq_work_has_interrupt() Russell King - ARM Linux
2016-11-14 16:30 ` Marc Zyngier
2016-11-14 16:57 ` Russell King - ARM Linux [this message]
2016-11-14 18:07 ` Russell King - ARM Linux
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=20161114165744.GP1041@n2100.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/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.