From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 14CE0C433F5 for ; Wed, 11 May 2022 08:46:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=vh4JDRDfsuXOYV9dV8z047aEPTMhjzBZpyQyX2Q3+PY=; b=y4RyN+u2r4Hunq uLHx/AbLky5D82lPISTS5CBXAbTVB/bbOZVj9qQRoz6+n0TsXsm8U4xR/UqDynhIJhsAzsys3kO8d Zu5SSBZfMB+/siLeYj7QsrFFQ7slDgPDBwY9TCYjdIiMbCPHYf/C1z2x8Fm4xK0ZP4GmIkNS7jIYx kGM4rJxYmYtpI/7QW95zGnfQiknE7LYaWs5qwwu/rfXivBahd7Rb4Gk62Dkxx0G/0GlaUjBa6G1uQ TEcq+UXliMnxH86uL8gajT17ig8uFRl/J0/4def6QJM16RjtBeFPMHMhFTuT7biiivRCbxJZZQhfo t3RuGsRylTrTQoLODvIg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nohy0-0061S5-Jb; Wed, 11 May 2022 08:45:08 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nohxx-0061R5-At for linux-arm-kernel@lists.infradead.org; Wed, 11 May 2022 08:45:06 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 499EF106F; Wed, 11 May 2022 01:45:01 -0700 (PDT) Received: from [10.57.1.137] (unknown [10.57.1.137]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 185D63F73D; Wed, 11 May 2022 01:44:58 -0700 (PDT) Message-ID: <6fcc2358-b029-fa01-cf06-aa040f53cf83@arm.com> Date: Wed, 11 May 2022 09:44:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH 0/2] perf: ARM CoreSight PMU support To: Will Deacon , Sudeep Holla Cc: Besar Wicaksono , 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, treding@nvidia.com, jonathanh@nvidia.com, vsethi@nvidia.com, Mathieu Poirier References: <20220509002810.12412-1-bwicaksono@nvidia.com> <20220509092843.GB26264@willie-the-truck> <2e5e09f9-b71b-d936-e291-db8f94554b18@arm.com> <20220510110742.ievkihggndpms3fn@bogus> <20220510111318.GD27557@willie-the-truck> From: Suzuki K Poulose In-Reply-To: <20220510111318.GD27557@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220511_014505_547089_B474D519 X-CRM114-Status: GOOD ( 23.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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" - __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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel