Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1574212yba; Tue, 2 Apr 2019 11:26:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqxDnoo7YIZL3uVSb/tb0jY+FnIp19yvboboZpgnnYlaGHFDCILs3tUhpNAX7ZaQRMac4RxO X-Received: by 2002:a65:6107:: with SMTP id z7mr54226229pgu.313.1554229564574; Tue, 02 Apr 2019 11:26:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554229564; cv=none; d=google.com; s=arc-20160816; b=GyU91Co2O3WDXisDGD+LZ5ekolb2CmirkHkLYnyDqtDS/85FAwlZVCUugCSnCs2Hyl KXy76D4tuxGS5o8XwzcJoIDe3craVcv/YA0TW1ufqtX2E7GUKkUz6T9pzSR4mrT5pl1o gKoSvgRIHlUSTfJFhLZifI5rO2UTgK2xLNjX1qqih0nZuic29EMNxHLqjIZko9D1PrU5 Z+T5EK/W+nqZ1helhRyrXT+dKnR2m9qpWBA8Q2ZE8/OsiB4oZosdLJoKOPudmeAXfgdW OZTlCf35Gk77nM6/+v0dkr6V/D3sJvZ3zmVyOJNvkKVr9itAiH+2hAbaKOycHNy0+eM2 GlEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=gPl8UXMO27Kwb35ggb87q7k0WZmTvPXXH0f2/j/wkqQ=; b=SduMSQGxrTeOXY3nzt0/omh8OJXFC6TWmguYZx4fdxY1X2zqV98U1io6Bj+GkRAjwY iUf776faRtNUXCTgmFBy6BluQrcDB55SSIJ1LTovA9ZEMcQHbKXG7MdAWLGhXxTouEqw E7ZYn0DUXWQ3s1RDeTxzUU/GrhYwFYxQXX//yFIbYfNNMDjavUxAVcVuwAk0pDitXKKK vxQoNxKR0PkrbySU63apF4OJBYm4fWG5r2xWxc7x7U6PcfAXXDmB8a6bGBV5uQKXq9p4 fAGidrgs/88q6NhazxLB54j6rrUuaE4HK8tpfZIkXVshAplrHHHhGR/RNbOiiO648qnf RYOw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v3si7287466pga.354.2019.04.02.11.25.49; Tue, 02 Apr 2019 11:26:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731300AbfDBQu6 (ORCPT + 99 others); Tue, 2 Apr 2019 12:50:58 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:54548 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729138AbfDBQu6 (ORCPT ); Tue, 2 Apr 2019 12:50:58 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0A21B80D; Tue, 2 Apr 2019 09:50:58 -0700 (PDT) Received: from fuggles.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A6D303F721; Tue, 2 Apr 2019 09:50:56 -0700 (PDT) Date: Tue, 2 Apr 2019 17:50:54 +0100 From: Will Deacon To: Prasad Sodagudi Cc: mingo@redhat.com, catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, peterz@infradead.org, linux-kernel@vger.kernel.org, mark.rutland@arm.com Subject: Re: [PATCH] perf: Change PMCR write to read-modify-write Message-ID: <20190402165054.GB1442@fuggles.cambridge.arm.com> References: <1553134066-20272-1-git-send-email-psodagud@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1553134066-20272-1-git-send-email-psodagud@codeaurora.org> User-Agent: Mutt/1.11.1+86 (6f28e57d73f2) () Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [+MarkR] On Wed, Mar 20, 2019 at 07:07:46PM -0700, Prasad Sodagudi wrote: > Preserves the bitfields of PMCR_EL0(AArch64) during PMU reset. > Reset routine should write a 1 to PMCR.C and PMCR.P fields only > to reset the counters. Other fields should not be changed > as they could be set before PMU initialization and their > value must be preserved even after reset. > > Signed-off-by: Prasad Sodagudi > --- > arch/arm64/kernel/perf_event.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c > index 4addb38..0c1afdd 100644 > --- a/arch/arm64/kernel/perf_event.c > +++ b/arch/arm64/kernel/perf_event.c > @@ -868,8 +868,8 @@ static void armv8pmu_reset(void *info) > * Initialize & Reset PMNC. Request overflow interrupt for > * 64 bit cycle counter but cheat in armv8pmu_write_counter(). > */ > - armv8pmu_pmcr_write(ARMV8_PMU_PMCR_P | ARMV8_PMU_PMCR_C | > - ARMV8_PMU_PMCR_LC); > + armv8pmu_pmcr_write(armv8pmu_pmcr_read() | ARMV8_PMU_PMCR_P | > + ARMV8_PMU_PMCR_C | ARMV8_PMU_PMCR_LC); No, I don't think this is right at all. Many of these bits are UNKNOWN out of reset, so you're throwing away our means of getting the PMU into a deterministic state. Who is setting which bits that you want to preserve and why? Will