| Message ID | 20220509002810.12412-1-bwicaksono@nvidia.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | perf: ARM CoreSight PMU support | expand |
On Sun, May 08, 2022 at 07:28:08PM -0500, Besar Wicaksono wrote: > Add driver support for ARM CoreSight PMU device and event attributes for NVIDIA > implementation. The code is based on ARM Coresight PMU architecture and ACPI ARM > Performance Monitoring Unit table (APMT) specification below: > * ARM Coresight PMU: > https://developer.arm.com/documentation/ihi0091/latest > * APMT: https://developer.arm.com/documentation/den0117/latest > > Notes: > * There is a concern on the naming of the PMU device. > Currently the driver is probing "arm-coresight-pmu" device, however the APMT > spec supports different kinds of CoreSight PMU based implementation. So it is > open for discussion if the name can stay or a "generic" name is required. > Please see the following thread: > http://lists.infradead.org/pipermail/linux-arm-kernel/2022-May/740485.html > > Besar Wicaksono (2): > perf: coresight_pmu: Add support for ARM CoreSight PMU driver > perf: coresight_pmu: Add support for NVIDIA SCF and MCF attribute > > 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/? Will
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: >> Add driver support for ARM CoreSight PMU device and event attributes for NVIDIA >> implementation. The code is based on ARM Coresight PMU architecture and ACPI ARM >> Performance Monitoring Unit table (APMT) specification below: >> * ARM Coresight PMU: >> https://developer.arm.com/documentation/ihi0091/latest >> * APMT: https://developer.arm.com/documentation/den0117/latest >> >> Notes: >> * There is a concern on the naming of the PMU device. >> Currently the driver is probing "arm-coresight-pmu" device, however the APMT >> spec supports different kinds of CoreSight PMU based implementation. So it is >> open for discussion if the name can stay or a "generic" name is required. >> Please see the following thread: >> http://lists.infradead.org/pipermail/linux-arm-kernel/2022-May/740485.html >> >> Besar Wicaksono (2): >> perf: coresight_pmu: Add support for ARM CoreSight PMU driver >> perf: coresight_pmu: Add support for NVIDIA SCF and MCF attribute >> >> 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 said, I am concerned that the "coresight_pmu" is easily confused with what exists today. Given that this is more of a "PMU" standard for the IPs in the Arm world, it would be better to name it as such avoiding any confusion with the existing PMUs. 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" "Arm PMU" Suzuki > > Will
Hi, On 2022/5/9 18:02, 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: >>> Add driver support for ARM CoreSight PMU device and event attributes for NVIDIA >>> implementation. The code is based on ARM Coresight PMU architecture and ACPI ARM >>> Performance Monitoring Unit table (APMT) specification below: >>> * ARM Coresight PMU: >>> https://developer.arm.com/documentation/ihi0091/latest >>> * APMT: https://developer.arm.com/documentation/den0117/latest >>> >>> Notes: >>> * There is a concern on the naming of the PMU device. >>> Currently the driver is probing "arm-coresight-pmu" device, however the APMT >>> spec supports different kinds of CoreSight PMU based implementation. So it is >>> open for discussion if the name can stay or a "generic" name is required. >>> Please see the following thread: >>> http://lists.infradead.org/pipermail/linux-arm-kernel/2022-May/740485.html >>> >>> Besar Wicaksono (2): >>> perf: coresight_pmu: Add support for ARM CoreSight PMU driver >>> perf: coresight_pmu: Add support for NVIDIA SCF and MCF attribute >>> >>> 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 said, I am concerned that the "coresight_pmu" is easily confused > with what exists today. Given that this is more of a "PMU" standard > for the IPs in the Arm world, it would be better to name it as such > avoiding any confusion with the existing PMUs. > > 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" To be honest, if wants to distinguish from Arm core PMU, the "Uncore PMU" is a better choice just in my opinion. The x86 including Intel and AMD also do the uncore PMU driver and with "uncore_" prefix. Thanks, Shaokun > "Arm PMU" > > Suzuki > >> >> Will > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > .
> -----Original Message----- > From: Suzuki K Poulose <suzuki.poulose@arm.com> > Sent: Monday, May 9, 2022 5:02 AM > To: Will Deacon <will@kernel.org>; Besar Wicaksono > <bwicaksono@nvidia.com> > 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; sudeep.holla@arm.com; > thanu.rangarajan@arm.com; Michael.Williams@arm.com; Thierry Reding > <treding@nvidia.com>; Jonathan Hunter <jonathanh@nvidia.com>; Vikram > Sethi <vsethi@nvidia.com>; Mathieu Poirier <mathieu.poirier@linaro.org>; > Michael Williams (ATG) <Michael.Williams@arm.com> > Subject: Re: [PATCH 0/2] perf: ARM CoreSight PMU support > > External email: Use caution opening links or attachments > > > 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: > >> Add driver support for ARM CoreSight PMU device and event attributes > for NVIDIA > >> implementation. The code is based on ARM Coresight PMU architecture > and ACPI ARM > >> Performance Monitoring Unit table (APMT) specification below: > >> * ARM Coresight PMU: > >> https://developer.arm.com/documentation/ihi0091/latest > >> * APMT: https://developer.arm.com/documentation/den0117/latest > >> > >> Notes: > >> * There is a concern on the naming of the PMU device. > >> Currently the driver is probing "arm-coresight-pmu" device, however > the APMT > >> spec supports different kinds of CoreSight PMU based implementation. > So it is > >> open for discussion if the name can stay or a "generic" name is required. > >> Please see the following thread: > >> http://lists.infradead.org/pipermail/linux-arm-kernel/2022- > May/740485.html > >> > >> Besar Wicaksono (2): > >> perf: coresight_pmu: Add support for ARM CoreSight PMU driver > >> perf: coresight_pmu: Add support for NVIDIA SCF and MCF attribute > >> > >> 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. Yes, there is no correlation or interaction with existing driver for ETM/STM tracing. It might share same authentication interface (NIDEN, DBGEN, SPIDEN, SPNIDEN) for external debug. But these are not used in the driver. > > That said, I am concerned that the "coresight_pmu" is easily confused > with what exists today. Given that this is more of a "PMU" standard > for the IPs in the Arm world, it would be better to name it as such > avoiding any confusion with the existing PMUs. > > 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" > "Arm PMU" As far as I understand, the APMT does not cover PMU in Arm PE. I think "Arm Uncore PMU" would fit. Regards, Besar > > Suzuki > > > > > Will
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: > > > Add driver support for ARM CoreSight PMU device and event attributes for NVIDIA > > > implementation. The code is based on ARM Coresight PMU architecture and ACPI ARM > > > Performance Monitoring Unit table (APMT) specification below: > > > * ARM Coresight PMU: > > > https://developer.arm.com/documentation/ihi0091/latest > > > * APMT: https://developer.arm.com/documentation/den0117/latest > > > > > > Notes: > > > * There is a concern on the naming of the PMU device. > > > Currently the driver is probing "arm-coresight-pmu" device, however the APMT > > > spec supports different kinds of CoreSight PMU based implementation. So it is > > > open for discussion if the name can stay or a "generic" name is required. > > > Please see the following thread: > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2022-May/740485.html > > > > > > Besar Wicaksono (2): > > > perf: coresight_pmu: Add support for ARM CoreSight PMU driver > > > perf: coresight_pmu: Add support for NVIDIA SCF and MCF attribute > > > > > > 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 said, I am concerned that the "coresight_pmu" is easily confused > with what exists today. Given that this is more of a "PMU" standard > for the IPs in the Arm world, it would be better to name it as such > avoiding any confusion with the existing PMUs. > Thanks Suzuki. I did suggest something similar[1] but asked to retain it so that it can be discussed in the bigger and right forum. > 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.
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
On Tue, May 10, 2022 at 12:13:19PM +0100, 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. > OK, now that triggered another question/thought. 1. Do you need to do active power management for these PMUs ? Or like CPU PMUs, do you reject entering low power states if there is active session in progress. If there is active session, runtime PM won't get triggered but if there is system wide suspend, how is that dealt with ? 2. Assuming you need some sort of PM, and since this is static table(which I really don't like/prefer but it is out there
> -----Original Message----- > From: Sudeep Holla <sudeep.holla@arm.com> > Sent: Tuesday, May 10, 2022 1:40 PM > To: Besar Wicaksono <bwicaksono@nvidia.com> > Cc: Suzuki K Poulose <suzuki.poulose@arm.com>; Will Deacon > <will@kernel.org>; Sudeep Holla <sudeep.holla@arm.com>; > 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 <treding@nvidia.com>; Jonathan > Hunter <jonathanh@nvidia.com>; Vikram Sethi <vsethi@nvidia.com>; > Mathieu Poirier <mathieu.poirier@linaro.org> > Subject: Re: [PATCH 0/2] perf: ARM CoreSight PMU support > > External email: Use caution opening links or attachments > > > On Tue, May 10, 2022 at 12:13:19PM +0100, 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. > > > > OK, now that triggered another question/thought. > > 1. Do you need to do active power management for these PMUs ? Or like > CPU PMUs, do you reject entering low power states if there is active > session in progress. If there is active session, runtime PM won't get > triggered but if there is system wide suspend, how is that dealt with ? > Looking at the other uncore/system PMUs, none of the drivers support PM ops. NVIDIA system PMU also does not get power gated and system suspend is not supported. But just like other uncore PMU driver, this driver supports CPU hotplug. If PM is needed, the required info should have been expressed in ACPI. > 2. Assuming you need some sort of PM, and since this is static table(which > I really don't like/prefer but it is out there
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. Suzuki > avoid it for non-Intel parts. > > Will
On 2022-05-11 02:29, Besar Wicaksono wrote: > > >> -----Original Message----- >> From: Sudeep Holla <sudeep.holla@arm.com> >> Sent: Tuesday, May 10, 2022 1:40 PM >> To: Besar Wicaksono <bwicaksono@nvidia.com> >> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>; Will Deacon >> <will@kernel.org>; Sudeep Holla <sudeep.holla@arm.com>; >> 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 <treding@nvidia.com>; Jonathan >> Hunter <jonathanh@nvidia.com>; Vikram Sethi <vsethi@nvidia.com>; >> Mathieu Poirier <mathieu.poirier@linaro.org> >> Subject: Re: [PATCH 0/2] perf: ARM CoreSight PMU support >> >> External email: Use caution opening links or attachments >> >> >> On Tue, May 10, 2022 at 12:13:19PM +0100, 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. >>> >> >> OK, now that triggered another question/thought. >> >> 1. Do you need to do active power management for these PMUs ? Or like >> CPU PMUs, do you reject entering low power states if there is active >> session in progress. If there is active session, runtime PM won't get >> triggered but if there is system wide suspend, how is that dealt with ? >> > > Looking at the other uncore/system PMUs, none of the drivers support PM ops. > NVIDIA system PMU also does not get power gated and system suspend is not > supported. But just like other uncore PMU driver, this driver supports CPU hotplug. > If PM is needed, the required info should have been expressed in ACPI. > >> 2. Assuming you need some sort of PM, and since this is static table(which >> I really don't like/prefer but it is out there
> -----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 <sudeep.holla@arm.com> > Cc: Besar Wicaksono <bwicaksono@nvidia.com>; 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 > <treding@nvidia.com>; Jonathan Hunter <jonathanh@nvidia.com>; Vikram > Sethi <vsethi@nvidia.com>; Mathieu Poirier <mathieu.poirier@linaro.org> > 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
On 11/05/2022, 18:12, "Robin Murphy" <robin.murphy@arm.com> wrote:
On 2022-05-11 02:29, Besar Wicaksono wrote:
>
>
>> -----Original Message-----
>> From: Sudeep Holla <sudeep.holla@arm.com>
>> Sent: Tuesday, May 10, 2022 1:40 PM
>> To: Besar Wicaksono <bwicaksono@nvidia.com>
>> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>; Will Deacon
>> <will@kernel.org>; Sudeep Holla <sudeep.holla@arm.com>;
>> 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 <treding@nvidia.com>; Jonathan
>> Hunter <jonathanh@nvidia.com>; Vikram Sethi <vsethi@nvidia.com>;
>> Mathieu Poirier <mathieu.poirier@linaro.org>
>> Subject: Re: [PATCH 0/2] perf: ARM CoreSight PMU support
>>
>> External email: Use caution opening links or attachments
>>
>>
>> On Tue, May 10, 2022 at 12:13:19PM +0100, 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.
>>>
>>
>> OK, now that triggered another question/thought.
>>
>> 1. Do you need to do active power management for these PMUs ? Or like
>> CPU PMUs, do you reject entering low power states if there is active
>> session in progress. If there is active session, runtime PM won't get
>> triggered but if there is system wide suspend, how is that dealt with ?
>>
>
> Looking at the other uncore/system PMUs, none of the drivers support PM ops.
> NVIDIA system PMU also does not get power gated and system suspend is not
> supported. But just like other uncore PMU driver, this driver supports CPU hotplug.
> If PM is needed, the required info should have been expressed in ACPI.
>
>> 2. Assuming you need some sort of PM, and since this is static table(which
>> I really don't like/prefer but it is out there
> -----Original Message----- > From: Besar Wicaksono > Sent: Wednesday, May 11, 2022 11:45 AM > To: Suzuki K Poulose <suzuki.poulose@arm.com>; Will Deacon > <will@kernel.org>; Sudeep Holla <sudeep.holla@arm.com> > 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 <treding@nvidia.com>; Jonathan > Hunter <jonathanh@nvidia.com>; Vikram Sethi <vsethi@nvidia.com>; > Mathieu Poirier <mathieu.poirier@linaro.org> > 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 > <sudeep.holla@arm.com> > > Cc: Besar Wicaksono <bwicaksono@nvidia.com>; > 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 > > <treding@nvidia.com>; Jonathan Hunter <jonathanh@nvidia.com>; Vikram > > Sethi <vsethi@nvidia.com>; Mathieu Poirier <mathieu.poirier@linaro.org> > > 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
Add driver support for ARM CoreSight PMU device and event attributes for NVIDIA implementation. The code is based on ARM Coresight PMU architecture and ACPI ARM Performance Monitoring Unit table (APMT) specification below: * ARM Coresight PMU: https://developer.arm.com/documentation/ihi0091/latest * APMT: https://developer.arm.com/documentation/den0117/latest Notes: * There is a concern on the naming of the PMU device. Currently the driver is probing "arm-coresight-pmu" device, however the APMT spec supports different kinds of CoreSight PMU based implementation. So it is open for discussion if the name can stay or a "generic" name is required. Please see the following thread: http://lists.infradead.org/pipermail/linux-arm-kernel/2022-May/740485.html Besar Wicaksono (2): perf: coresight_pmu: Add support for ARM CoreSight PMU driver perf: coresight_pmu: Add support for NVIDIA SCF and MCF attribute 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(+) create mode 100644 drivers/perf/coresight_pmu/Kconfig create mode 100644 drivers/perf/coresight_pmu/Makefile create mode 100644 drivers/perf/coresight_pmu/arm_coresight_pmu.c create mode 100644 drivers/perf/coresight_pmu/arm_coresight_pmu.h create mode 100644 drivers/perf/coresight_pmu/arm_coresight_pmu_nvidia.c create mode 100644 drivers/perf/coresight_pmu/arm_coresight_pmu_nvidia.h