[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220510111318.GD27557@willie-the-truck>
Date: Tue, 10 May 2022 12:13:19 +0100
From: Will Deacon <will@...nel.org>
To: Sudeep Holla <sudeep.holla@....com>
Cc: Suzuki K Poulose <suzuki.poulose@....com>,
Besar Wicaksono <bwicaksono@...dia.com>,
catalin.marinas@....com, mark.rutland@....com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-tegra@...r.kernel.org, thanu.rangarajan@....com,
Michael.Williams@....com, treding@...dia.com, jonathanh@...dia.com,
vsethi@...dia.com, Mathieu Poirier <mathieu.poirier@...aro.org>
Subject: Re: [PATCH 0/2] perf: ARM CoreSight PMU support
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
Powered by blists - more mailing lists