[PATCH] ARM: ux500: Initialize irq affinity
Will Deacon
will.deacon at arm.com
Sun Jan 22 07:54:11 EST 2012
Hi Russell,
On Fri, Jan 20, 2012 at 05:44:57PM +0000, Russell King - ARM Linux wrote:
> | So, we have to choose a CPU to route the IRQ to from the mask being
> | requested - and the requested mask may contain anything from a single CPU
> | to multiple CPUs.
> |
> | We choose to route it to the first online CPU in the set. That fits with
> | the model, and does not require us to report back which CPU it's currently
> | routed to. Indeed, architectures such as x86 can't tell you which CPU
> | the next interrupt will hit.
> |
> | So we shouldn't even try to do this on ARM. Yes, we end up with all IRQs
> | targetting CPU0 at boot, and with the masks showing 'all CPUs' but that's
> | not a problem. Really not a problem.
I think this *could* be a problem if, as in Linus's case, some interrupts
have a hardcoded affinity enforced by the hardware (i.e. there are sticky bits
in the GIC distributor CPU targets registers). If we boot on a CPU that is
different from the hardcoded affinity, we could end up initialising an
interrupt with multiple targets. I suspect this will just lead to spurious
interrupts at the end of the day, but there's a potential performance impact
too.
So we could change gic_dist_init to ignore interrupts with sticky bits when
setting up the targets (assuming that the hardcoded target is limited to a
single CPU...) although we also need a way to prevent those interrupts being
moved later on.
For the time being we can just limit ux500 to booting on (physical) CPU 0
and wait and see if anybody hardcodes their targets to point at secondary
CPUs in the future.
Will
More information about the linux-arm-kernel
mailing list