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 839B4C4338F for ; Mon, 2 Aug 2021 11:23:55 +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 3F1AC60FC4 for ; Mon, 2 Aug 2021 11:23:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3F1AC60FC4 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=G2Zof84KfCcgxrsgeful/uKP+U2dTd/vHeG8vsk1v7Q=; b=ssYXspoYQQNJwh QOvAsH6U+qigPxt4GcsqwulQwOpZOi88YQ7A39nuAzo6uZn6/SK2vjB7hG4OD9HDMSK3WVL8IswLj h4sU5wiH2inp/FdVorJMUyuxqmLyVNy74PjmfFUWUPdYwm2GbyDcgkf7CzhoVKREhhvxLL4q9748W 1IKBL+2fQ49fv5x0ouWS30pZmdAC0VsvBWqIMTKxNDJo0PLsMH02B/En+Nj0Uhl7xWuwYjGtR/uW4 20Fk9YyCrm5gm437Rao2O24ZT0qBH3qrCUTHrG5CBYJQn12tJoRir1ZFEPG8P6d5dPYZD6b5MyHwg phxGMcUImkNt85N1eKcA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mAW16-00Fu1n-HX; Mon, 02 Aug 2021 11:21:56 +0000 Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mAW0w-00FtzF-BO for linux-arm-kernel@lists.infradead.org; Mon, 02 Aug 2021 11:21:47 +0000 Received: by mail-wr1-x429.google.com with SMTP id k4so10227422wrc.0 for ; Mon, 02 Aug 2021 04:21:43 -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=G/koorird9RI6rxHcMKGWVC8FpqcPw2Bxqajxw8KAm4=; b=aiZNE3gCayt228fGCrHvqWoMztXke8LpVWO1FnIygBy/abbs828QBj+IZEAUyXO1RI Jm9JuLsbnNsV3CeKbZKE3u2fpsHLWDcB5GriZExIbtLRnn5yx1H+CejY+Tszn3K1jFl+ 2oIhUVVfjNXKm7l2u6UWTLSOvFnoMk9b2sh9S6Jf7tXzLWuHgMav6vYww9Fb0Yl0piIq KPLvyAg4X715tfC3kuA8KSOVhNhA4pFBHeEwgcggXr2RHaUcnLCmlCMMvtkAU8ShqMus 5c5kc8xsTCP3YMQGPqlaCfgPENZM7vSl2noQezCY99cSzsgB6tsXNxCKCpoAd5BXn0Uu c0bw== 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=G/koorird9RI6rxHcMKGWVC8FpqcPw2Bxqajxw8KAm4=; b=owujsQ+hnkEKRLWlftUEW5dG4Z5YPW9BcVdlf8UjwGf+rOlZF1QzODWvMvthry0Ubc zZt3DLqDRfIIT+unN4hQTnNxarz0aA78yVV8v6OjeNVhxYf4oVAAtIoolMZ+nAMhmOFj gbmjC5tsVclZ0wyieZM/RZk/uS8hl6jfi0MYCFX1ozCp0T6xxyp5jbaMRgr2qnGX+E7q +aFjHgzuOWWnfb5vBMl7IpFImSCZchmw6KOyjX77ljIhvem8ptYDL1l8PJdlA/tmLTbn VTRwyO+t8zJjDpDJzEtcRsUJE0xqsGwWlFP1AvIbkfDqP2TYPHJ2Ma/ErctLDrBnKlFE HVyw== X-Gm-Message-State: AOAM5334GkUlaxL0tV6Et3rpAsiGkdxfaGNsuJVzVN8XbMpCNtXwIR61 qmdXFIQ+ONhHUYtXrswpX6eGP/aQ7GAPRgqxTO+sBg== X-Google-Smtp-Source: ABdhPJw+wl63y5y5TpELUycesptAk3jPx8BJVJfGvYIoyZ5V7Va5STE7ZNvQjhlWpic5NsH+ZoKNK3nykh2tfhfC0CM= X-Received: by 2002:a5d:67c4:: with SMTP id n4mr16475048wrw.176.1627903302730; Mon, 02 Aug 2021 04:21:42 -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> In-Reply-To: <20210731074343.GG7437@leoy-ThinkPad-X240s> From: Mike Leach Date: Mon, 2 Aug 2021 12:21:31 +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_042146_478744_2126E026 X-CRM114-Status: GOOD ( 33.19 ) 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 Sat, 31 Jul 2021 at 08:43, Leo Yan wrote: > > On Wed, Jul 21, 2021 at 10:07:02AM +0100, James Clark wrote: > > Now that the metadata has a length field we can add extra registers > > without breaking any previous versions of perf. > > > > Save the TRCDEVARCH register so that it can be used to configure the ETE > > decoder in the next commit. If the sysfs file doesn't exist then 0 will > > be saved which is an impossible register value and can also be used to > > signify that the file couldn't be read. > > After reviewed the whole patch set, come back to highlight one thing: > seems to me ETE is only a feature introduced by new ETMv4 revisions; in > other words, if we support ETMv4.5 or any later revisions, it will > support ETE feature. > The ETE hardware and trace protocol is introduced to support new architectural features in the PE - principally those associated with v9 architecture and beyond. It has has additional packet types that will never appear in any ETM4.x trace sequence. ETE (and TRBE) are defined as architectural features of the PE - i.e. FEAT_ETE and FEAT_TRBE read from feature registers on the core. You are correct in saying that some features in ETM v4.x beyond ETM 4.5 will also appear in ETE, but the reverse is not true - ETE is a superset of ETMv4. > 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. 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. 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. Regards Mike > How about you think for this? Sorry if I introduce noise due to my > lack knowledge (and platform) for ETE. > > 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