From patchwork Thu Apr 6 14:49:15 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Robin Murphy X-Patchwork-Id: 13203596 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 D8B28C76196 for ; Thu, 6 Apr 2023 14:50:23 +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:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=29B3Mn60/vL1x0sBrwDezMNYwY5I1EFFhiYHJviHfCg=; b=EV0cELml1/afAi 1A3fBnncExE2X8UDjfx3sZEl8eZ7kY/mCw2DAM+whPjMEQ/SLU7EtMEAOnYDI+9JUxCRVbfFTat/T kRKkik6W2R4ZhLFhhz6ZeUnqhOO9yszorDpgOURO0+XhGNK8aUkwt560CpVZ16RTkLdWpcWyQEJvz m9ImuKTdPpKMv3hOGh5AB0C3WTr0oewzI62glsjzRbBz0Vpnf/fCy7xetQWQU4e+JdQtvF6ZJd9Ca pMRpVgdr9EOcOyu9PEdwZldshmIOIbPCT4PJQnn1nPP7NJxGn2XPg0jHL/YM1ZotV36m3P5EIyjAq mPubbxfjL4PGXOkRx0Uw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pkQvi-007hMX-36; Thu, 06 Apr 2023 14:49:38 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pkQve-007hLT-36 for linux-arm-kernel@lists.infradead.org; Thu, 06 Apr 2023 14:49:37 +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 C57BC106F; Thu, 6 Apr 2023 07:50:15 -0700 (PDT) Received: from e121345-lin.cambridge.arm.com (e121345-lin.cambridge.arm.com [10.1.196.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id B18EE3F762; Thu, 6 Apr 2023 07:49:30 -0700 (PDT) From: Robin Murphy To: will@kernel.org Cc: mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, ilkka@os.amperecomputing.com, Geoff Blake Subject: [PATCH] perf/arm-cmn: Fix DTC reset Date: Thu, 6 Apr 2023 15:49:15 +0100 Message-Id: X-Mailer: git-send-email 2.39.2.101.g768bb238c484.dirty MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230406_074935_068586_D8FC4D67 X-CRM114-Status: GOOD ( 14.63 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org It turns out that my naive DTC reset logic fails to work as intended, since clearing PMCR.PMU_EN appears to result in writes to PMOVSR_CLR being ignored, while some hard-to-characterise combination of conditions (differently between DTC0 and secondary DTCs) also appears to result in PMOVSR reading as zero even when an overflow remains asserted. Thus rather than resetting the PMU to a nice clean state, we can currently end up with screaming spurious interrupts from secondary DTCs which we can neither see nor clear. This behaviour is of course not documented. Resetting PMCR to disable the interrupt output but enable the PMU itself seems to at least make the PMOVSR_CLR write work as expected on DTC0 (although it looks like writing to PMCR twice has actually been having some hidden side-effect of clearing any pending overflows there). Unfortunately this still does not seem to help secondary DTCs, but going beyond PMU scope and additionally resetting DTC_CTL does seems to make everything work out, and superficially looks sensible. Therefore pile that onto the house of empirical cards too, until I can check with the hardware team whether there's actually any proper recommended way of recovering from an arbitrary PMU state after an oops/kexec/whatever. Fixes: 0ba64770a2f2 ("perf: Add Arm CMN-600 PMU driver") Reported-by: Geoff Blake Signed-off-by: Robin Murphy --- This supersedes the previous shutdown/IRQ patches, now that I've finally managed to make *some* sense of what's really going on. If anyone's interested, this is the contrivance I used for testing: https://gitlab.arm.com/linux-arm/linux-rm/-/commit/d8f1035c5bc510516d6e4f0b7bf0b875a749daf7 --- drivers/perf/arm-cmn.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c index 144cc08d9e04..81fe01171e33 100644 --- a/drivers/perf/arm-cmn.c +++ b/drivers/perf/arm-cmn.c @@ -1899,7 +1899,10 @@ static int arm_cmn_init_dtc(struct arm_cmn *cmn, struct arm_cmn_node *dn, int id if (dtc->irq < 0) return dtc->irq; - writel_relaxed(0, dtc->base + CMN_DT_PMCR); + if (idx == 0) + writel_relaxed(0, dtc->base + CMN_DT_DTC_CTL); + + writel_relaxed(CMN_DT_PMCR_PMU_EN, dtc->base + CMN_DT_PMCR); writel_relaxed(0x1ff, dtc->base + CMN_DT_PMOVSR_CLR); writel_relaxed(CMN_DT_PMCR_OVFL_INTR_EN, dtc->base + CMN_DT_PMCR);