From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Jan Glauber <jglauber@cavium.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Will Deacon <will.deacon@arm.com>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v8 1/3] perf: cavium: Support memory controller PMU counters
Date: Tue, 25 Jul 2017 23:56:34 +0800 [thread overview]
Message-ID: <20170725235634.00002574@huawei.com> (raw)
In-Reply-To: <20170725150422.4775-2-jglauber@cavium.com>
On Tue, 25 Jul 2017 17:04:20 +0200
Jan Glauber <jglauber@cavium.com> wrote:
> Add support for the PMU counters on Cavium SOC memory controllers.
>
> This patch also adds generic functions to allow supporting more
> devices with PMU counters.
>
> Properties of the LMC PMU counters:
> - not stoppable
> - fixed purpose
> - read-only
> - one PCI device per memory controller
>
> Signed-off-by: Jan Glauber <jglauber@cavium.com>
One trivial point inline which, whilst it obviously makes to actual
difference, makes review a tiny bit easier.
Otherwise looks good to me, but I'm somewhat new to this area
so who knows what I've missed ;)
> ---
> drivers/perf/Kconfig | 8 +
> drivers/perf/Makefile | 1 +
> drivers/perf/cavium_pmu.c | 424 +++++++++++++++++++++++++++++++++++++++++++++
> include/linux/cpuhotplug.h | 1 +
> 4 files changed, 434 insertions(+)
> create mode 100644 drivers/perf/cavium_pmu.c
<snip>
> +static int cvm_pmu_lmc_probe(struct pci_dev *pdev)
> +{
> + struct cvm_pmu_dev *next, *lmc;
> + int nr = 0, ret = -ENOMEM;
> +
> + lmc = kzalloc(sizeof(*lmc), GFP_KERNEL);
> + if (!lmc)
> + return -ENOMEM;
> +
> + lmc->map = ioremap(pci_resource_start(pdev, 0),
> + pci_resource_len(pdev, 0));
> + if (!lmc->map)
> + goto fail_ioremap;
> +
> + list_for_each_entry(next, &cvm_pmu_lmcs, entry)
> + nr++;
> + lmc->pmu_name = kasprintf(GFP_KERNEL, "lmc%d", nr);
> + if (!lmc->pmu_name)
> + goto fail_kasprintf;
> +
> + lmc->pdev = pdev;
> + lmc->num_counters = ARRAY_SIZE(lmc_events);
> + lmc->pmu = (struct pmu) {
> + .task_ctx_nr = perf_invalid_context,
> + .event_init = cvm_pmu_event_init,
> + .add = cvm_pmu_lmc_add,
> + .del = cvm_pmu_del,
> + .start = cvm_pmu_start,
> + .stop = cvm_pmu_stop,
> + .read = cvm_pmu_read,
> + .attr_groups = cvm_pmu_lmc_attr_groups,
> + };
> +
> + cpuhp_state_add_instance_nocalls(CPUHP_AP_PERF_ARM_CVM_ONLINE,
> + &lmc->cpuhp_node);
> +
> + /*
> + * perf PMU is CPU dependent so pick a random CPU and migrate away
> + * if it goes offline.
> + */
> + cpumask_set_cpu(smp_processor_id(), &lmc->active_mask);
> +
> + list_add(&lmc->entry, &cvm_pmu_lmcs);
> + lmc->event_valid = cvm_pmu_lmc_event_valid;
> +
> + ret = perf_pmu_register(&lmc->pmu, lmc->pmu_name, -1);
> + if (ret)
> + goto fail_pmu;
> +
> + dev_info(&pdev->dev, "Enabled %s PMU with %d counters\n",
> + lmc->pmu_name, lmc->num_counters);
> + return 0;
> +
> +fail_pmu:
> + kfree(lmc->pmu_name);
> + cpuhp_state_remove_instance(CPUHP_AP_PERF_ARM_CVM_ONLINE,
> + &lmc->cpuhp_node);
Expected order to unwind the above would be the reverse of this.
> +fail_kasprintf:
> + iounmap(lmc->map);
> +fail_ioremap:
> + kfree(lmc);
> + return ret;
> +}
> +
> +static int __init cvm_pmu_init(void)
> +{
> + unsigned long implementor = read_cpuid_implementor();
> + unsigned int vendor_id = PCI_VENDOR_ID_CAVIUM;
> + struct pci_dev *pdev = NULL;
> + int rc;
> +
> + if (implementor != ARM_CPU_IMP_CAVIUM)
> + return -ENODEV;
> +
> + INIT_LIST_HEAD(&cvm_pmu_lmcs);
> +
> + rc = cpuhp_setup_state_multi(CPUHP_AP_PERF_ARM_CVM_ONLINE,
> + "perf/arm/cvm:online", NULL,
> + cvm_pmu_offline_cpu);
> +
> + /* detect LMC devices */
> + while ((pdev = pci_get_device(vendor_id, 0xa022, pdev))) {
> + if (!pdev)
> + break;
> + rc = cvm_pmu_lmc_probe(pdev);
> + if (rc)
> + return rc;
> + }
> + return 0;
> +}
> +late_initcall(cvm_pmu_init); /* should come after PCI init */
> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
> index b56573b..78ac3d2 100644
> --- a/include/linux/cpuhotplug.h
> +++ b/include/linux/cpuhotplug.h
> @@ -141,6 +141,7 @@ enum cpuhp_state {
> CPUHP_AP_PERF_ARM_QCOM_L3_ONLINE,
> CPUHP_AP_WORKQUEUE_ONLINE,
> CPUHP_AP_RCUTREE_ONLINE,
> + CPUHP_AP_PERF_ARM_CVM_ONLINE,
> CPUHP_AP_ONLINE_DYN,
> CPUHP_AP_ONLINE_DYN_END = CPUHP_AP_ONLINE_DYN + 30,
> CPUHP_AP_X86_HPET_ONLINE,
next prev parent reply other threads:[~2017-07-25 15:56 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-25 15:04 [PATCH v8 0/3] Cavium ARM64 uncore PMU support Jan Glauber
2017-07-25 15:04 ` [PATCH v8 1/3] perf: cavium: Support memory controller PMU counters Jan Glauber
2017-07-25 15:39 ` Suzuki K Poulose
2017-07-26 11:19 ` Jan Glauber
2017-07-26 12:47 ` Suzuki K Poulose
2017-07-26 13:10 ` Jan Glauber
2017-07-26 14:35 ` Suzuki K Poulose
2017-07-26 14:55 ` Borislav Petkov
2017-07-26 15:13 ` Jan Glauber
2017-07-26 15:17 ` Suzuki K Poulose
2017-07-26 15:28 ` Borislav Petkov
2017-07-26 15:46 ` Jan Glauber
2017-07-26 16:25 ` Jonathan Cameron
2017-07-26 16:40 ` Jan Glauber
2017-07-26 15:35 ` Borislav Petkov
2017-07-26 15:45 ` Jan Glauber
2017-07-26 15:55 ` Borislav Petkov
2017-07-26 16:19 ` Greg KH
2017-07-26 16:30 ` Borislav Petkov
2017-07-26 17:33 ` Greg KH
2017-07-26 20:02 ` David Daney
2017-07-26 20:08 ` Greg KH
2017-07-26 21:02 ` David Daney
2017-07-27 2:29 ` Greg KH
2017-07-27 17:29 ` David Daney
2017-07-28 1:11 ` Greg KH
2017-07-28 7:23 ` Borislav Petkov
2017-07-27 5:11 ` Borislav Petkov
2017-07-27 9:08 ` Jan Glauber
2017-07-27 13:15 ` Borislav Petkov
2017-07-28 23:12 ` Greg KH
2017-08-08 13:25 ` Will Deacon
2017-08-15 9:13 ` Jan Glauber
2017-08-07 9:37 ` Suzuki K Poulose
2017-07-25 15:56 ` Jonathan Cameron [this message]
2017-07-25 15:04 ` [PATCH v8 2/3] perf: cavium: Support transmit-link " Jan Glauber
2017-07-25 15:04 ` [PATCH v8 3/3] perf: cavium: Add Documentation Jan Glauber
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=20170725235634.00002574@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=jglauber@cavium.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox