linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: lee.jones@linaro.org (Lee Jones)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 15/15] ARM: perf: handle muxed CPU IRQ lines
Date: Wed, 20 Jun 2012 14:44:50 +0100	[thread overview]
Message-ID: <4FE1D3D2.3050209@linaro.org> (raw)
In-Reply-To: <20120620132823.GG32666@mudshark.cambridge.arm.com>

Hi Will,

> On Wed, Jun 20, 2012 at 01:56:51PM +0100, Lee Jones wrote:
>> When registering a PMU device, a platform can either use the generic
>> IRQ handler, or supplement it with one of its own. One of the reasons
>> a platform might choose to do this is to handle the case of muxed IRQ
>> lines. If this is the case and the IRQ is handled on the wrong CPU,
>> this patch sets affinity with the next successive online CPU.
>>
>> Cc: Will Deacon<will.deacon@arm.com>
>> Signed-off-by: Lee Jones<lee.jones@linaro.org>
>> ---
>>   arch/arm/kernel/perf_event_v7.c |   12 +++++++++++-
>>   1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
>> index d3c5360..04a8867 100644
>> --- a/arch/arm/kernel/perf_event_v7.c
>> +++ b/arch/arm/kernel/perf_event_v7.c
>> @@ -1069,8 +1069,18 @@ static irqreturn_t armv7pmu_handle_irq(int irq_num, void *dev)
>>   	/*
>>   	 * Did an overflow occur?
>>   	 */
>> -	if (!armv7_pmnc_has_overflowed(pmnc))
>> +	if (armv7_pmnc_has_overflowed(pmnc)) {
>
> Did you mean to change this predicate?

No sorry, that's a mistake.

>> +		unsigned int next_cpu;
>> +
>> +		next_cpu = cpumask_next(smp_processor_id(), cpu_online_mask);
>> +
>> +		if (next_cpu>= nr_cpumask_bits)
>> +			next_cpu = cpumask_first(cpu_online_mask);
>> +
>> +		irq_set_affinity(irq_num, cpumask_of(next_cpu));
>> +
>
> Shouldn't this be in the platform IRQ handler, rather than the core v7 perf
> code?

Well that's where it currently resides, but in the process of DT:ing the 
platform, we have no real way to set the call-back. Normally, if it's 
absolutely necessary, we do this with AUXDATA. However in the PMU case 
we fall-down as a device address is required for DT look-up, which the 
PMU does not have.

I spoke with Arnd about sensible solutions and he suggested placing the 
logic inside the generic instead, thus supporting muxed IRQ lines 
without the requirement of providing a platform specific handler in 
every instance this occurs (although, I think the ux500 are the only 
platform to do this currently).

I'd be happy to take any other suggestions, but this seemed fairly neat 
and unobtrusive (not withstanding the predicate cock-up).

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2012-06-20 13:44 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-20 12:56 [PATCH 00/15] Device Tree related re-works and clean-ups Lee Jones
2012-06-20 12:56 ` [PATCH 01/15] mfd: Add IRQ domain support for the AB8500 Lee Jones
2012-06-29 14:51   ` Samuel Ortiz
2012-06-20 12:56 ` [PATCH 02/15] mfd: Generically describe interactions with the DB8500 PRCMU Lee Jones
2012-06-29 14:53   ` Samuel Ortiz
2012-06-20 12:56 ` [PATCH 03/15] mfd: Make MFD core code Device Tree and IRQ domain aware Lee Jones
2012-06-29 14:55   ` Samuel Ortiz
2012-06-29 14:52     ` Lee Jones
2012-06-29 18:49       ` Samuel Ortiz
2012-07-02  9:57         ` Lee Jones
2012-07-02 15:01           ` Samuel Ortiz
2012-06-20 12:56 ` [PATCH 04/15] mfd: ab8500: Register devices using the newly DT:ed MFD API Lee Jones
2012-06-29 15:09   ` Samuel Ortiz
2012-06-29 16:04     ` Lee Jones
2012-06-29 18:50       ` Samuel Ortiz
2012-07-02 10:03         ` Lee Jones
2012-07-02 15:14           ` Samuel Ortiz
2012-07-04 15:29             ` Lee Jones
2012-06-20 12:56 ` [PATCH 05/15] mfd: db8500-prcmu: " Lee Jones
2012-06-29 15:11   ` Samuel Ortiz
2012-06-20 12:56 ` [PATCH 06/15] mfd: Register the ab8500 from db8500-prcmu using the " Lee Jones
2012-06-29 15:15   ` Samuel Ortiz
2012-06-20 12:56 ` [PATCH 07/15] i2c: Add Device Tree support to the Nomadik I2C driver Lee Jones
2012-06-20 19:30   ` Linus Walleij
2012-06-21  6:47     ` Srinidhi Kasagar
2012-06-20 12:56 ` [PATCH 08/15] regulator: Stop initialising AB8500's registers during bring-up Lee Jones
2012-06-20 13:08   ` Mark Brown
2012-06-20 13:19     ` Lee Jones
2012-06-20 13:26   ` Mark Brown
2012-06-20 12:56 ` [PATCH 09/15] pinctrl: pinctrl-nomadik: Fix possible memory leak Lee Jones
2012-06-20 12:56 ` [PATCH 10/15] pinctrl: pinctrl-nomadik: Append sleepmode property with vendor specific prefixes Lee Jones
2012-06-20 12:56 ` [PATCH 11/15] ARM: ux500: Remove AB8500 regulator register initialisation information Lee Jones
2012-06-20 12:56 ` [PATCH 12/15] ARM: ux500: Ensure vendor specific properties have the vendor's identifier Lee Jones
2012-06-20 12:56 ` [PATCH 13/15] ARM: ux500: Remove temporary snowball_of_platform_devs enablement structure Lee Jones
2012-06-20 12:56 ` [PATCH 14/15] ARM: ux500: Remove PMU platform registration when booting with DT Lee Jones
2012-06-20 12:56 ` [PATCH 15/15] ARM: perf: handle muxed CPU IRQ lines Lee Jones
2012-06-20 13:28   ` Will Deacon
2012-06-20 13:44     ` Lee Jones [this message]
2012-06-20 14:01       ` Will Deacon
2012-06-20 14:13         ` Lee Jones

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=4FE1D3D2.3050209@linaro.org \
    --to=lee.jones@linaro.org \
    --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).