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 83EAAC433FE for ; Fri, 3 Dec 2021 12:07:29 +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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=zUZ9LDMcQwm1AahFI61uQJuFLbYRBerN4lSHKjZZS+0=; b=RgfXSe7bpI5+Ve aJMPhLfgRzgowRnWAS91GgYz9sIQMNrQX/TBMdaTkEHssLPh80d3Ftpx4JgvNpfHTK32D2qLQ4UVJ r33XjhBKfDEZypsioVoXLYjuX9YfBlKOAs3xJqxPAUoWLM3uN8JRPriF3gGKXX55tTPBdyJYz0q+p p07Kigh2VbS8AvtTX+549Ie875d3ziGLG/xN8t32K8kkewZe1myJx3k2jzr4TsijsEpN1iJkINNS8 JLEXWng1ehbXwSDIsdBFMWHNiTxtxJ85LtpAhlNYv6+1LVGSDD+7Q8mIMaZfujfFSxmDeC5ca7QGN VZGtDVsjlDpRtNzgzsSw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mt7Jz-00FcB6-PM; Fri, 03 Dec 2021 12:05:48 +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 1mt7Iv-00FbmI-32 for linux-arm-kernel@lists.infradead.org; Fri, 03 Dec 2021 12:04:42 +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 BAA281396; Fri, 3 Dec 2021 04:04:39 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.66.214]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CF9613F5A1; Fri, 3 Dec 2021 04:04:37 -0800 (PST) Date: Fri, 3 Dec 2021 12:04:35 +0000 From: Mark Rutland To: Marc Zyngier Cc: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Will Deacon , Hector Martin , Sven Peter , Alyssa Rosenzweig , Rob Herring , Thomas Gleixner , Dougall , kernel-team@android.com Subject: Re: [PATCH v2 8/8] drivers/perf: Add Apple icestorm/firestorm CPU PMU driver Message-ID: References: <20211201134909.390490-1-maz@kernel.org> <20211201134909.390490-9-maz@kernel.org> <877dcnm2wt.wl-maz@kernel.org> <875ys6lype.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <875ys6lype.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211203_040441_233033_38C68C6B X-CRM114-Status: GOOD ( 20.10 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Dec 03, 2021 at 11:22:53AM +0000, Marc Zyngier wrote: > On Thu, 02 Dec 2021 16:14:01 +0000, Mark Rutland wrote: > > On Thu, Dec 02, 2021 at 03:39:46PM +0000, Marc Zyngier wrote: > > > On Wed, 01 Dec 2021 16:58:10 +0000, Mark Rutland wrote: > > > > On Wed, Dec 01, 2021 at 01:49:09PM +0000, Marc Zyngier wrote: > > > > > + state = read_sysreg_s(SYS_IMP_APL_PMCR0_EL1); > > > > > + overflow = read_sysreg_s(SYS_IMP_APL_PMSR_EL1); > > > > > > > > I assume the overflow behaviour is free-running rather than stopping? > > > > > > Configurable, apparently. At the moment, I set it to stop on overflow. > > > Happy to change the behaviour though. > > > > The architected PMU continues counting upon overflow (which prevents > > losing counts around the overlflow occurring), so I'd prefer that. > > > > Is that behaviour per-counter, or for the PMU as a whole? > > It is global. This will probably require some additional rework to > clear bit 47 in overflowing counters, which we can't do atomically. Ah; I see. To calrify my comment above, the reason for wanting the counter to keep counting is to count during the window between the IRQ being asserted and the PMU IRQ handler being invoked, and it's fine for there to be a blackout period *within* the PMU IRQ handler. So for example it would be fine to have: irq_handler() { if (!any_counter_overflowed()) return IRQ_NONE; stop_all_counters(); for_each_counter(c) { handle_counter(c); } start_all_counters(); return IRQ_HANDLED; } ... and I think with that the regular per-counter period reprogramming would do the right thing? Really, all the PMU drivers should do that so that repgoramming is consistent and we don't get skewed groups. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel