All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: Will Deacon <will.deacon@arm.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/7] ARM: perf_event: Support percpu irqs for the CPU PMU
Date: Tue, 14 Jan 2014 12:57:53 -0800	[thread overview]
Message-ID: <52D5A4D1.9030403@codeaurora.org> (raw)
In-Reply-To: <20140113115213.GE1189@mudshark.cambridge.arm.com>

On 01/13/14 03:52, Will Deacon wrote:
> On Fri, Jan 10, 2014 at 07:36:57PM +0000, Stephen Boyd wrote:
>>
>> Passing the hw_events as the pcpu token here is kind of hacky.
>> The reason is because the token is dereferenced into cpu_pmu in
>> armv7pmu_handle_irq() like so:
>>
>> 	struct arm_pmu *cpu_pmu = (struct arm_pmu *)dev;
>>
>> It would be great if we could pass cpu_pmu directly to the
>> request call like so:
>>
>> 	request_percpu_irq(irq, cpu_pmu->handle_irq, "arm-pmu", &cpu_pmu);
>>
>> but no. request_percpu_irq() wants a percpu pointer so this won't
>> work. If cpu_pmu was declared as DEFINE_PER_CPU, this would work
>> out just fine.
> That feels really broken though, since we rely on the cpu_pmu being a
> container for the struct pmu that was registered with perf core.
>
>> Should the cpu_pmu become a per-cpu variable? That sounds rather
>> invasive.
> I also don't think that's the right solution, based on the above. It's
> actually pretty hard to work out what's the right thing to do here...

Yes it doesn't seem like the right solution.

>
> We *could* have a per-cpu pointer to the cpu_pmu_pointer, but then we'd
> need to update the IRQ handlers, including things like the CCI PMU which
> really doesn't care about per-cpu stuff. So after all this, the shim we have
> around the IRQ handler for the U8500 SPI workarounds might be the right
> thing after all -- it allows us to consolidate the conversion of a pcpu
> pointer into the relevant instance (actually any instance, since they'd all
> point at the same thing) for the current CPU.
>
> What do you think to having that shim throw away the second level pcpu
> pointer in the case of a PPI? (probably means we need to revisit that
> renaming again).

Ok I think I understand what you're getting at. We pass a per-cpu
pointer to the cpu_pmu pointer as the dev_id argument to the PPI irq
handler, and then we check to see if the irq is per-cpu inside the
armpmu_dispatch_irq() function and throw away the second level of
pointer, i.e.

static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
{
        struct arm_pmu *armpmu;
        struct platform_device *plat_device;
        struct arm_pmu_platdata *plat;

        if (irq_is_percpu(irq))
                dev = *(struct arm_pmu_cpu **)dev;
        armpmu = dev;
        plat_device = armpmu->plat_device;
        plat = dev_get_platdata(&plat_device->dev);

        if (plat && plat->handle_irq)
                return plat->handle_irq(irq, dev, armpmu->handle_irq);
        else
                return armpmu->handle_irq(irq, dev);
}


We still need to make a per-cpu variable to hold the pointer, and assign
it during cpu_pmu_init like this patch does. Hopefully that is ok.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

WARNING: multiple messages have this Message-ID (diff)
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/7] ARM: perf_event: Support percpu irqs for the CPU PMU
Date: Tue, 14 Jan 2014 12:57:53 -0800	[thread overview]
Message-ID: <52D5A4D1.9030403@codeaurora.org> (raw)
In-Reply-To: <20140113115213.GE1189@mudshark.cambridge.arm.com>

On 01/13/14 03:52, Will Deacon wrote:
> On Fri, Jan 10, 2014 at 07:36:57PM +0000, Stephen Boyd wrote:
>>
>> Passing the hw_events as the pcpu token here is kind of hacky.
>> The reason is because the token is dereferenced into cpu_pmu in
>> armv7pmu_handle_irq() like so:
>>
>> 	struct arm_pmu *cpu_pmu = (struct arm_pmu *)dev;
>>
>> It would be great if we could pass cpu_pmu directly to the
>> request call like so:
>>
>> 	request_percpu_irq(irq, cpu_pmu->handle_irq, "arm-pmu", &cpu_pmu);
>>
>> but no. request_percpu_irq() wants a percpu pointer so this won't
>> work. If cpu_pmu was declared as DEFINE_PER_CPU, this would work
>> out just fine.
> That feels really broken though, since we rely on the cpu_pmu being a
> container for the struct pmu that was registered with perf core.
>
>> Should the cpu_pmu become a per-cpu variable? That sounds rather
>> invasive.
> I also don't think that's the right solution, based on the above. It's
> actually pretty hard to work out what's the right thing to do here...

Yes it doesn't seem like the right solution.

