Re: [PATCH v7 13/13] coresight: docs: Document etm4x timestamp interval option

[Leo Yan <leo.yan@arm.com>]

On Wed, Nov 26, 2025 at 03:36:58PM +0000, Al Grant 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
> > >
> > >
> > 
> > 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.
> 
> Timestamps have a more specialised use in per-thread mode, they are
> as you say less essential for switching in the right context to decode
> the trace, and less relevant to BOLT/AutoFDO style usage where the
> trace is collapsed into a heat-map profile.
> 
> But trace can also be used to get a detailed timeline of CPU activity -
> a non-invasive timeline that can trace even through interrupt-disabled
> kernel code. And for that, having a global constant-frequency timebase
> becomes more useful, both in its own right, and to line up traces
> from each CPU with other CPUs and system-level traces.
> It's also the only way we have to indirectly observe CPU frequency
> adjustments. (Intel's Processor Trace, which is generally similar to
> ETM/ETE, has specific packets that trace CPU frequency changes.)

Just clarify a bit to make sure us on the same page.

This series does not break timestamp functionality, it just changes the
PMU format 'timestamp' from 1-bit to 4-bits for counter support.  The
updated 'timestamp' format still supports per-thread mode and CPU wise
trace modes.

The only difference is now users need to specify 'cs_etm/timestamp=1/'
rather than 'cs_etm/timestamp/' when enabling timestamp.  Given PMU
format is not an ABI, it is fine for me for the updated format.

To avoid confusion for users, a well-written document is deserved —
which is exactly this patch for.  And perf log would be helpful.  I
think we are well prepared for the change.

Thanks,
Leo