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=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 AD603C433DB for ; Fri, 12 Feb 2021 17:32:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7103F64E77 for ; Fri, 12 Feb 2021 17:32:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231324AbhBLRb7 (ORCPT ); Fri, 12 Feb 2021 12:31:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231759AbhBLRbW (ORCPT ); Fri, 12 Feb 2021 12:31:22 -0500 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1EADC0613D6 for ; Fri, 12 Feb 2021 09:30:42 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id u16so329921wmq.1 for ; Fri, 12 Feb 2021 09:30:42 -0800 (PST) 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=m26TZ2tJuGxHBQo60qfAvVdy7loPGID74+UtZKlfkOg=; b=Qfnmud5g3lCzCePjlJrPbZtUmeeJR8MxWC9cXk14YQdskS8dsXWY1w17KCQwnHc2Hz jZnbB1OkLK36/68EMpyLPCv5iF9m33zhbWAzTf1v6wo9eZy2lzEcctCtrrkt53I91zNc eD9Y1Wd0etCGfEs/pZDzNcwvPMyIcbJlm38GWbg6dTxu2yILiMp1OybumgoJT7DvIRgV 23zhen8nr6Rm/qHhVoX9yMTKK95WY8VX0YlQ2kOeYlnTSBhZtcWeIhqwpzksoF4dtceo CBaX+sWlRpdCrInLYacJnotHP4cUDsGlqwqY+joMmnZJcvfyXAIwJfx6DO8nnVg4vIyv 6/RQ== 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=m26TZ2tJuGxHBQo60qfAvVdy7loPGID74+UtZKlfkOg=; b=XmcZ5RQprE4r0purvHDOwOqMxwQ5Wds0dbB04Ms5/3B/M8BjRABiPTItTGe0rqySXR X5n+F+xYqiPMfUrEhXa50czeRHEC82fttEcUr1Gh+1uGhzOsw7A/WKqvWw/jMf8XeD0r hy/UXu+SRbu/i13lSzlMUsUaXFcD7YsOu9gNv8DrKM71oe+VcBsB5CBeF8gW/SX7H8cq IP1Lawja8LOzNo8HDC5YiXsc0UXnW7z9wo6ByDHSFE+JK81z7N1zWE7bVGfLn4rrbkNd ON6E07+yEoXErOud6rxq57pxvAxPo6pQHnC93qPNn7PKOAxmMVBNBhJ/ViiVcm0jw6KO JLLg== X-Gm-Message-State: AOAM532U4DAbZlDchqipAW97rRz3g9cJZISdjYJpVQjNLNmVFY31lboc pMgQE66XsD+fmyUzz8kRsk/JKo59K2fBoKjH0asWsw== X-Google-Smtp-Source: ABdhPJy52YXbmOf00JWxlF3hemo/oj+rIHdEoWUO9Pr70Gx3wPY4oq9ObryiZJyNQPBO2ODs9Ho/MP/A9bIPQzCvgJc= X-Received: by 2002:a7b:c952:: with SMTP id i18mr3177294wml.5.1613151041500; Fri, 12 Feb 2021 09:30:41 -0800 (PST) MIME-Version: 1.0 References: <20210110224850.1880240-1-suzuki.poulose@arm.com> <20210110224850.1880240-29-suzuki.poulose@arm.com> <72f85de4-5b39-c963-78cf-2f8347e21268@arm.com> In-Reply-To: <72f85de4-5b39-c963-78cf-2f8347e21268@arm.com> From: Mike Leach Date: Fri, 12 Feb 2021 17:30:30 +0000 Message-ID: Subject: Re: [PATCH v7 28/28] coresight: Add support for v8.4 SelfHosted tracing To: Suzuki K Poulose Cc: linux-arm-kernel , Coresight ML , Mathieu Poirier , Anshuman Khandual , Leo Yan , Linux Kernel Mailing List , Jonathan Zhou , Catalin Marinas , Will Deacon Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Suzuki, On Fri, 12 Feb 2021 at 15:36, Suzuki K Poulose wrote: > > Hi Mike > > On 2/12/21 10:34 AM, Mike Leach wrote: > > Hi Mathieu, Suzuki, > > > > Sorry for the really late response on this patch, but I noticed a > > problem while doing a review of the ETE / TRBE set. (TRBE specs > > mention TRFCR_ELx, so I was confirming a couple of things). > > > > On Sun, 10 Jan 2021 at 22:49, Suzuki K Poulose wrote: > >> > >> From: Jonathan Zhou > >> > >> v8.4 tracing extensions added support for trace filtering controlled > >> by TRFCR_ELx. This must be programmed to allow tracing at EL1/EL2 and > >> EL0. The timestamp used is the virtual time. Also enable CONTEXIDR_EL2 > >> tracing if we are running the kernel at EL2. > >> > >> Cc: Catalin Marinas > >> Cc: Mike Leach > >> Cc: Will Deacon > >> Reviewed-by: Mathieu Poirier > >> Signed-off-by: Jonathan Zhou > >> [ Move the trace filtering setup etm_init_arch_data() and > >> clean ups] > >> Signed-off-by: Suzuki K Poulose > >> --- > >> .../coresight/coresight-etm4x-core.c | 25 +++++++++++++++++++ > >> 1 file changed, 25 insertions(+) > >> > >> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c > >> index 3d3165dd09d4..18c1a80abab8 100644 > >> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > >> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > >> @@ -859,6 +859,30 @@ static bool etm4_init_csdev_access(struct etmv4_drvdata *drvdata, > >> return false; > >> } > >> > >> +static void cpu_enable_tracing(void) > >> +{ > >> + u64 dfr0 = read_sysreg(id_aa64dfr0_el1); > >> + u64 trfcr; > >> + > >> + if (!cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_TRACE_FILT_SHIFT)) > >> + return; > >> + > >> + /* > >> + * If the CPU supports v8.4 SelfHosted Tracing, enable > >> + * tracing at the kernel EL and EL0, forcing to use the > >> + * virtual time as the timestamp. > >> + */ > >> + trfcr = (TRFCR_ELx_TS_VIRTUAL | > >> + TRFCR_ELx_ExTRE | > >> + TRFCR_ELx_E0TRE); > >> + > >> + /* If we are running at EL2, allow tracing the CONTEXTIDR_EL2. */ > >> + if (is_kernel_in_hyp_mode()) > >> + trfcr |= TRFCR_EL2_CX; > >> + > > > > This is wrong - CX bit is present on TRFCR_EL2, not TRFCR_EL1. > > Why is this wrong ? We do this only when we are in EL2. > Sorry - must have been looking at an older version of the ARMARM when I looked for EL1 registers that are aliased to EL2. So this does indeed work! > > Moreover, TRFCR_EL2 has a separate enables for tracing at EL0 and EL2. > > > > True, that is for EL0&2 translation regimes. i.e, tracing EL0 with > the kernel running at EL2. But bits TRFCR_EL2.E2TRE == TRFCR_EL1.E1TRE > If notice, we name the bit TRFCR_ELx_ExTRE. And E0TRE == E0HTRE. > > So we do the following : > > 1) When kernel running at EL2: > Enable tracing at EL2 and EL0 and context tracking > 2) When kernel running at EL1: > Enable tracing at EL1 and EL0. > > > > Secondly - is this correct in principal? Should the driver not be > > reading the access it is permitted by the kernel, rather than giving > > itself unfettered access to trace where it wants to. > > I dont follow the "access permitted by the kernel" here. What are we referrring to ? > By that I mean that as I suggest below this should be controlled by what we could call the hypervisor, rather than a driver. > > Surely TRFCR_ELx levels should be chosen in KConfig and then should > > be set up in kernel initialisation? > > I disagree with yet another Kconfig. This basic requirement for > enabling the trace collection. It is not something that we can optionally > use from the architecture. So we should transparently do the right > thing for making sure that we set up the system for something that > didn't require any other steps. Or in other words, if we add a Kconfig > option for TRFCR programming, if someone forgets to select it > when they upgraded the kernel they are in for a surprisingly long > debugging to find why the trace doesnt work. > > As for the TRFCR programming, we have two choices. etm4x driver > or generic boot up for the CPU. I preferred to do this in the > driver as we can enable it only if trace drivers are available. > The point is that TRFCR are not part of the controlling registers for the ETE or any trace source device. The architecture manual seems to regard them as being controlled by the hypervisor, rather than the PE trace device. This implies that the control feature is designed to be independent from the trace generation features. I thought they were there to allow virtualisation code to determine what gets traced and what is prohibited, and what view the trace sees of the clock. If you simple switch everything on from the driver and control the ELs traced from the ETE / ETM registers then what are they there for? This solution could be a first pass at this to get trace working, but I think it will have to change in future. Regards Mike > Cheers > Suzuki > > > > > Regards > > > > Mike > > > > > > > >> + write_sysreg_s(trfcr, SYS_TRFCR_EL1); > >> +} > >> + > >> static void etm4_init_arch_data(void *info) > >> { > >> u32 etmidr0; > >> @@ -1044,6 +1068,7 @@ static void etm4_init_arch_data(void *info) > >> /* NUMCNTR, bits[30:28] number of counters available for tracing */ > >> drvdata->nr_cntr = BMVAL(etmidr5, 28, 30); > >> etm4_cs_lock(drvdata, csa); > >> + cpu_enable_tracing(); > >> } > >> > >> static inline u32 etm4_get_victlr_access_type(struct etmv4_config *config) > >> -- > >> 2.24.1 > >> > > > > > > -- > > Mike Leach > > Principal Engineer, ARM Ltd. > > Manchester Design Centre. UK > > > -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK 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=-14.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 3E1EAC433DB for ; Fri, 12 Feb 2021 17:32:00 +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 F2C6464D9C for ; Fri, 12 Feb 2021 17:31:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F2C6464D9C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org 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-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id: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=fVdxai2LVIWIYvayVJKz+PASK5NhuwwjvzwkRBKgSBQ=; b=LKyCnDymXl8JIlRPcCNc1J7CH 7Z5ToaQ+5gRJz/3Syl//ajv6NItdfDWbp1Lc29qDluENt0gZdLzBvbHu2pNVWK8obCj+Z9SIT01fX Syx1R60eg7xM6Iz8W21HJCL2YDAjM2mxIsKL02O1PXXdrps2Y3liAquvXVFkWQT2K5BSXPL3WAzaB Mk2QUP/P0NfeJGTtSe4Lg1HQ9BlDt5fvtEjxk0nkB5CAD5g0lHxCScCw/WMXwBkTWd7chMXeMRjZx hcakN2V2qB/VdVgs4WkYFoe6XTGXWZwZ7H9un3FcbczDPXLJcLhR9laSMgOkwEpGKxJH4JQivisGm IkKEpc8EA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lAcHI-00023w-8m; Fri, 12 Feb 2021 17:30:48 +0000 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lAcHD-00022N-Bm for linux-arm-kernel@lists.infradead.org; Fri, 12 Feb 2021 17:30:44 +0000 Received: by mail-wm1-x330.google.com with SMTP id l17so325921wmq.2 for ; Fri, 12 Feb 2021 09:30:42 -0800 (PST) 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=m26TZ2tJuGxHBQo60qfAvVdy7loPGID74+UtZKlfkOg=; b=Qfnmud5g3lCzCePjlJrPbZtUmeeJR8MxWC9cXk14YQdskS8dsXWY1w17KCQwnHc2Hz jZnbB1OkLK36/68EMpyLPCv5iF9m33zhbWAzTf1v6wo9eZy2lzEcctCtrrkt53I91zNc eD9Y1Wd0etCGfEs/pZDzNcwvPMyIcbJlm38GWbg6dTxu2yILiMp1OybumgoJT7DvIRgV 23zhen8nr6Rm/qHhVoX9yMTKK95WY8VX0YlQ2kOeYlnTSBhZtcWeIhqwpzksoF4dtceo CBaX+sWlRpdCrInLYacJnotHP4cUDsGlqwqY+joMmnZJcvfyXAIwJfx6DO8nnVg4vIyv 6/RQ== 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=m26TZ2tJuGxHBQo60qfAvVdy7loPGID74+UtZKlfkOg=; b=EHcP/d1Lve/t0yKEaTC4admZ33yOsN37ajiu+0cyORJpVFqiM8SwBZaMA9uK8b137L giIHTKEVUMy1YCZR3gdXWUoR1oMqIRkY0i0xHIFaK6/mN6RWMyR1N1zNs1nQLs1jkHSR cVfKEXvBpLsKOSdFQit7pTJjLm73G5hI8k1wX8pz5V74dQsZZshLePKYudjNXCczfm9/ EceC6t6xc6BVTRPKbS2JQfMzgWBsr3Bj994ECdNky2Otw3684/EXfurcPYzKLcDH/ORe 4DMJllwyzQ0oImv5xGgZbCJhnvzzYE+C+cELAY3vs6uelBLvBgKK1aNIqDUq2SDQc23b 0/gA== X-Gm-Message-State: AOAM531PNP0OaPjB1h33nKkEzIZ6QRU8k5Je30rCUpx+3h9xfm/8xWtD Mk1v+TXmkNvJVNacora806p6p+8b6BDsy59UrBtH5Q== X-Google-Smtp-Source: ABdhPJy52YXbmOf00JWxlF3hemo/oj+rIHdEoWUO9Pr70Gx3wPY4oq9ObryiZJyNQPBO2ODs9Ho/MP/A9bIPQzCvgJc= X-Received: by 2002:a7b:c952:: with SMTP id i18mr3177294wml.5.1613151041500; Fri, 12 Feb 2021 09:30:41 -0800 (PST) MIME-Version: 1.0 References: <20210110224850.1880240-1-suzuki.poulose@arm.com> <20210110224850.1880240-29-suzuki.poulose@arm.com> <72f85de4-5b39-c963-78cf-2f8347e21268@arm.com> In-Reply-To: <72f85de4-5b39-c963-78cf-2f8347e21268@arm.com> From: Mike Leach Date: Fri, 12 Feb 2021 17:30:30 +0000 Message-ID: Subject: Re: [PATCH v7 28/28] coresight: Add support for v8.4 SelfHosted tracing To: Suzuki K Poulose X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210212_123043_705692_37C56322 X-CRM114-Status: GOOD ( 46.08 ) 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: Mathieu Poirier , Anshuman Khandual , Catalin Marinas , Coresight ML , Linux Kernel Mailing List , Jonathan Zhou , Leo Yan , Will Deacon , linux-arm-kernel 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 Suzuki, On Fri, 12 Feb 2021 at 15:36, Suzuki K Poulose wrote: > > Hi Mike > > On 2/12/21 10:34 AM, Mike Leach wrote: > > Hi Mathieu, Suzuki, > > > > Sorry for the really late response on this patch, but I noticed a > > problem while doing a review of the ETE / TRBE set. (TRBE specs > > mention TRFCR_ELx, so I was confirming a couple of things). > > > > On Sun, 10 Jan 2021 at 22:49, Suzuki K Poulose wrote: > >> > >> From: Jonathan Zhou > >> > >> v8.4 tracing extensions added support for trace filtering controlled > >> by TRFCR_ELx. This must be programmed to allow tracing at EL1/EL2 and > >> EL0. The timestamp used is the virtual time. Also enable CONTEXIDR_EL2 > >> tracing if we are running the kernel at EL2. > >> > >> Cc: Catalin Marinas > >> Cc: Mike Leach > >> Cc: Will Deacon > >> Reviewed-by: Mathieu Poirier > >> Signed-off-by: Jonathan Zhou > >> [ Move the trace filtering setup etm_init_arch_data() and > >> clean ups] > >> Signed-off-by: Suzuki K Poulose > >> --- > >> .../coresight/coresight-etm4x-core.c | 25 +++++++++++++++++++ > >> 1 file changed, 25 insertions(+) > >> > >> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c > >> index 3d3165dd09d4..18c1a80abab8 100644 > >> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > >> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > >> @@ -859,6 +859,30 @@ static bool etm4_init_csdev_access(struct etmv4_drvdata *drvdata, > >> return false; > >> } > >> > >> +static void cpu_enable_tracing(void) > >> +{ > >> + u64 dfr0 = read_sysreg(id_aa64dfr0_el1); > >> + u64 trfcr; > >> + > >> + if (!cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_TRACE_FILT_SHIFT)) > >> + return; > >> + > >> + /* > >> + * If the CPU supports v8.4 SelfHosted Tracing, enable > >> + * tracing at the kernel EL and EL0, forcing to use the > >> + * virtual time as the timestamp. > >> + */ > >> + trfcr = (TRFCR_ELx_TS_VIRTUAL | > >> + TRFCR_ELx_ExTRE | > >> + TRFCR_ELx_E0TRE); > >> + > >> + /* If we are running at EL2, allow tracing the CONTEXTIDR_EL2. */ > >> + if (is_kernel_in_hyp_mode()) > >> + trfcr |= TRFCR_EL2_CX; > >> + > > > > This is wrong - CX bit is present on TRFCR_EL2, not TRFCR_EL1. > > Why is this wrong ? We do this only when we are in EL2. > Sorry - must have been looking at an older version of the ARMARM when I looked for EL1 registers that are aliased to EL2. So this does indeed work! > > Moreover, TRFCR_EL2 has a separate enables for tracing at EL0 and EL2. > > > > True, that is for EL0&2 translation regimes. i.e, tracing EL0 with > the kernel running at EL2. But bits TRFCR_EL2.E2TRE == TRFCR_EL1.E1TRE > If notice, we name the bit TRFCR_ELx_ExTRE. And E0TRE == E0HTRE. > > So we do the following : > > 1) When kernel running at EL2: > Enable tracing at EL2 and EL0 and context tracking > 2) When kernel running at EL1: > Enable tracing at EL1 and EL0. > > > > Secondly - is this correct in principal? Should the driver not be > > reading the access it is permitted by the kernel, rather than giving > > itself unfettered access to trace where it wants to. > > I dont follow the "access permitted by the kernel" here. What are we referrring to ? > By that I mean that as I suggest below this should be controlled by what we could call the hypervisor, rather than a driver. > > Surely TRFCR_ELx levels should be chosen in KConfig and then should > > be set up in kernel initialisation? > > I disagree with yet another Kconfig. This basic requirement for > enabling the trace collection. It is not something that we can optionally > use from the architecture. So we should transparently do the right > thing for making sure that we set up the system for something that > didn't require any other steps. Or in other words, if we add a Kconfig > option for TRFCR programming, if someone forgets to select it > when they upgraded the kernel they are in for a surprisingly long > debugging to find why the trace doesnt work. > > As for the TRFCR programming, we have two choices. etm4x driver > or generic boot up for the CPU. I preferred to do this in the > driver as we can enable it only if trace drivers are available. > The point is that TRFCR are not part of the controlling registers for the ETE or any trace source device. The architecture manual seems to regard them as being controlled by the hypervisor, rather than the PE trace device. This implies that the control feature is designed to be independent from the trace generation features. I thought they were there to allow virtualisation code to determine what gets traced and what is prohibited, and what view the trace sees of the clock. If you simple switch everything on from the driver and control the ELs traced from the ETE / ETM registers then what are they there for? This solution could be a first pass at this to get trace working, but I think it will have to change in future. Regards Mike > Cheers > Suzuki > > > > > Regards > > > > Mike > > > > > > > >> + write_sysreg_s(trfcr, SYS_TRFCR_EL1); > >> +} > >> + > >> static void etm4_init_arch_data(void *info) > >> { > >> u32 etmidr0; > >> @@ -1044,6 +1068,7 @@ static void etm4_init_arch_data(void *info) > >> /* NUMCNTR, bits[30:28] number of counters available for tracing */ > >> drvdata->nr_cntr = BMVAL(etmidr5, 28, 30); > >> etm4_cs_lock(drvdata, csa); > >> + cpu_enable_tracing(); > >> } > >> > >> static inline u32 etm4_get_victlr_access_type(struct etmv4_config *config) > >> -- > >> 2.24.1 > >> > > > > > > -- > > Mike Leach > > Principal Engineer, ARM Ltd. > > Manchester Design Centre. UK > > > -- 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