From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CA35E332EA7 for ; Thu, 27 Nov 2025 16:09:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764259790; cv=none; b=l4IgY7IRYx7VuknHVJAJqLUa/dDDGS+wtumRFEF8NQbjaZA4FalLUaZCpJ8HbNrky6CjzT8uKGIZe7PzOUEpt0QUQR6+BQ3AYQ35K0fLMIV+3md0AdGUX+EG9gSG69sSNzZ1Mh0hVMd4CgpuIR5FIuWrG+ZJ0oKgxKC5S8f9zNs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764259790; c=relaxed/simple; bh=Shy1HFgfU90K6/nNwp8t68zQdNeKMbk7tWOQoJuS11Y=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Lypp/vzsZ48B7qC4zFIRTMKvfHCYqk1v554lDQK8cWjaoNRF/S0p+9UeElojdFNAxhcHMU9qjE4IMF8SisTh0DUMTuRugOK6ZZa+aSK8Ns+CJ57NoWsVvFUdXEb2qDS1swMyXuoae59lHy8FrUxbmKUAZyPD8yHtDUs9jtI25kI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=iXPbkdHT; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="iXPbkdHT" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-47118259fd8so8523275e9.3 for ; Thu, 27 Nov 2025 08:09:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1764259787; x=1764864587; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=3cpIrGri61+e+bZAB58zpN3dYTJlO6XdCHLnWd6iMRc=; b=iXPbkdHToa0CqRei+F5zqIgct9fAoR25c/iCsBNXS9Yo/Tsia+/qr/Qr4MYQVuV1V3 eAwfm2wHj3uOwnwBgayl5DGhfJkYC1I633eEbYDdtYEUgk9wcNdOwENmnpD+jt/VVo7g pt39xg2mzFPJdePjAgF5OjqmrHnza/ZTd6KjJiZ/6tHZ3fMxjahc3UhsgZBZlopXyeYA 8MD4xbRwBJp01/9Lw/YIE6tGIQ66Y8IN0llVuZEIukNvD3NqiS+K6Dj8ECS/TKr4Nerz F9IbcEjNT4ADGfSz6VWHLgwYwdt9KQrAl3hp8SakyqxQ/m0nuKUW30UBQal/nq7IkdId Np0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764259787; x=1764864587; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3cpIrGri61+e+bZAB58zpN3dYTJlO6XdCHLnWd6iMRc=; b=wa+Fitqyu11GmSoV1jttRvFb6KvmZac2oI8xScLKCQH9vmfqcMSQyrri6hqEhjfn2a OHq2OCTJIW+AABa5AVR0QtEI6GL8K3IThWqzu8HvlZ3vTEymlsfI1vCtmn5A3bW/7Nfj mWQmOmVYYrBNdnMcaxUOvAtFF87aMF61HF6hRQ4xdjJ6SSEh/HXQ78w9lw7H3KnyIvH/ r2ReOT8OXuN6nGeOpohR2rU19FSkb/Q3oIXYdcGwOlUsVs0Z1ni/vAkDF+bj3e1Flciw GxHf2MPNYBFXNE48CS8Cg3Tsd3SOWo+k2VzwqRegYwKZXlF58AArLQqHABjH4v3RiTQW jKzg== X-Forwarded-Encrypted: i=1; AJvYcCXw3BWoo5G4/OEEgfm35ZNkfwQxYb3hRwPyT1uPEm9libCjfQEcnfQ+H+UkoxuElO6L1z+nvQxTDq000/U=@vger.kernel.org X-Gm-Message-State: AOJu0YwTL++H6SU2EbKJIt7K0LpAZgys5El8yZcwfJTE9lrfBkrUtNjN jbPtldc3UWenh0Oaml2QPhQ7ohbGu9thSaw/A/s1OCxBbgk15H0025fjhfRBjcBp6BA= X-Gm-Gg: ASbGncsZAV3J5lIDYiQdMvZC0boWk5fDS92d7kjWQCQ/Ol3I9e1Eht2yYv2UIzWwsr+ XM9gUcY+W1JwsiT0SVlU4QChJPi185Qyz0rO10oV895OMFMllJ62e7LesqrCzvh7BGoki16qDgT v7T3J3cr5tbT0b4kp+B5lN8ZUumDZHsEniMfbq/5B3eIq7k577nNLMNl1+PdBbii2BJpjojYiqr LgG//GefjKyK9eKUK5TIN7bBC6nKvDPfCgMepwjOMroP7DRuW4Js2uzsqNbl+VQKLKTdD5CSLmh XrDBEAjikixv9l2MaqhXpdv7kdYgQPxMzBFOuN8/QKo4Pj69Bk/yv1bUYGkLlubJXoI3+x7Pwjk D1I05o6kpJ+j53Fvhtk66p1uSrKQ1f/6EVCLSAD4sBTDaTdUbMermyjKnFjBBrpvEmfFBAsZW9B vSSXCYPbDZGPUrR5Rq X-Google-Smtp-Source: AGHT+IGXhcwFBRvfQzDOHSo9hFl4xdfh4gra5/RCy9pJflHLTngXIl7AkUmgjKB8t4pi3YsRh+RXCQ== X-Received: by 2002:a05:600c:21cb:b0:477:acb7:7141 with SMTP id 5b1f17b1804b1-4790f03337dmr46833965e9.3.1764259787134; Thu, 27 Nov 2025 08:09:47 -0800 (PST) Received: from [192.168.1.3] ([185.48.77.170]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4790adc8bc7sm113711125e9.1.2025.11.27.08.09.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Nov 2025 08:09:46 -0800 (PST) Message-ID: <718ffc8b-21ec-4536-b0c4-aaf2635aaf75@linaro.org> Date: Thu, 27 Nov 2025 16:09:45 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 12/13] coresight: Allow setting the timestamp interval To: Mike Leach Cc: Suzuki K Poulose , Alexander Shishkin , Jonathan Corbet , Leo Yan , Randy Dunlap , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org References: <20251126-james-cs-syncfreq-v7-0-7fae5e0e5e16@linaro.org> <20251126-james-cs-syncfreq-v7-12-7fae5e0e5e16@linaro.org> Content-Language: en-US From: James Clark In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 27/11/2025 3:48 pm, Mike Leach wrote: > Hi James > > On Wed, 26 Nov 2025 at 10:57, James Clark wrote: >> >> Timestamps are currently emitted at the maximum rate possible, which is >> much too frequent for most use cases. Set the interval using the value >> from the timestamp field. Granular control is not required, so save >> space in the config by interpreting it as 2 ^ timestamp. And then 4 >> bits (0 - 15) is enough to set the interval to be larger than the >> existing SYNC timestamp interval. >> >> No sysfs mode support is needed for this attribute because counter >> generated timestamps are only configured for Perf mode. >> >> Reviewed-by: Leo Yan >> Tested-by: Leo Yan >> Signed-off-by: James Clark >> --- >> drivers/hwtracing/coresight/coresight-etm-perf.h | 1 + >> drivers/hwtracing/coresight/coresight-etm4x-core.c | 28 +++++++++++++++------- >> 2 files changed, 20 insertions(+), 9 deletions(-) >> >> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.h b/drivers/hwtracing/coresight/coresight-etm-perf.h >> index 24d929428633..128f80bb1443 100644 >> --- a/drivers/hwtracing/coresight/coresight-etm-perf.h >> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.h >> @@ -7,6 +7,7 @@ >> #ifndef _CORESIGHT_ETM_PERF_H >> #define _CORESIGHT_ETM_PERF_H >> >> +#include >> #include >> #include "coresight-priv.h" >> >> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c >> index c7bf73c8f2d7..0129b0502726 100644 >> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c >> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c >> @@ -651,7 +651,7 @@ static void etm4_enable_sysfs_smp_call(void *info) >> * +--------------+ >> * | >> * +------v-------+ >> - * | Counter x | (reload to 1 on underflow) >> + * | Counter x | (reload to 2 ^ timestamp on underflow) >> * +--------------+ >> * | >> * +------v--------------+ >> @@ -662,11 +662,25 @@ static void etm4_enable_sysfs_smp_call(void *info) >> * | Timestamp Generator | (timestamp on resource y) >> * +----------------------+ >> */ >> -static int etm4_config_timestamp_event(struct etmv4_drvdata *drvdata) >> +static int etm4_config_timestamp_event(struct etmv4_drvdata *drvdata, >> + struct perf_event_attr *attr) >> { >> int ctridx; >> int rselector; >> struct etmv4_config *config = &drvdata->config; >> + struct perf_event_attr max_timestamp = { >> + .ATTR_CFG_FLD_timestamp_CFG = U64_MAX, >> + }; >> + >> + /* timestamp may be 0 if deprecated_timestamp is used, so make min 1 */ >> + u8 ts_level = max(1, ATTR_CFG_GET_FLD(attr, timestamp)); >> + > > I could be missing something here - but if we have a perf command line: > > perf -e cs_etm/timestamp=0/ > > is this bit not changing that to timestamp=1 regardless? The docs > (patch 13) indicate timestamp=0 to be timestamps off. > > This command is used in test_arm_coresight.sh when testing the > combination of options on the CS system. > > Mike > No, no change. This function never gets called if either timestamp or deprecated_timestamp = 0. timestamp=0 and timestamp=1 still behave exactly the same as before. The only new change is timestamp values > 1 and that the bits used in the config are different. >> + /* >> + * Disable counter generated timestamps when timestamp == MAX. Leave >> + * only SYNC timestamps. >> + */ >> + if (ts_level == ATTR_CFG_GET_FLD(&max_timestamp, timestamp)) >> + return 0; >> >> /* No point in trying if we don't have at least one counter */ >> if (!drvdata->nr_cntr) >> @@ -704,12 +718,8 @@ static int etm4_config_timestamp_event(struct etmv4_drvdata *drvdata) >> return -ENOSPC; >> } >> >> - /* >> - * 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; >> + /* Initialise original and reload counter value. */ >> + config->cntr_val[ctridx] = config->cntrldvr[ctridx] = 1 << (ts_level - 1); >> >> /* >> * Trace Counter Control Register TRCCNTCTLRn >> @@ -799,7 +809,7 @@ static int etm4_parse_event_config(struct coresight_device *csdev, >> * order to correlate instructions executed on different CPUs >> * (CPU-wide trace scenarios). >> */ >> - ret = etm4_config_timestamp_event(drvdata); >> + ret = etm4_config_timestamp_event(drvdata, attr); >> >> /* >> * No need to go further if timestamp intervals can't >> >> -- >> 2.34.1 >> > >