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=-4.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 32B88C4338F for ; Mon, 2 Aug 2021 12:50:18 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id E09F860F55 for ; Mon, 2 Aug 2021 12:50:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E09F860F55 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4snD5v6CfN72KcnaW/pPptWR5kswacK/IXE22InGl9Q=; b=GoBIrMufyA/cFl 7Xlf7TtHw9L6ZaVDJqEX+jt39uPmCIAaF1AjxsVNCwYeHWJZIfuqXAqWl0bFveOGFuryAM2J+E8U+ TUL/2+efmWd3717Sd4R55Bw/q4fex521v9eZSnqhT7Xfp+/RhdXLAfiSsG8IoKNoDtgffDmLf+3+a i1ASxKZ4kpObeQ9rcJIrCWWPwn5yx4Bvttbb/xNSeIw3uHtTEmGRz+d8wi6cnwF1805coPPCb2bBH P4l7VHAvOkQrFqGD6p9pjnuy5dkC/26XxN/i6tGelJdKyM9xTqk70CHngZJ7nADuKDz0giVeZymh6 i4jnPBceuve9SqYQ1vlw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mAXMq-00GGBI-3P; Mon, 02 Aug 2021 12:48:28 +0000 Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mAXMm-00GGAL-GV for linux-arm-kernel@lists.infradead.org; Mon, 02 Aug 2021 12:48:26 +0000 Received: by mail-wm1-x32d.google.com with SMTP id l4-20020a05600c1d04b02902506f89ad2dso11490644wms.1 for ; Mon, 02 Aug 2021 05:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VKO11xsjor8r4pTLuSQbHnxU20k9vn9Taln/7g7m6Zw=; b=hb8n4SuM+gu0M2h9LExOU03wp4PUoMWWRa+qt3mjhGTaDa+Hy6REkHW0Z399LvgjQi ZsXDRmSr8Nbs/+JMibOrSVEGQrQ8lMdsyRhsKJ7A6t+StKAYUmtdZf8xq14EOID4GV4b G9cZ8Bxyae8oXAoGJIaydxpDfc0vZ+OpcVMbQksN14KWb5VNj2kjDR8RXlNw41Fzuzve uqEW6+lVJaSWpYRf5rdFoVmmg9INircKqa81u4dbbayqeCOuiEgb2m13v94heOudkRnE nj3ux7Ia+/sn/wCYFGpWv9rV/07cIZhmLGUp9vnhQJCB0v30QAugw9qQ2EUrBxMGx4Re ZYTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VKO11xsjor8r4pTLuSQbHnxU20k9vn9Taln/7g7m6Zw=; b=s//fgFdjAKn/HH5h1z+T7/uO1v3C/R54y8ek60mnk50jEl6KfW04LEP8au5k1xFnPv gi1mXvGk4ThJAS2ymhtuLV6zQjUAHsSfh9DxzCytx8MDCR2yhA9+fF1Xep+yUYbp5UyW ue0uQnok+b4FpQPsyibau6QRKFrslOJADQg9fi0ENvElCqDJF1FzVgLGypmuWdTbuALG 12RWD4QElQrTso2f4Xqj+/S2GCjK0/OUePIBi993PXEMUKnXzJRw/Mjf0VLw2JsEaD7L 4U13Pyg3HTXESdimNHtdwSGmJAe9dtWNxZhTxMzIFIZtS7C/rlCrgPokYQ77v2szDMc+ zzmA== X-Gm-Message-State: AOAM533xvlBvKrA8kxidUoVg777YaiQbr6T1gZ2F+9dXu0RJZEH/kpM0 AaTv0f2c9e0+NIGZfxo9RJNxOpSDYbfnYo6M7UNi/g== X-Google-Smtp-Source: ABdhPJxlnx05eCshGODl7C718NCFPREwOuEZ3qujJdnK+0XbqWzHiOeDNCIiqfMR/bixn70mBq1vitNkK7o9qGsV/y8= X-Received: by 2002:a05:600c:4fd1:: with SMTP id o17mr13207741wmq.131.1627908502651; Mon, 02 Aug 2021 05:48:22 -0700 (PDT) MIME-Version: 1.0 References: <20210721090706.21523-1-james.clark@arm.com> <20210721090706.21523-4-james.clark@arm.com> <20210731074343.GG7437@leoy-ThinkPad-X240s> <20210802120545.GJ7437@leoy-ThinkPad-X240s> In-Reply-To: <20210802120545.GJ7437@leoy-ThinkPad-X240s> From: Mike Leach Date: Mon, 2 Aug 2021 13:48:12 +0100 Message-ID: Subject: Re: [PATCH 3/6] perf cs-etm: Save TRCDEVARCH register To: Leo Yan Cc: James Clark , Arnaldo Carvalho de Melo , Mathieu Poirier , Coresight ML , Al Grant , "Suzuki K. Poulose" , Anshuman Khandual , John Garry , Will Deacon , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , linux-arm-kernel , Linux Kernel Mailing List , linux-perf-users@vger.kernel.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210802_054824_602959_D83370E5 X-CRM114-Status: GOOD ( 42.36 ) 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 Hi Leo, On Mon, 2 Aug 2021 at 13:05, Leo Yan wrote: > > Hi Mike, > > On Mon, Aug 02, 2021 at 12:21:31PM +0100, Mike Leach wrote: > > [...] > > > > Here I think the right thing to do is to support newer revisions for > > > ETMv4, and then based on the revision it creates a decoder with > > > supporting ETE feature. For a more neat solution, if the perf tool > > > passes the "correct" revision number to the OpenCSD decoder, it should > > > can decode trace data with ETE packets. In this way, the ETE decoding > > > can be transparent for perf cs-etm code. > > > > > > > The OpenCSD decoder separates the ETMv4 decoder from the ETE decoder - > > for the reasons given above. > > Thanks for explanation. > > > Additionally the ETE decoder and the ETMv4 decoder required different > > sets of ID registers to correctly set up the decoder. For example, > > for ETMv4 the version is extracted form TRCIDR1, for ETE the version > > in TRCIDR1 is set 0xFF, and thus needs TRCDEVARCH to extract the > > revision. It is likely that later updates to ETE will require an > > additional TRCIDR register to be saved. > > Okay, for ETMv4.x and ETE, finally I think we need to rely on TRCDEVARCH to > decide the tracer version based on the architecture number (arch 4 or 5) > and revision number. > > > Choosing the base type of decoder in this way is how the library can > > support ETMv3, EMTv4, ETE, STM, PTM etc - and while some of those > > protocols use TRCIDR1 and TRCDEVARCH - not all do. > > > > It would in theory be possible to have the OpenCSD library > > "autodetect" the type of decoder needed based purely on a set of ID > > registers. But this set of ID registers would be far larger than the > > ones currently used, and would require modifcation to a lot of the > > existing device drivers to ensure they were accessible via sysfs. This > > register set includes the ID registers that are currently used to > > identify the component on the AMBA bus and match to the correct > > driver, plus additional CoreSight management registers. This would > > also create a dependency between decoder creation and ID numbers - in > > the same way that each new ETM4.x part number has to be added to the > > ETM4.x device driver. > > > > Such a system would require a significant update to the OpenCSD > > infrastructure, and is not planned at this time. > > It's fine for me not introducing significant change in OpenCSD. > > If so, I understand your suggestion in another email to add a new magic > number and a new protocol (this patch set has added the new protocol > CS_ETM_PROTO_ETE) for creating ETE decoder. > > Just confirm one thing which is a bit confused me: for ETMv4.5 or any > newer ETM IPs, should the perf tool keep the existed way to create the > ETMv4 decoder? Or there have updating is required for decoder to > support the extended packets? > Where the trace device is identified as an ETMv4.x, then perf will continue to create an ETMv4.x decoder as it does now. The OpenCSD ETM4.x decoder will track any needed updates for the ETM4.x series. Only where the trace device is ETE, there will be the new magic number and different ID registers be used - so the call to OpenCSD will request an ETE decoder to be created. The register value structures supplied to OpenCSD on decoder creation, differ between ETM4.x and ETE. Regards Mike > Thanks, > Leo -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel