[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <878uakqbyl.fsf@eliezer.anholt.net>
Date: Mon, 13 Jul 2015 09:06:10 -0700
From: Eric Anholt <eric@...olt.net>
To: Thomas Gleixner <tglx@...utronix.de>,
Stephen Warren <swarren@...dotorg.org>
Cc: linux-arm-kernel@...ts.infradead.org,
linux-rpi-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Lee Jones <lee@...nel.org>, devicetree@...r.kernel.org,
Jason Cooper <jason@...edaemon.net>,
Andrea Merello <andrea.merello@...il.com>
Subject: Re: [PATCH 4/4] irqchip: Add bcm2836 interrupt controller for Raspberry Pi 2.
Thomas Gleixner <tglx@...utronix.de> writes:
> On Fri, 10 Jul 2015, Stephen Warren wrote:
>> On 07/07/2015 03:13 PM, Eric Anholt wrote:
>> > +static void bcm2836_mask_per_cpu_irq(unsigned int reg, unsigned int bit)
>> > +{
>> > + void __iomem *reg_base = intc.base + reg;
>> > + unsigned int i;
>> > +
>> > + for (i = 0; i < 4; i++)
>>
>> Is "4" there the CPU count? Perhaps this should use one of the Linux
>> APIs to query the CPU count rather than hard-coding it?
>>
>> Should per-CPU IRQs automatically be masked on all CPUs at once, or only
>> on the current CPU? A very quick look at the ARM GIC driver implies it
>> doesn't iterate over all CPUs when masking per-CPU IRQs.
>
> Usually per cpu interrupts are only masked on the cpu which is calling
> the function. The whole reason why per cpu interrupts exist is that
> you can share the same interrupt number for all cores.
>
> So masking all interrupts is not a good idea. In this case if a cpu is
> hot unplugged, then all other cpus would not longer get timer
> interrupts. Not what you really want, right?
I was replicating the behavior of the downstream driver, but it seemed
suspicious. Converting to using smp_processor_id() to just mask/unmask
this CPU's interrupts seems to have gone fine.
Download attachment "signature.asc" of type "application/pgp-signature" (819 bytes)
Powered by blists - more mailing lists