>
> We *could* have a per-cpu pointer to the cpu_pmu_pointer, but then we'd
> need to update the IRQ handlers, including things like the CCI PMU which
> really doesn't care about per-cpu stuff. So after all this, the shim we have
> around the IRQ handler for the U8500 SPI workarounds might be the right
> thing after all -- it allows us to consolidate the conversion of a pcpu
> pointer into the relevant instance (actually any instance, since they'd all
> point at the same thing) for the current CPU.
>
> What do you think to having that shim throw away the second level pcpu
> pointer in the case of a PPI? (probably means we need to revisit that
> renaming again).

Ok I think I understand what you're getting at. We pass a per-cpu
pointer to the cpu_pmu pointer as the dev_id argument to the PPI irq
handler, and then we check to see if the irq is per-cpu inside the
armpmu_dispatch_irq() function and throw away the second level of
pointer, i.e.

static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
{
        struct arm_pmu *armpmu;
        struct platform_device *plat_device;
        struct arm_pmu_platdata *plat;

        if (irq_is_percpu(irq))
                dev = *(struct arm_pmu_cpu **)dev;
        armpmu = dev;
        plat_device = armpmu->plat_device;
        plat = dev_get_platdata(&plat_device->dev);

        if (plat && plat->handle_irq)
                return plat->handle_irq(irq, dev, armpmu->handle_irq);
        else
                return armpmu->handle_irq(irq, dev);
}


We still need to make a per-cpu variable to hold the pointer, and assign
it during cpu_pmu_init like this patch does. Hopefully that is ok.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

  reply	other threads:[~2014-01-14 20:57 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-08 22:59 [PATCH 0/7] Support Krait CPU PMUs Stephen Boyd
2014-01-08 22:59 ` Stephen Boyd
2014-01-08 22:59 ` [PATCH 1/7] ARM: perf_event: Silence sparse warning Stephen Boyd
2014-01-08 22:59   ` Stephen Boyd
2014-01-09 10:45   ` Will Deacon
2014-01-09 10:45     ` Will Deacon
2014-01-09 23:59     ` Stephen Boyd
2014-01-09 23:59       ` Stephen Boyd
2014-01-09 23:59       ` Stephen Boyd
2014-01-08 22:59 ` [PATCH 2/7] ARM: perf_event: Support percpu irqs for the CPU PMU Stephen Boyd
2014-01-08 22:59   ` Stephen Boyd
2014-01-09 10:49   ` Will Deacon
2014-01-09 10:49     ` Will Deacon
2014-01-09 19:17     ` Stephen Boyd
2014-01-09 19:17       ` Stephen Boyd
2014-01-10 10:58       ` Will Deacon
2014-01-10 10:58         ` Will Deacon
2014-01-10 10:58         ` Will Deacon
2014-01-10 19:36         ` Stephen Boyd
2014-01-10 19:36           ` Stephen Boyd
2014-01-13 11:52           ` Will Deacon
2014-01-13 11:52             ` Will Deacon
2014-01-14 20:57             ` Stephen Boyd [this message]
2014-01-14 20:57               ` Stephen Boyd
2014-01-15 10:33               ` Will Deacon
2014-01-15 10:33                 ` Will Deacon
2014-01-08 22:59 ` [PATCH 3/7] ARM: perf_event: Add basic support for Krait CPU PMUs Stephen Boyd
2014-01-08 22:59   ` Stephen Boyd
2014-01-09 11:04   ` Will Deacon
2014-01-09 11:04     ` Will Deacon
2014-01-09 11:04     ` Will Deacon
2014-01-09 19:57     ` Stephen Boyd
2014-01-09 19:57       ` Stephen Boyd
2014-01-10 11:01       ` Will Deacon
2014-01-10 11:01         ` Will Deacon
2014-01-10 11:01         ` Will Deacon
2014-01-10 18:57         ` Stephen Boyd
2014-01-10 18:57           ` Stephen Boyd
2014-01-08 22:59 ` [PATCH 4/7] ARM: perf_event: Add hook for event index clearing Stephen Boyd
2014-01-08 22:59   ` Stephen Boyd
2014-01-08 22:59 ` [PATCH 5/7] ARM: perf_event: Fully support Krait CPU PMU events Stephen Boyd
2014-01-08 22:59   ` Stephen Boyd
     [not found] ` <1389221984-10973-1-git-send-email-sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-01-08 22:59   ` [PATCH 6/7] devicetree: bindings: Document Krait performance monitor units (PMU) Stephen Boyd
2014-01-08 22:59     ` Stephen Boyd
2014-01-08 22:59     ` Stephen Boyd
2014-01-09 18:14     ` Will Deacon
2014-01-09 18:14       ` Will Deacon
2014-01-09 19:57       ` Stephen Boyd
2014-01-09 19:57         ` Stephen Boyd
2014-01-08 22:59 ` [PATCH 7/7] ARM: dts: msm: Add krait-pmu to platforms with Krait CPUs Stephen Boyd
2014-01-08 22:59   ` Stephen Boyd

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=52D5A4D1.9030403@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=will.deacon@arm.com \
    /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.