> -----Original Message----- > From: Besar Wicaksono > Sent: Wednesday, May 11, 2022 11:45 AM > To: Suzuki K Poulose <suzuki.poulose@xxxxxxx>; Will Deacon > <will@xxxxxxxxxx>; Sudeep Holla <sudeep.holla@xxxxxxx> > Cc: catalin.marinas@xxxxxxx; mark.rutland@xxxxxxx; linux-arm- > kernel@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux- > tegra@xxxxxxxxxxxxxxx; thanu.rangarajan@xxxxxxx; > Michael.Williams@xxxxxxx; Thierry Reding <treding@xxxxxxxxxx>; Jonathan > Hunter <jonathanh@xxxxxxxxxx>; Vikram Sethi <vsethi@xxxxxxxxxx>; > Mathieu Poirier <mathieu.poirier@xxxxxxxxxx> > Subject: RE: [PATCH 0/2] perf: ARM CoreSight PMU support > > > > > -----Original Message----- > > From: Suzuki K Poulose <suzuki.poulose@xxxxxxx> > > Sent: Wednesday, May 11, 2022 3:45 AM > > To: Will Deacon <will@xxxxxxxxxx>; Sudeep Holla > <sudeep.holla@xxxxxxx> > > Cc: Besar Wicaksono <bwicaksono@xxxxxxxxxx>; > catalin.marinas@xxxxxxx; > > mark.rutland@xxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux- > > kernel@xxxxxxxxxxxxxxx; linux-tegra@xxxxxxxxxxxxxxx; > > thanu.rangarajan@xxxxxxx; Michael.Williams@xxxxxxx; Thierry Reding > > <treding@xxxxxxxxxx>; Jonathan Hunter <jonathanh@xxxxxxxxxx>; Vikram > > Sethi <vsethi@xxxxxxxxxx>; Mathieu Poirier <mathieu.poirier@xxxxxxxxxx> > > 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
