RE: [PATCH 0/2] perf: ARM CoreSight PMU support

quoted

-----Original Message-----
From: Besar Wicaksono
Sent: Wednesday, May 11, 2022 11:45 AM
To: Suzuki K Poulose <suzuki.poulose@arm.com>; Will Deacon
[off-list ref]; Sudeep Holla [off-list ref]
Cc: catalin.marinas@arm.com; mark.rutland@arm.com; linux-arm-
kernel@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
tegra@vger.kernel.org; thanu.rangarajan@arm.com;
Michael.Williams@arm.com; Thierry Reding [off-list ref]; Jonathan
Hunter [off-list ref]; Vikram Sethi [off-list ref];
Mathieu Poirier [off-list ref]
Subject: RE: [PATCH 0/2] perf: ARM CoreSight PMU support

-----Original Message-----
From: Suzuki K Poulose <suzuki.poulose@arm.com>
Sent: Wednesday, May 11, 2022 3:45 AM
To: Will Deacon <will@kernel.org>; Sudeep Holla
[off-list ref]
Cc: Besar Wicaksono <redacted>;
catalin.marinas@arm.com;
mark.rutland@arm.com; linux-arm-kernel@lists.infradead.org; linux-
kernel@vger.kernel.org; linux-tegra@vger.kernel.org;
thanu.rangarajan@arm.com; Michael.Williams@arm.com; Thierry Reding
[off-list ref]; Jonathan Hunter [off-list ref]; Vikram
Sethi [off-list ref]; Mathieu Poirier [off-list ref]
Subject: Re: [PATCH 0/2] perf: ARM CoreSight PMU support

External email: Use caution opening links or attachments

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.
From the other PMU drivers, the registered name may have additional
properties
specific to the implementation, e.g. socket, cluster id, instance number,
memory
address, cache level. Since this is a shared driver, my initial thought is to
register
a default arm_coresight_pmu<APMT node id> naming format for
consistency and
"identifier" sysfs node to distinguish the PMUs. If an implementation needs
to
expose more details about the PMU, it can be communicated via additional
sysfs attributes.
Hi Will and Suzuki,

Shall we go ahead with "arm_system_pmu" for the device name ?

Regards,
Besar
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help