From: Will Deacon <will.deacon@arm.com>
To: Jeremy Linton <jeremy.linton@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com,
punit.agrawal@arm.com, linux-acpi@vger.kernel.org,
mlangsdorf@redhat.com, steve.capper@arm.com
Subject: Re: [PATCH v9 07/10] arm: arm64: pmu: Assign platform PMU CPU affinity
Date: Fri, 16 Sep 2016 14:29:53 +0100 [thread overview]
Message-ID: <20160916132953.GR3380@arm.com> (raw)
In-Reply-To: <1473892358-22574-8-git-send-email-jeremy.linton@arm.com>
On Wed, Sep 14, 2016 at 05:32:35PM -0500, Jeremy Linton wrote:
> On systems with multiple PMU types the PMU to CPU affinity
> needs to be detected and set. The CPU to interrupt affinity
> should also be set.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> ---
> drivers/perf/arm_pmu.c | 63 ++++++++++++++++++++++++++++++++++++++++++--------
> 1 file changed, 53 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> index 58117d7..63f16a5 100644
> --- a/drivers/perf/arm_pmu.c
> +++ b/drivers/perf/arm_pmu.c
> @@ -11,6 +11,7 @@
> */
> #define pr_fmt(fmt) "hw perfevents: " fmt
>
> +#include <linux/acpi.h>
> #include <linux/bitmap.h>
> #include <linux/cpumask.h>
> #include <linux/cpu_pm.h>
> @@ -24,6 +25,7 @@
> #include <linux/irq.h>
> #include <linux/irqdesc.h>
>
> +#include <asm/cpu.h>
> #include <asm/cputype.h>
> #include <asm/irq_regs.h>
>
> @@ -876,25 +878,67 @@ static void cpu_pmu_destroy(struct arm_pmu *cpu_pmu)
> }
>
> /*
> - * CPU PMU identification and probing.
> + * CPU PMU identification and probing. Its possible to have
> + * multiple CPU types in an ARM machine. Assure that we are
> + * picking the right PMU types based on the CPU in question
> */
> -static int probe_current_pmu(struct arm_pmu *pmu,
> - const struct pmu_probe_info *info)
> +static int probe_plat_pmu(struct arm_pmu *pmu,
> + const struct pmu_probe_info *info,
> + unsigned int pmuid)
> {
> - int cpu = get_cpu();
> - unsigned int cpuid = read_cpuid_id();
> int ret = -ENODEV;
> + int cpu;
> + int aff_ctr = 0;
> + static int duplicate_pmus;
> + struct platform_device *pdev = pmu->plat_device;
> + int irq = platform_get_irq(pdev, 0);
>
> - pr_info("probing PMU on CPU %d\n", cpu);
> + if (irq >= 0 && !irq_is_percpu(irq)) {
> + pmu->irq_affinity = kcalloc(pdev->num_resources, sizeof(int),
> + GFP_KERNEL);
> + if (!pmu->irq_affinity)
> + return -ENOMEM;
> + }
>
> + for_each_possible_cpu(cpu) {
> + unsigned int cpuid = read_specific_cpuid(cpu);
> +
> + if (cpuid == pmuid) {
> + cpumask_set_cpu(cpu, &pmu->supported_cpus);
> + if (pmu->irq_affinity) {
> + pmu->irq_affinity[aff_ctr] = cpu;
> + aff_ctr++;
> + }
> + }
> + }
> +
> + /* find the type of PMU given the CPU */
> for (; info->init != NULL; info++) {
> - if ((cpuid & info->mask) != info->cpuid)
> + if ((pmuid & info->mask) != info->cpuid)
> continue;
> ret = info->init(pmu);
> + /*
> + * if this pmu declaration is unspecified and we have
> + * previously found a PMU on this platform then append
> + * a PMU number to the pmu name. This avoids changing
> + * the names of PMUs that are specific to a class of CPUs.
> + * The assumption is that if we match a specific PMU in the
> + * provided pmu_probe_info then it's unique, and another PMU
> + * in the system will match a different entry rather than
> + * needing the _number to assure its unique.
> + */
> + if ((!info->cpuid) && (duplicate_pmus)) {
Hmm, the duplicate_pmus check looks a little odd here. Doesn't it mean
that you'd end up with things like:
"arm,armv8-pmuv3"
"arm,armv8-pmuv3_1"
which looks needlessly fiddly to parse. Is this intentional?
Will
next prev parent reply other threads:[~2016-09-16 13:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-14 22:32 [PATCH v9 00/10] Enable PMUs in ACPI systems Jeremy Linton
2016-09-14 22:32 ` [PATCH v9 01/10] arm64: pmu: add fallback probe table Jeremy Linton
2016-09-14 22:32 ` [PATCH v9 02/10] arm64: pmu: Probe default hw/cache counters Jeremy Linton
2016-09-14 22:32 ` [PATCH v9 03/10] arm64: pmu: Hoist pmu platform device name Jeremy Linton
2016-09-14 22:32 ` [PATCH v9 04/10] arm64: Rename the common MADT parse routine Jeremy Linton
2016-09-14 22:32 ` [PATCH v9 05/10] arm: arm64: Add routine to determine cpuid of other cpus Jeremy Linton
2016-09-14 22:32 ` [PATCH v9 06/10] arm64: pmu: Cache PMU interrupt numbers from MADT parse Jeremy Linton
2016-09-14 22:32 ` [PATCH v9 07/10] arm: arm64: pmu: Assign platform PMU CPU affinity Jeremy Linton
2016-09-16 13:29 ` Will Deacon [this message]
2016-09-16 15:35 ` Jeremy Linton
2016-09-16 15:48 ` Will Deacon
2016-09-16 16:37 ` Punit Agrawal
2016-09-14 22:32 ` [PATCH v9 08/10] arm64: pmu: Detect and enable multiple PMUs in an ACPI system Jeremy Linton
2016-09-16 13:33 ` Punit Agrawal
2016-09-16 16:32 ` Jeremy Linton
2016-09-16 17:07 ` Punit Agrawal
2016-09-16 17:57 ` Jeremy Linton
2016-09-20 16:11 ` Punit Agrawal
2016-09-14 22:32 ` [PATCH v9 09/10] arm: pmu: Add PMU definitions for hot-plugged CPUs Jeremy Linton
2016-09-14 22:32 ` [PATCH v9 10/10] MAINTAINERS: Tweak ARM PMU maintainers Jeremy Linton
2016-09-16 17:13 ` [PATCH v9 00/10] Enable PMUs in ACPI systems Punit Agrawal
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=20160916132953.GR3380@arm.com \
--to=will.deacon@arm.com \
--cc=jeremy.linton@arm.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=mlangsdorf@redhat.com \
--cc=punit.agrawal@arm.com \
--cc=steve.capper@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 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).