[PATCH] ARM: ux500: Initialize irq affinity
Russell King - ARM Linux
linux at arm.linux.org.uk
Fri Jan 20 12:44:57 EST 2012
On Fri, Jan 20, 2012 at 04:45:40PM +0100, Linus Walleij wrote:
> On Fri, Jan 20, 2012 at 2:03 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > On Fri, Jan 20, 2012 at 01:59:16PM +0100, Per Fransson wrote:
> >> Use irq_set_affinity() to initialize the kernel view of irq affinity
> >> when programming the GIC registers.
> >
> > Why is this necessary?
>
> Necessary: we don't quite know. (Maybe should have been RFC, but
> this patch is better than being silent of it...)
I'm afraid Per Fransson took the thread off the mailing lists,
so my reply to him also wasn't public. Here's what I said:
| The affinity starts off as "all CPUs", and the implementation is free
| to route the IRQ to any of those CPUs. On x86, some hardware is smart
| enough to route the IRQ to one of a set of CPUs, choosing which CPU
| to target in hardware.
|
| We don't have that ability, and trying to do that in software proved to
| be very problematic to get it to work satisfactorily. Given that there
| is a userspace daemon which helps to solve the problem, it was decided
| that we wouldn't bother with this i the kernel.
|
| 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.
More information about the linux-arm-kernel
mailing list