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
