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
avoid it for non-Intel parts.
Will