mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Al Grant <Al.Grant@arm.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Cc: Mike Leach <mike.leach@linaro.org>,
	"coresight@lists.linaro.org" <coresight@lists.linaro.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] coresight: etm: Make cycle count threshold user configurable
Date: Fri, 4 Aug 2023 14:15:38 +0530	[thread overview]
Message-ID: <92a176f4-c8ff-2ce0-c667-b134436452ee@arm.com> (raw)
In-Reply-To: <DB9PR08MB7512B9A03A86B8983884B1C98609A@DB9PR08MB7512.eurprd08.prod.outlook.com>



On 8/4/23 13:34, Al Grant wrote:
> 
> 
>> -----Original Message-----
>> From: Anshuman Khandual <anshuman.khandual@arm.com>
>> Sent: Friday, August 4, 2023 5:47 AM
>> To: linux-arm-kernel@lists.infradead.org
>> Cc: Anshuman Khandual <Anshuman.Khandual@arm.com>; Mike Leach
>> <mike.leach@linaro.org>; coresight@lists.linaro.org; linux-doc@vger.kernel.org;
>> linux-kernel@vger.kernel.org
>> Subject: [PATCH] coresight: etm: Make cycle count threshold user configurable
>>
>> Cycle counting is enabled, when requested and supported but with a default
>> threshold value ETM_CYC_THRESHOLD_DEFAULT i.e 0x100 getting into
>> TRCCCCTLR, representing the minimum interval between cycle count trace
>> packets.
>>
>> This makes cycle threshold user configurable, from the user space via perf event
>> attributes. Although it falls back using ETM_CYC_THRESHOLD_DEFAULT, in case
>> no explicit request. As expected it creates a sysfs file as well.
>>
>> /sys/bus/event_source/devices/cs_etm/format/cc_threshold
>>
>> New 'cc_threshold' uses 'event->attr.config3' as no more space is available in
>> 'event->attr.config1' or 'event->attr.config2'.
>>
>> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
>> Cc: Mike Leach <mike.leach@linaro.org>
>> Cc: James Clark <james.clark@arm.com>
>> Cc: Leo Yan <leo.yan@linaro.org>
>> Cc: coresight@lists.linaro.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-doc@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>>  Documentation/trace/coresight/coresight.rst        |  2 ++
>>  drivers/hwtracing/coresight/coresight-etm-perf.c   |  2 ++
>>  drivers/hwtracing/coresight/coresight-etm4x-core.c | 12 ++++++++++--
>>  3 files changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/trace/coresight/coresight.rst
>> b/Documentation/trace/coresight/coresight.rst
>> index 4a71ea6cb390..b88d83b59531 100644
>> --- a/Documentation/trace/coresight/coresight.rst
>> +++ b/Documentation/trace/coresight/coresight.rst
>> @@ -624,6 +624,8 @@ They are also listed in the folder
>> /sys/bus/event_source/devices/cs_etm/format/
>>     * - timestamp
>>       - Session local version of the system wide setting:
>> :ref:`ETMv4_MODE_TIMESTAMP
>>         <coresight-timestamp>`
>> +   * - cc_treshold
> 
> Spelling: cc_threshold

Will fix this, besides does it require some more description for
this new config option i.e cc_threshold ?

> 
>> +     - Cycle count treshhold value
>>
>>  How to use the STM module
>>  -------------------------
>> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c
>> b/drivers/hwtracing/coresight/coresight-etm-perf.c
>> index 5ca6278baff4..09f75dffae60 100644
>> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
>> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
>> @@ -68,6 +68,7 @@ PMU_FORMAT_ATTR(preset,		"config:0-3");
>>  PMU_FORMAT_ATTR(sinkid,		"config2:0-31");
>>  /* config ID - set if a system configuration is selected */
>>  PMU_FORMAT_ATTR(configid,	"config2:32-63");
>> +PMU_FORMAT_ATTR(cc_threshold,	"config3:0-11");
>>
>>
>>  /*
>> @@ -101,6 +102,7 @@ static struct attribute *etm_config_formats_attr[] = {
>>  	&format_attr_preset.attr,
>>  	&format_attr_configid.attr,
>>  	&format_attr_branch_broadcast.attr,
>> +	&format_attr_cc_threshold.attr,
>>  	NULL,
>>  };
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c
>> b/drivers/hwtracing/coresight/coresight-etm4x-core.c
>> index 9d186af81ea0..9a2766f68416 100644
>> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
>> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
>> @@ -644,7 +644,7 @@ static int etm4_parse_event_config(struct
>> coresight_device *csdev,
>>  	struct etmv4_config *config = &drvdata->config;
>>  	struct perf_event_attr *attr = &event->attr;
>>  	unsigned long cfg_hash;
>> -	int preset;
>> +	int preset, cc_threshold;
>>
>>  	/* Clear configuration from previous run */
>>  	memset(config, 0, sizeof(struct etmv4_config)); @@ -667,7 +667,15 @@
>> static int etm4_parse_event_config(struct coresight_device *csdev,
>>  	if (attr->config & BIT(ETM_OPT_CYCACC)) {
>>  		config->cfg |= TRCCONFIGR_CCI;
>>  		/* TRM: Must program this for cycacc to work */
>> -		config->ccctlr = ETM_CYC_THRESHOLD_DEFAULT;
>> +		cc_treshold = attr->config3 & ETM_CYC_THRESHOLD_MASK;
> 
> Spelling again

Yikes, this does not even build. Seems like I had missed the applicable
config i.e CONFIG_CORESIGHT_SOURCE_ETM4X this time around. Apologies.

> 
>> +		if (cc_treshold) {
>> +			if (cc_treshold < drvdata->ccitmin)
>> +				config->ccctlr = drvdata->ccitmin;
>> +			else
>> +				config->ccctlr = cc_threshold;
>> +		} else {
>> +			config->ccctlr = ETM_CYC_THRESHOLD_DEFAULT;
>> +		}
> 
> Consider dropping the check against CCITMIN. There are CPUs where
> CCITMIN is incorrect, e.g. see published errata 1490853 where the
> value 0x100 should be 0b100 i.e. 4. On these ETMs it is possible to
> set the timing threshold to four cycles instead of 256 cycles, providing
> much better timing resolution. The kernel currently does not work
> around this errata and uses the incorrect value of ccitmin. If you drop
> the check, and trust the value provided by userspace, you allow
> userspace to work around it.
Why ? We could just work around the errata #1490853 while initializing
the drvdata->ccitmin if that is where the problem exists. I dont think
user space should be required to know about the erratas, and provide a
right value instead.

  reply	other threads:[~2023-08-04  8:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-04  4:47 Anshuman Khandual
2023-08-04  8:04 ` Al Grant
2023-08-04  8:45   ` Anshuman Khandual [this message]
2023-08-04  9:23     ` James Clark
2023-08-04 10:10       ` Al Grant
2023-08-04 11:07         ` James Clark
2023-08-05  3:18 ` kernel test robot
2023-08-08  7:45 Anshuman Khandual
2023-08-08 10:19 ` Mike Leach
2023-08-09  4:42   ` Anshuman Khandual

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=92a176f4-c8ff-2ce0-c667-b134436452ee@arm.com \
    --to=anshuman.khandual@arm.com \
    --cc=Al.Grant@arm.com \
    --cc=coresight@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.leach@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®