> -----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. Regards, Besar
