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=-9.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,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 7E7BDC2D0E2 for ; Tue, 22 Sep 2020 11:15:40 +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 CB14020B1F for ; Tue, 22 Sep 2020 11:15:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="wyv0J6Z4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CB14020B1F 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=kLdLuBXZhHsHw6uHOfX5A4x8AR3A8synLShYDXJQl5s=; b=wyv0J6Z4KT77fadGzj76KxMjy mshbHBB/0p3waOOGAm9Pd78puAfcfehKpUmDm0DhYncbOLFH12WhuYjECVDLXSp4HV8Vz6YmBpfBI gI11M0faX2nd/KNfVOSgGFZsxWZfUfjUyZ3crnku8Fwe9c/TOiWwYPXa14dGVl2X+ii0W/qyQilHA X6CBYa1mo2FsJX1mvQVLgb/jZTOi4239RDsBKZ/6i0dxNQRO6b5JbhRPhX3yPocYB1VSWt+CTt3YZ /Nqa5eMDVqJFt+6RXVnJfbWxucWktv1gKT+zE5NS8gDJ3aSIS5GxW4jISu8Qoshuc87BYBXI3MXAO lxTaRiFtQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kKgFC-0004Lb-HR; Tue, 22 Sep 2020 11:13:58 +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 1kKgF8-0004LE-2N for linux-arm-kernel@lists.infradead.org; Tue, 22 Sep 2020 11:13:56 +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 65DB2113E; Tue, 22 Sep 2020 04:13:52 -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 182423F70D; Tue, 22 Sep 2020 04:13:50 -0700 (PDT) Subject: Re: [PATCH 15/19] coresight: etm4x: Use TRCDEVARCH for component discovery To: mike.leach@linaro.org References: <20200911084119.1080694-1-suzuki.poulose@arm.com> <20200911084119.1080694-16-suzuki.poulose@arm.com> From: Suzuki K Poulose Message-ID: <7b0c27e5-6391-b8d2-fcdb-97cb26bc398b@arm.com> Date: Tue, 22 Sep 2020 12:18:29 +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_071355_459123_754012F6 X-CRM114-Status: GOOD ( 25.41 ) 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: >> >> We have been using TRCIDR1 for detecting the ETM version. As >> we are about to discover the trace unit on a CPU, let us use a >> CoreSight architected register, instead of an ETM architected >> register for accurate detection on a CPU. e.g, a CPU might >> implement a custom trace unit, not an ETM. >> >> Signed-off-by: Suzuki K Poulose >> static int etm4_cpu_id(struct coresight_device *csdev) >> { >> struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent); >> @@ -694,10 +693,23 @@ static void etm_detect_lock_status(struct etmv4_drvdata *drvdata, >> drvdata->os_lock_model = TRCOSLSR_OSM(os_lsr); >> } >> >> +static inline bool trace_unit_supported(u32 devarch) >> +{ >> + return (devarch & ETM_DEVARCH_ID_MASK) == ETM_DEVARCH_ETMv4x_ARCH; >> +} >> + > > This is fine for system reg access - but imposes additional > constraints on memory mapped devices that previously may have worked > just by matching CID/PID. Can you be certain there are no devices out > there that have omitted this register (it does have a present bit > after all) Very good point and I agree. I could restrict this to system instruction based devices and use the TRCIDR1 for > >> static bool etm_init_iomem_access(struct etmv4_drvdata *drvdata, >> struct csdev_access *csa) >> { >> + u32 devarch; >> + >> + devarch = readl_relaxed(drvdata->base + TRCDEVARCH); >> + if (!trace_unit_supported(devarch)) >> + return false; >> + >> *csa = CSDEV_ACCESS_IOMEM(drvdata->base); >> + drvdata->arch = devarch; >> + >> return true; >> } >> >> @@ -713,7 +725,6 @@ static bool etm_init_csdev_access(struct etmv4_drvdata *drvdata, >> static void etm4_init_arch_data(void *info) > > The primary task of this routine is to read all the ID registers and > set up the data in regards to resources etc. > We should not be mixing in a secondary task of detection of a valid device. I agree that we have to read up the registers. However, for system instructions based devices, we shouldn't try to access random register space, if they are not ETM. Moreover, it kind of simplifies the logic, where you don't have to read up all the registers if this is not a supported device in the first place. Or the other way around, I think the priority is to make sure we are dealing with a valid device we support, before we tread into reading the register space to avoid unknown side effects of the operations. Thanks Suzuki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel