All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv2 1/2] ARM: perf_event: allow platform-specific interrupt handler
Date: Fri, 11 Feb 2011 16:33:58 -0000	[thread overview]
Message-ID: <000801cbca09$7bc956a0$735c03e0$@deacon@arm.com> (raw)
In-Reply-To: <1297137277-26889-1-git-send-email-rabin.vincent@stericsson.com>

Hi Rabin,

> Allow a platform-specific IRQ handler to be specified via platform data.  This
> will be used to implement the single-irq workaround for the DB8500.
> 
> Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
> ---
>  arch/arm/include/asm/pmu.h   |   14 ++++++++++++++
>  arch/arm/kernel/perf_event.c |   17 ++++++++++++++++-
>  2 files changed, 30 insertions(+), 1 deletions(-)

If you're happy with this as a workaround for your platform, then
it looks alright to me.

Acked-by: Will Deacon <will.deacon@arm.com>

One thing you could try is using the GIC patch I posted the other day:

http://lists.infradead.org/pipermail/linux-arm-kernel/2011-February/041496.html

If you then do:

    ARM: gic: allow per-cpu SPIs to be affine to multiple CPUs
    
    The concept of a per-cpu SPI is somewhat a contradiction, but can occur in
    systems where SPIs from different CPUs are ORd together into a single line.
    
    An example of this is the PMU interrupt on the u8500 platform.
    
    This patch allows SPIs with the IRQF_PERCPU flag to be affine to multiple
    CPUs in a CPU mask. This, of course, assumes that the driver knows what it
    is doing and can handle such a configuration.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>

diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 9def30b..512f55f 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -145,7 +145,7 @@ gic_set_cpu(struct irq_data *d, const struct cpumask *mask_val, bool force)
 {
        void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + (gic_irq(d) & ~3);
        unsigned int shift = (d->irq % 4) * 8;
-       unsigned int cpu = cpumask_first(mask_val);
+       unsigned int cpu_map, cpu = cpumask_first(mask_val);
        u32 val;
        struct irq_desc *desc;
 
@@ -155,9 +155,19 @@ gic_set_cpu(struct irq_data *d, const struct cpumask *mask_val, bool force)
                spin_unlock(&irq_controller_lock);
                return -EINVAL;
        }
+
        d->node = cpu;
+
+       if (CHECK_IRQ_PER_CPU(desc->status)) {
+               cpu_map = 0;
+               for_each_cpu(cpu, mask_val)
+                       cpu_map |= 1 << (cpu + shift);
+       } else {
+               cpu_map = 1 << (cpu + shift);
+       }
+
        val = readl(reg) & ~(0xff << shift);
-       val |= 1 << (cpu + shift);
+       val |= cpu_map;
        writel(val, reg);
        spin_unlock(&irq_controller_lock);
 

You'll be able to target the PMU IRQ to both CPUs and avoid the need for
ping-ponging the affinity. This is a bit weird though as usually you'd have
a PPI for a percpu interrupt so this might be better off staying inside
platform code and leaving the GIC code alone. I also think this approach
is more invasive from the perf point of view.

Unless this approach gives markedly better profiling results than your
proposal, I think we should go with what you've got.

Will

  parent reply	other threads:[~2011-02-11 16:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-08  3:54 [PATCHv2 1/2] ARM: perf_event: allow platform-specific interrupt handler Rabin Vincent
2011-02-08  3:54 ` [PATCHv2 2/2] ux500: DB8500 PMU support Rabin Vincent
2011-02-11 16:33 ` Will Deacon [this message]
     [not found] ` <-6723806473392693428@unknownmsgid>
2011-02-16 10:34   ` [PATCHv2 1/2] ARM: perf_event: allow platform-specific interrupt handler Rabin Vincent
2011-02-17 16:33     ` Will Deacon
     [not found]     ` <-3663809140750500272@unknownmsgid>
2011-02-17 16:50       ` Rabin Vincent
2011-02-18 11:34         ` Will Deacon

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='000801cbca09$7bc956a0$735c03e0$@deacon@arm.com' \
    --to=will.deacon@arm.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.