[PATCH v6 11/11] coresight: etm4x: Reuse normal enable and disable logic in CPU idle

[Mike Leach]

Hi Leo

On Wed, 12 Nov 2025 at 13:56, Leo Yan <leo.yan at arm.com> wrote:
>
> Hi Mike,
>
> On Wed, Nov 12, 2025 at 11:58:26AM +0000, Mike Leach wrote:
>
> [...]
>
> > > I prefer we can use a separate patch series to address this issue (I
> > > should review Levi's patch series so can make things proceed). At the
> > > meantime, I would say this patch is still valid.
> > >
> > > As a side topic, actually we have found issues for the config is
> > > reset when start a session so the user's config does not take affect at
> > > all (see etm4_set_default_config()).
> >
> > This code is used by the perf session - not the sysfs session. This is
> > deliberate to start from a stable state and add any configuration from
> > the perf command line.
>
> My feeling is now the discussion mixes up two things:
>
> - Should we apply user's parameters (via sysfs knobs) on a perf session?
>
> - Can a perf session overwrite user's parameters?
>
> For me, there is no reason to prevent a perf session from using the
> user's configs.  We might disagree on this, but regarding the second
> question, a perf session definitely should not overwrite the user's
> parameters — it can ignore the user's configuration, but it must not
> erase these parameters.
>
> > The perf session deliberately ignores parameters set by sysfs - in
> > fact the first act in parsing the perf event structure in
> > etm4_parse_event_config(), is to completely zero out the entire config
> > structure. Then the default config is set - which guarantees trace is
> > captured, then any perf command line options are set in the registers
> > (e.g. timestamps, address filtering etc). After this if we have s
> > cscfg configuration active, this too is added in.
>
> Seems to me, a correct sequence is:
>
>  1) Clean up hw_config;
>  2) Apply user's config on hw_config;

The configuration system was designed precisely to implement the
concept of a "users config" without the unnecessary burden of having
to program up all the ETMs via sysfs in a multicore system.

The users config you describe is simply repeating work already done.

The danger in using sysfs configuration is that the perf session
cannot possibly know if it was set by the current user of the
resources or left over from a previous session.

The only elements that should affect a perf session should be those
that appear on the perf command line - these being the traditional
commands + a named configuration if present. This means that the owner
of the perf session is 100% sure of what is being requested.

Changing the configuration of a perf session via some backdoor sysfs
additions is unacceptable.

Regards

Mike

>  3) Apply cscfg on hw_config.
>  4) Apply perf's format/config on hw_config;
>
> In this sequence, the last applying config has highest priority (as
> the perf format is the latest setting from user).
>
> Here I am not quite sure for step 2) and 3).  Should we apply both
> user's config and cscfg, or we apply only one and ignore another (e.g.,
> if cscfg has been set, then ignore user's config, vice versa).
>
> > This ensures that the configuration run on all the ETMs used during
> > the perf session is identical - which cannot be guaranteed if we used
> > sysfs set parameters as part of the perf session, as each ETM might
> > have different parameters set by sysfs.This gives us predictable,
> > stable and repeatable perf configurations.
>
> Why can't we leave this to users?
>
> For sanity, drivers should reject invalid parameters when a user is
> setting it, once the parameters are accepted, afterwards drivers should
> simply follow the user's settings in a runtime session.
>
> Thanks,
> Leo



-- 
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK