Document how the new field is used, maximum value and the interaction
with SYNC timestamps.
Signed-off-by: James Clark <james.clark@linaro.org>
---
Documentation/trace/coresight/coresight.rst | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/Documentation/trace/coresight/coresight.rst b/Documentation/trace/coresight/coresight.rst
index 806699871b80..d461de4e067e 100644
--- a/Documentation/trace/coresight/coresight.rst
+++ b/Documentation/trace/coresight/coresight.rst
@@ -613,8 +613,20 @@ They are also listed in the folder /sys/bus/event_source/devices/cs_etm/format/
- Session local version of the system wide setting: :ref:`ETM_MODE_RETURNSTACK
<coresight-return-stack>`
* - timestamp
- - Session local version of the system wide setting: :ref:`ETMv4_MODE_TIMESTAMP
- <coresight-timestamp>`
+ - Controls generation and interval of timestamps.
+
+ 0 = off, 1 = minimum interval .. 15 = maximum interval.
+
+ Values 1 - 14 use a counter that decrements every cycle to generate a
+ timestamp on underflow. The reload value for the counter is 2 ^ (interval
+ - 1). If the value is 1 then the reload value is 1, if the value is 11
+ then the reload value is 1024 etc.
+
+ Setting the maximum interval (15) will disable the counter generated
+ timestamps, freeing the counter resource, leaving only ones emitted when
+ a SYNC packet is generated. The sync interval is controlled with
+ TRCSYNCPR.PERIOD which is every 4096 bytes of trace by default.
+
* - cc_threshold
- Cycle count threshold value. If nothing is provided here or the provided value is 0, then the
default value i.e 0x100 will be used. If provided value is less than minimum cycles threshold
--
2.34.1On Wed, Nov 26, 2025 at 10:54:42AM +0000, James Clark wrote: > Document how the new field is used, maximum value and the interaction > with SYNC timestamps. > > Signed-off-by: James Clark <james.clark@linaro.org> Reviewed-by: Leo Yan <leo.yan@arm.com> > --- > Documentation/trace/coresight/coresight.rst | 16 ++++++++++++++-- > 1 file changed, 14 insertions(+), 2 deletions(-) > > diff --git a/Documentation/trace/coresight/coresight.rst b/Documentation/trace/coresight/coresight.rst > index 806699871b80..d461de4e067e 100644 > --- a/Documentation/trace/coresight/coresight.rst > +++ b/Documentation/trace/coresight/coresight.rst > @@ -613,8 +613,20 @@ They are also listed in the folder /sys/bus/event_source/devices/cs_etm/format/ > - Session local version of the system wide setting: :ref:`ETM_MODE_RETURNSTACK > <coresight-return-stack>` > * - timestamp > - - Session local version of the system wide setting: :ref:`ETMv4_MODE_TIMESTAMP > - <coresight-timestamp>` > + - Controls generation and interval of timestamps. > + > + 0 = off, 1 = minimum interval .. 15 = maximum interval. > + > + Values 1 - 14 use a counter that decrements every cycle to generate a > + timestamp on underflow. The reload value for the counter is 2 ^ (interval > + - 1). If the value is 1 then the reload value is 1, if the value is 11 > + then the reload value is 1024 etc. > + > + Setting the maximum interval (15) will disable the counter generated > + timestamps, freeing the counter resource, leaving only ones emitted when > + a SYNC packet is generated. The sync interval is controlled with > + TRCSYNCPR.PERIOD which is every 4096 bytes of trace by default. > + > * - cc_threshold > - Cycle count threshold value. If nothing is provided here or the provided value is 0, then the > default value i.e 0x100 will be used. If provided value is less than minimum cycles threshold > > -- > 2.34.1 >
Hi, On Wed, 26 Nov 2025 at 14:01, Leo Yan <leo.yan@arm.com> wrote: > > On Wed, Nov 26, 2025 at 10:54:42AM +0000, James Clark wrote: > > Document how the new field is used, maximum value and the interaction > > with SYNC timestamps. > > > > Signed-off-by: James Clark <james.clark@linaro.org> > > Reviewed-by: Leo Yan <leo.yan@arm.com> > > > --- > > Documentation/trace/coresight/coresight.rst | 16 ++++++++++++++-- > > 1 file changed, 14 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/trace/coresight/coresight.rst b/Documentation/trace/coresight/coresight.rst > > index 806699871b80..d461de4e067e 100644 > > --- a/Documentation/trace/coresight/coresight.rst > > +++ b/Documentation/trace/coresight/coresight.rst > > @@ -613,8 +613,20 @@ They are also listed in the folder /sys/bus/event_source/devices/cs_etm/format/ > > - Session local version of the system wide setting: :ref:`ETM_MODE_RETURNSTACK > > <coresight-return-stack>` > > * - timestamp > > - - Session local version of the system wide setting: :ref:`ETMv4_MODE_TIMESTAMP > > - <coresight-timestamp>` > > + - Controls generation and interval of timestamps. > > + > > + 0 = off, 1 = minimum interval .. 15 = maximum interval. > > + > > + Values 1 - 14 use a counter that decrements every cycle to generate a > > + timestamp on underflow. The reload value for the counter is 2 ^ (interval > > + - 1). If the value is 1 then the reload value is 1, if the value is 11 > > + then the reload value is 1024 etc. > > + > > + Setting the maximum interval (15) will disable the counter generated > > + timestamps, freeing the counter resource, leaving only ones emitted when > > + a SYNC packet is generated. The sync interval is controlled with > > + TRCSYNCPR.PERIOD which is every 4096 bytes of trace by default. > > + What is the default value? As far as I recall when this command line parameter was a bool then: perf -e cs_etm/timestamp/ <program> is sufficient to turn on timestamping. This is worth mentioning so users can correctly assess what happens for any existing scripts they might have. Based on this then the same command must set the timestamp to 1 - which will have the same effect as before as we do not want to break existing behaviour. Mike > > * - cc_threshold > > - Cycle count threshold value. If nothing is provided here or the provided value is 0, then the > > default value i.e 0x100 will be used. If provided value is less than minimum cycles threshold > > > > -- > > 2.34.1 > > -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK
On Wed, Nov 26, 2025 at 02:20:14PM +0000, Mike Leach wrote:
[...]
> > > * - timestamp
> > > - - Session local version of the system wide setting: :ref:`ETMv4_MODE_TIMESTAMP
> > > - <coresight-timestamp>`
> > > + - Controls generation and interval of timestamps.
> > > +
> > > + 0 = off, 1 = minimum interval .. 15 = maximum interval.
> > > +
> > > + Values 1 - 14 use a counter that decrements every cycle to generate a
> > > + timestamp on underflow. The reload value for the counter is 2 ^ (interval
> > > + - 1). If the value is 1 then the reload value is 1, if the value is 11
> > > + then the reload value is 1024 etc.
> > > +
> > > + Setting the maximum interval (15) will disable the counter generated
> > > + timestamps, freeing the counter resource, leaving only ones emitted when
> > > + a SYNC packet is generated. The sync interval is controlled with
> > > + TRCSYNCPR.PERIOD which is every 4096 bytes of trace by default.
> > > +
>
> What is the default value?
From driver's pespective, the default value is 0 (disabled). We do
set default values in perf:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/arch/arm/util/cs-etm.c#n444
IIUC, the default value would be the same with or without this series.
> As far as I recall when this command line parameter was a bool then:
> perf -e cs_etm/timestamp/ <program>
> is sufficient to turn on timestamping.
Hmm... with the latest perf, we must assign value to `timestamp`,
otherwise perf will report error:
# /mnt/build/perf record -e cs_etm/timestamp/ -C 0 -- taskset -c 0 ls
event syntax error: 'cs_etm/timestamp/'
\___ Bad event or PMU
Unable to find PMU or event on a PMU of 'cs_etm'
event syntax error: 'cs_etm/timestamp/'
\___ no value assigned for term
event syntax error: 'cs_etm/timestamp/'
\___ no value assigned for term
Run 'perf list' for a list of valid events
> This is worth mentioning so users can correctly assess what happens
> for any existing scripts they might have.
>
> Based on this then the same command must set the timestamp to 1 -
> which will have the same effect as before as we do not want to break
> existing behaviour.
>
> Mike
>
>
> > > * - cc_threshold
> > > - Cycle count threshold value. If nothing is provided here or the provided value is 0, then the
> > > default value i.e 0x100 will be used. If provided value is less than minimum cycles threshold
> > >
> > > --
> > > 2.34.1
> > >
>
>
>
> --
> Mike Leach
> Principal Engineer, ARM Ltd.
> Manchester Design Centre. UK
On Wed, Nov 26, 2025 at 02:44:37PM +0000, Coresight ML wrote: [...] > > As far as I recall when this command line parameter was a bool then: > > perf -e cs_etm/timestamp/ <program> > > is sufficient to turn on timestamping. > > Hmm... with the latest perf, we must assign value to `timestamp`, > otherwise perf will report error: > > # /mnt/build/perf record -e cs_etm/timestamp/ -C 0 -- taskset -c 0 ls > event syntax error: 'cs_etm/timestamp/' > \___ Bad event or PMU > > Unable to find PMU or event on a PMU of 'cs_etm' > > event syntax error: 'cs_etm/timestamp/' > \___ no value assigned for term > > event syntax error: 'cs_etm/timestamp/' > \___ no value assigned for term > Run 'perf list' for a list of valid events Apologize for this misinformation. When `timestamp` is bool, it does support the `-e cs_etm/timestamp/` format. > > This is worth mentioning so users can correctly assess what happens > > for any existing scripts they might have. > > > > Based on this then the same command must set the timestamp to 1 - > > which will have the same effect as before as we do not want to break > > existing behaviour. Not sure if we need to record such info. Seems to me, it is weird that record a common behaviour for perf formats in this doc. The perf error log would be sufficient for users to setup a proper format? Thanks, Leo
On 26/11/2025 2:44 pm, Leo Yan wrote: > On Wed, Nov 26, 2025 at 02:20:14PM +0000, Mike Leach wrote: > > [...] > >>>> * - timestamp >>>> - - Session local version of the system wide setting: :ref:`ETMv4_MODE_TIMESTAMP >>>> - <coresight-timestamp>` >>>> + - Controls generation and interval of timestamps. >>>> + >>>> + 0 = off, 1 = minimum interval .. 15 = maximum interval. >>>> + >>>> + Values 1 - 14 use a counter that decrements every cycle to generate a >>>> + timestamp on underflow. The reload value for the counter is 2 ^ (interval >>>> + - 1). If the value is 1 then the reload value is 1, if the value is 11 >>>> + then the reload value is 1024 etc. >>>> + >>>> + Setting the maximum interval (15) will disable the counter generated >>>> + timestamps, freeing the counter resource, leaving only ones emitted when >>>> + a SYNC packet is generated. The sync interval is controlled with >>>> + TRCSYNCPR.PERIOD which is every 4096 bytes of trace by default. >>>> + >> >> What is the default value? > > From driver's pespective, the default value is 0 (disabled). We do > set default values in perf: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/arch/arm/util/cs-etm.c#n444 > > IIUC, the default value would be the same with or without this series. > >> As far as I recall when this command line parameter was a bool then: >> perf -e cs_etm/timestamp/ <program> >> is sufficient to turn on timestamping. > > Hmm... with the latest perf, we must assign value to `timestamp`, > otherwise perf will report error: > > # /mnt/build/perf record -e cs_etm/timestamp/ -C 0 -- taskset -c 0 ls > event syntax error: 'cs_etm/timestamp/' > \___ Bad event or PMU > > Unable to find PMU or event on a PMU of 'cs_etm' > > event syntax error: 'cs_etm/timestamp/' > \___ no value assigned for term > > event syntax error: 'cs_etm/timestamp/' > \___ no value assigned for term > Run 'perf list' for a list of valid events > > That's unfortunate and not what I expected. And I don't think it makes sense to remove that validation from Perf. The test uses "timestamp=1" so I didn't notice. Can we accept that people are most likely using the defaults so timestamps are already on and they wouldn't be using it? The only real use case of that at the moment is to do timestamp=0 and that doesn't fail. Although it's not the default for per-thread mode and I did find the OpenCSD HOWTO.md uses it as an example. timestamps make less sense in per-thread mode as you don't need to correlate between CPUs or watch for context switches. I suppose we need to choose what's worse, breaking some subset of Perf commands in a slightly annoying way or having two separate options to control timestamps that you have to use together. I think it's 50/50, maybe with the breakage being the slightly better option. >> This is worth mentioning so users can correctly assess what happens >> for any existing scripts they might have. >> >> Based on this then the same command must set the timestamp to 1 - >> which will have the same effect as before as we do not want to break >> existing behaviour. >> >> Mike >> >> >>>> * - cc_threshold >>>> - Cycle count threshold value. If nothing is provided here or the provided value is 0, then the >>>> default value i.e 0x100 will be used. If provided value is less than minimum cycles threshold >>>> >>>> -- >>>> 2.34.1 >>>> >> >> >> >> -- >> Mike Leach >> Principal Engineer, ARM Ltd. >> Manchester Design Centre. UK
© 2016 - 2025 Red Hat, Inc.