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=-7.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS 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 DEDC7C43381 for ; Tue, 26 Mar 2019 11:51:51 +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 AFB582075D for ; Tue, 26 Mar 2019 11:51:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="UJLANJCk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AFB582075D 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+infradead-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=bombadil.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=LIt3xphOqxTbc8YmbwXWS15PXpc9dK7g1Yf/WT2Tbcg=; b=UJLANJCkfjvsCSdtlUDPAutle eybRqyH1K9ZG3g0oa0o43b9CiKXqVNNQMDKaGm9opi7k7LMSwdjOErVTRsbKK4lezGVw28zQwUK1q alC+kaYroO4EgELgHY01zrsBxHiRKTPCGM7NNOwtbCQ+JHYpGVWcJyLCxtXGYPgqGj6QjWOEZEi/N KAaNEGXLXXcmJ7j6eSIzvAw5dQMximaFoa+9QY3qMAdSmyWM24Hqo+sgYCS6Lrh9l7vKdtBDm173U a+Oejdqz0F2UHGK2lK9Wl6qm7R8GYQjWFY4iQuhYn486evqvF+8hc9u4hmFhvBT6xOYXWO9BAMT0y RGthcBzxQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h8kcI-0002MO-Nj; Tue, 26 Mar 2019 11:51:42 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h8kcC-0002Lu-OM for linux-arm-kernel@lists.infradead.org; Tue, 26 Mar 2019 11:51:39 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D5F641596; Tue, 26 Mar 2019 04:51:33 -0700 (PDT) Received: from [10.37.12.89] (unknown [10.37.12.89]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5A66D3F59C; Tue, 26 Mar 2019 04:51:32 -0700 (PDT) Subject: Re: [PATCH v2 03/16] coresight: etm4x: Configure tracers to emit timestamps To: mathieu.poirier@linaro.org, linux-arm-kernel@lists.infradead.org References: <20190325215632.17013-1-mathieu.poirier@linaro.org> <20190325215632.17013-4-mathieu.poirier@linaro.org> From: Suzuki K Poulose Message-ID: <93c1dffd-285b-a2ac-7eaa-fcb6db16b26a@arm.com> Date: Tue, 26 Mar 2019 11:53:46 +0000 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: <20190325215632.17013-4-mathieu.poirier@linaro.org> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190326_045136_807907_A2A50CAA X-CRM114-Status: GOOD ( 33.01 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alexander.shishkin@linux.intel.com, peterz@infradead.org, coresight@lists.linaro.org, Mike.Leach@arm.com, 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+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 03/25/2019 09:56 PM, Mathieu Poirier wrote: > Configure timestamps to be emitted at regular intervals in the trace > stream to temporally correlate instructions executed on different CPUs. > > Signed-off-by: Mathieu Poirier > --- > drivers/hwtracing/coresight/coresight-etm4x.c | 115 +++++++++++++++++- > 1 file changed, 112 insertions(+), 3 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c > index 732ae12fca9b..45c341a5aa0b 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x.c > @@ -138,8 +138,11 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata) > drvdata->base + TRCCNTVRn(i)); > } > > - /* Resource selector pair 0 is always implemented and reserved */ > - for (i = 0; i < drvdata->nr_resource * 2; i++) > + /* > + * Resource selector pair 0 is always implemented and reserved. As > + * such start at 2. > + */ > + for (i = 2; i < drvdata->nr_resource * 2; i++) > writel_relaxed(config->res_ctrl[i], > drvdata->base + TRCRSCTLRn(i)); To be frank, that looks like a separate fix for the existing driver, from this series. > > @@ -201,6 +204,97 @@ static void etm4_enable_hw_smp_call(void *info) > arg->rc = etm4_enable_hw(arg->drvdata); > } > > +/* > + * The goal of function etm4_config_timestamp_event() is to configure a > + * counter that will tell the tracer to emit a timestamp packet when it > + * reaches zero. This is done in order to get a more fine grained idea > + * of when instructions are executed so that they can be correlated > + * with execution on other CPUs. > + * > + * To do this the counter itself is configured to self reload and > + * TRCRSCTLR1 (always true) used to get the counter to decrement. From > + * there a resource selector is configured with the counter and the > + * timestamp control register to use the resource selector to trigger the > + * event that will insert a timestamp packet in the stream. > + */ > +static int etm4_config_timestamp_event(struct etmv4_drvdata *drvdata) > +{ > + int i, ctridx, ret = -EINVAL; > + int counter, rselector; > + u32 val = 0; > + struct etmv4_config *config = &drvdata->config; > + > + /* No point in trying if we don't have at least one counter */ > + if (!drvdata->nr_cntr) > + goto out; > + > + /* Find a counter that hasn't been initialised */ > + for (i = 0; i < drvdata->nr_cntr; i++) > + if (config->cntr_val[i] == 0) > + break; > + > + /* Remember what counter we used */ > + counter = 1 << i; > + ctridx = i; > + > + /* All the counters have been configured already, bail out */ > + if (i == drvdata->nr_cntr) { > + pr_err("%s: no available counter found\n", __func__); > + goto out; > + } Should this be pr_debug ? This could be easily triggered to flood the dmesg. Also, I think the return code could be -ENODEV or -ENOSPC rather than -EINVAL in this case. > + > + /* > + * Initialise original and reload counter value to the smallest > + * possible value in order to get as much precision as we can. > + */ > + config->cntr_val[ctridx] = 1; > + config->cntrldvr[ctridx] = 1; We could delay the initialisation until we find the resource selector to avoid clearing them later. > + > + /* Set the trace counter control register */ > + val = 0x1 << 16 | /* Bit 16, reload counter automatically */ > + 0x0 << 7 | /* Select single resource selector */ > + 0x1; /* Resource selector 1, i.e always true */ > + > + config->cntr_ctrl[ctridx] = val; > + > + /* > + * Searching for an available resource selector to use, starting at > + * '2' since every implementation has at least 2 resource selector. > + * ETMIDR4 gives the number of resource selector _pairs_, > + * hence multiply by 2. > + */ > + for (i = 2; i < drvdata->nr_resource * 2; i++) > + if (!config->res_ctrl[i]) > + break; > + > + /* Remember what resource selector we used */ > + rselector = i; > + > + if (i == drvdata->nr_resource * 2) { > + pr_err("%s: no available resource selector found\n", __func__); > + Same as above. This shouldn't be an error, may be a debug. It is a crunch of resources, a usage error from the user and not kernel. > + /* Backout what we did and exit */ > + config->cntr_ctrl[ctridx] = 0; > + config->cntrldvr[ctridx] = 0; > + config->cntr_val[ctridx] = 0; > + goto out; > + } > + > + val = 0x2 << 16 | /* Group 0b0010 - Counter and sequencers */ > + counter << 0; /* Counter to use */ > + > + config->res_ctrl[i] = val; > + > + val = 0x0 << 7 | /* Select single resource selector */ > + rselector; /* Resource selector */ > + > + config->ts_ctrl = val; > + > + ret = 0; > +out: > + return ret; > +} > + > static int etm4_parse_event_config(struct etmv4_drvdata *drvdata, > struct perf_event *event) > { > @@ -236,9 +330,24 @@ static int etm4_parse_event_config(struct etmv4_drvdata *drvdata, > /* TRM: Must program this for cycacc to work */ > config->ccctlr = ETM_CYC_THRESHOLD_DEFAULT; > } > - if (attr->config & BIT(ETM_OPT_TS)) > + if (attr->config & BIT(ETM_OPT_TS)) { > + /* > + * Configure timestamps to be emitted at regular intervals in > + * order to correlate instructions executed on different CPUs > + * (CPU-wide trace scenarios). > + */ > + ret = etm4_config_timestamp_event(drvdata); > + > + /* > + * No need to go further if timestamp intervals can't > + * be configured. > + */ > + if (ret) > + goto out; > + > /* bit[11], Global timestamp tracing bit */ > config->cfg |= BIT(11); > + } > > if (attr->config & BIT(ETM_OPT_CTXTID)) > /* bit[6], Context ID tracing bit */ > Rest all looks good to me. Suzuki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel