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 X-Spam-Level: X-Spam-Status: No, score=-12.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 53692C2D0E2 for ; Tue, 22 Sep 2020 11:56:14 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AE0602075E for ; Tue, 22 Sep 2020 11:56:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="UfQD03pc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AE0602075E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=GW8FmTIH7lp1aZB5hS+XgUdgl0ldzaRakCR9y4XEyUA=; b=UfQD03pcWDHOH0OgF6fpLCexv xleSe+G+9Z622Zb4OBSvu34Uh72P/3CznSxvTy0/bwN02otv4cRiMnPguuu1kJeqpHY9g87b4XxvS JNnrSlIE0rWb9p2dLc5PPyutDkG7VIhBz4UBqAX3Y6G3B9HtDPcemWaR39dtDCp8X5ITRpFlaihre NsTf2oDvOCxJARdengi4+e/chK1S2CoZhYWSMJgTX4BgsgpyI7sXBlXFbUu3qxHIlrok0NWLzryEj Uz+ERGZ6BjqeiICSiFFWQWIN1k7kYL1GyNbd4eBbIlXC1Yn4u4tdeAS2MV+2DHnfKeJwsCWtZQp6g IpUK7AVdg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kKgsW-0001J5-3n; Tue, 22 Sep 2020 11:54:36 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kKgsT-0001Ij-A2 for linux-arm-kernel@lists.infradead.org; Tue, 22 Sep 2020 11:54:34 +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 6CFFB113E; Tue, 22 Sep 2020 04:54:32 -0700 (PDT) Received: from [10.57.51.251] (unknown [10.57.51.251]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6555B3F73B; Tue, 22 Sep 2020 04:54:31 -0700 (PDT) Subject: Re: [PATCH 16/19] coresight: etm4x: Detect system instructions support To: mike.leach@linaro.org References: <20200911084119.1080694-1-suzuki.poulose@arm.com> <20200911084119.1080694-17-suzuki.poulose@arm.com> From: Suzuki K Poulose Message-ID: Date: Tue, 22 Sep 2020 12:59:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200922_075433_488285_A06D8C72 X-CRM114-Status: GOOD ( 27.86 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: coresight@lists.linaro.org, anshuman.khandual@arm.com, mathieu.poirier@linaro.org, linux-arm-kernel@lists.infradead.org, leo.yan@linaro.org 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 09/18/2020 04:35 PM, Mike Leach wrote: > Hi Suzuki, > > On Fri, 11 Sep 2020 at 09:41, Suzuki K Poulose wrote: >> >> ETM v4.4 onwards adds support for system instruction access >> to the ETM. Detect the support on an ETM and switch to using the >> mode when available. >> >> Signed-off-by: Suzuki K Poulose >> --- >> drivers/hwtracing/coresight/coresight-etm4x.c | 31 +++++++++++++++++++ >> 1 file changed, 31 insertions(+) >> >> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c >> index 0fce9fb12cff..dc5ac171db35 100644 >> --- a/drivers/hwtracing/coresight/coresight-etm4x.c >> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c >> @@ -693,11 +693,39 @@ static void etm_detect_lock_status(struct etmv4_drvdata *drvdata, >> drvdata->os_lock_model = TRCOSLSR_OSM(os_lsr); >> } >> >> +static inline bool cpu_supports_sysreg_trace(void) >> +{ >> + u64 dfr0 = read_sysreg_s(SYS_ID_AA64DFR0_EL1); >> + >> + return ((dfr0 >> ID_AA64DFR0_TRACEVER_SHIFT) & 0xfUL) > 0; >> +} >> + > > This will be an issue if you have an aarch32 device (eg Cortex-A32 or > similar, with ETM support but no aarch64) Agreed and in fact this was part of the header file in my initial versions. I could move it back there. However, the ETM4x even without this series doesn't support aarch32. The compilation would fail for various reasons (e.g, readq()). > >> static inline bool trace_unit_supported(u32 devarch) >> { >> return (devarch & ETM_DEVARCH_ID_MASK) == ETM_DEVARCH_ETMv4x_ARCH; >> } >> >> +static bool etm_init_sysreg_access(struct etmv4_drvdata *drvdata, >> + struct csdev_access *csa) >> +{ >> + u32 devarch; >> + >> + if (!cpu_supports_sysreg_trace()) >> + return false; >> + >> + devarch = read_etm4x_sysreg_const_offset(TRCDEVARCH); >> + if (!trace_unit_supported(devarch)) >> + return false; >> + *csa = (struct csdev_access) { >> + .io_mem = false, >> + .read = etm4x_sysreg_read, >> + .write = etm4x_sysreg_write, >> + }; >> + >> + drvdata->arch = devarch; >> + return true; >> +} >> + >> static bool etm_init_iomem_access(struct etmv4_drvdata *drvdata, >> struct csdev_access *csa) >> { >> @@ -716,6 +744,9 @@ static bool etm_init_iomem_access(struct etmv4_drvdata *drvdata, >> static bool etm_init_csdev_access(struct etmv4_drvdata *drvdata, >> struct csdev_access *csa) >> { >> + if (etm_init_sysreg_access(drvdata, csa)) >> + > > Don't think we should enforce system instruction access if the device > tree has defined memory access. The driver cannot possibly know if > this is a mistake or deliberate (e.g. test / implementation bug fix).> > + return true; Agreed, will fix it. > >> if (drvdata->base) >> return etm_init_iomem_access(drvdata, csa); >> >> -- >> 2.24.1 >> > > The device tree bindings define the access support intended - and > there is access specific probing. i.e. the next patch splits amba (mem > access) / platform (sys access) driver probes, followed by the common > probe section. The register / memory access support used should be > made there, and the detection of a compatible device for the register > access i.e. check TRCDEVARCH should be in the platform probe path too > - possibly simplifying things and ensuring the common code changes are > reduced. I will address this in the next version. I believe we could work around the problem of missing TRCDEVARCH on older platforms. Thanks a lot for the review ! Suzuki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel