Messages in this thread | | | Date | Wed, 11 May 2022 09:44:57 +0100 | Subject | Re: [PATCH 0/2] perf: ARM CoreSight PMU support | From | Suzuki K Poulose <> |
| |
On 10/05/2022 12:13, Will Deacon wrote: > On Tue, May 10, 2022 at 12:07:42PM +0100, Sudeep Holla wrote: >> On Mon, May 09, 2022 at 11:02:23AM +0100, Suzuki K Poulose wrote: >>> Cc: Mike Williams, Mathieu Poirier >>> On 09/05/2022 10:28, Will Deacon wrote: >>>> On Sun, May 08, 2022 at 07:28:08PM -0500, Besar Wicaksono wrote: >>>>> arch/arm64/configs/defconfig | 1 + >>>>> drivers/perf/Kconfig | 2 + >>>>> drivers/perf/Makefile | 1 + >>>>> drivers/perf/coresight_pmu/Kconfig | 10 + >>>>> drivers/perf/coresight_pmu/Makefile | 7 + >>>>> .../perf/coresight_pmu/arm_coresight_pmu.c | 1317 +++++++++++++++++ >>>>> .../perf/coresight_pmu/arm_coresight_pmu.h | 147 ++ >>>>> .../coresight_pmu/arm_coresight_pmu_nvidia.c | 300 ++++ >>>>> .../coresight_pmu/arm_coresight_pmu_nvidia.h | 17 + >>>>> 9 files changed, 1802 insertions(+) >>>> >>>> How does this interact with all the stuff we have under >>>> drivers/hwtracing/coresight/? >>> >>> Absolutely zero, except for the name. The standard >>> is named "CoreSight PMU" which is a bit unfortunate, >>> given the only link, AFAIU, with the "CoreSight" architecture >>> is the Lock Access Register(LAR). For reference, the >>> drivers/hwtracing/coresight/ is purely "CoreSight" self-hosted >>> tracing and the PMU is called "cs_etm" (expands to coresight etm). >>> Otherwise the standard doesn't have anything to do with what >>> exists already in the kernel. > > That's... a poor naming choice! But good, if it's entirely separate then I > don't have to worry about that. Just wanted to make sure we're not going to > get tangled up in things like ROM tables and Coresight power domains for > these things. > >>> One potential recommendation for the name is, "Arm PMU" (The ACPI table is >>> named Arm PMU Table). But then that could be clashing with the armv8_pmu >>> :-(. >>> >>> Some of the other options are : >>> >>> "Arm Generic PMU" >>> "Arm Uncore PMU" >> >> I wasn't sure on this if there is any restriction on usage of this on Arm >> and hence didn't make the suggestion. But if allowed, this would be my >> choice too. > > We'd taken to calling them "System" PMUS in the past, so maybe just stick > with that? I think "Uncore" is Intel terminology so it's probably best to
I thought about that, but there are some IPs named "System Profilers" (e.g., on Juno board) which could be easily confused. But I hope their population in the name space is much less. So, I am happy with that choice. The only other concern is, it doesn't indicate it supports PMUs that are compliant to a given Arm Standard. i.e., people could think of this as a "single type" of PMU. So, I am wondering if something like "Arm Standard PMU" makes any sense ?
Also, I hope the drivers would choose a name indicating the "type" - <vendor>_<type>_pmu (e.g., nvidia_pcie_pmu, arm_smmuv3_pmu etc) while registering their PMU. That way it is clearer for the PMU while the base device could be arm_system_pmu_0 etc.
Suzuki
> avoid it for non-Intel parts. > > Will
| |