From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: ux500: Initialize irq affinity
Date: Fri, 20 Jan 2012 17:50:18 +0000 [thread overview]
Message-ID: <20120120175018.GC11845@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CACRpkdYgT-Q+ZEzhjOaOb_2Pihx0-pMXo+Dc-CESDT7BAWAOqg@mail.gmail.com>
On Fri, Jan 20, 2012 at 04:45:40PM +0100, Linus Walleij wrote:
> On the Ux500 all shared peripheral IRQs (32 thru 127) are delivered
> to CPU0 (hardwired, will not work on CPU1), I have heard that this
> is sort of what everybody does but don't know for sure. (Marc?)
BTW, if you can't route IRQs to a CPU, then we'll need a hook to
refuse the affinity call.
> Currently the gic_set_affinity() in common/gic.c isn't called for any
> IRQs so they are left in their power-on state (from U-Boot or
> similar) which is essentially correct (we checked dumps of the
> registers).
No they aren't. See the gic code:
cpu = cpu_logical_map(smp_processor_id());
cpumask = 1 << cpu;
cpumask |= cpumask << 8;
cpumask |= cpumask << 16;
/*
* Set all global interrupts to this CPU only.
*/
for (i = 32; i < gic_irqs; i += 4)
writel_relaxed(cpumask, base + GIC_DIST_TARGET + i * 4 / 4);
At boot, we program _all_ the GIC IRQs to point@the boot CPU as part
of the initialization, which will be logical CPU 0.
> However when we look at the irq descriptors in e.g. crash:
>
> crash> irq -s
> IRQ NAME AFFINITY
> 36 Nomadik Timer Tick 0
> 43 uart-pl011 0-1
> 44 nmk-i2c 0-1
> 46 pl022 0-1
> 53 nmk-i2c 0-1
> 54 nmk-i2c 0-1
> (... etc ...)
Yes, and as I said in my previous email, having the affinity mask report
more CPUs than we set the hardware to is perfectly legal. What you've
pointed out above is that setting an affinity mask of _just_ CPU1 should
be made fail on Ux500.
In other words, when setting an affinity, if:
affinity & online_mask & ~invalid_cpus
is zero, then we should fail the request to set the affinity.
But that doesn't mean that setting the affinity to ~0 (all CPUs, including
the invalid CPUs) should be failed.
next prev parent reply other threads:[~2012-01-20 17:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-20 12:59 [PATCH] ARM: ux500: Initialize irq affinity Per Fransson
2012-01-20 13:03 ` Russell King - ARM Linux
2012-01-20 15:45 ` Linus Walleij
2012-01-20 16:03 ` Marc Zyngier
2012-01-20 16:08 ` Will Deacon
2012-01-20 17:44 ` Russell King - ARM Linux
2012-01-20 21:28 ` Per Fransson
2012-01-22 12:54 ` Will Deacon
2012-01-22 15:27 ` Russell King - ARM Linux
2012-01-24 11:04 ` Will Deacon
2012-01-24 22:00 ` Linus Walleij
2012-01-20 17:50 ` Russell King - ARM Linux [this message]
2012-01-20 17:56 ` Linus Walleij
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=20120120175018.GC11845@n2100.arm.linux.org.uk \
--to=linux@arm.linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).