[PATCH v3 19/31] coresight: cti: Introduce CS_MODE_DEBUG mode

[Mike Leach]

Hi Leo,

On Fri, 3 Oct 2025 at 14:59, Leo Yan <leo.yan at arm.com> wrote:
>
> On Thu, Oct 02, 2025 at 11:31:52AM +0100, Mike Leach wrote:
> > Hi,
> >
> > On Mon, 15 Sept 2025 at 11:34, Leo Yan <leo.yan at arm.com> wrote:
> > >
> > > Introduce a new CS_MODE_DEBUG mode to indicate that a device is being
> > > used for debugging purposes, e.g, if a system enables CTI for debugging
> > > but not for hardware trace
> > >
> >
> > How can you know why the CTI is being enabled?
>
> Depend on which CTI enablement path is invoked.
>
> > System CTIs are attached to key HW trace infrastucture such as input
> > triggers for ETR/ETB that have direct effect on trace.
> > CoreCTIs, while they have some debug triggers, can also trigger ETM events.
>
> Seems to me, it is no matter system CTIs or Core CTIs. Here, I am trying
> to distinguish three methods for enabling CTI:
>
>   (1) Enable CTI within a perf session.
>   (2) Enable CTI within a sysfs session.
>   (3) Enable CTI using the CTI driver's sysfs knob(s).
>
> Currently, methods (2) and (3) are both using CS_MODE_SYSFS.
>
> Method (2) enables a CTI device when we enable a source-to-sink path
> via the sysfs interface; CTI acts as a helper in this case.
>
> Since the CTI driver also provides its own sysfs knobs to enable the
> CTI device by itself (defined in coresight-cti-sysfs.c), to
> distinguish this from method (2), this patch introduces CS_MODE_DEBUG.
>
> Thanks,
> Leo

The point here is that a user can (or at least could and should be
able to) program and enable CTIs across the system to generate signal
inputs to trace devices, then start trace either by sysfs or perf and
expect those CTIs to have the desired effect.

The "mode" for CTIs was introduced to fix a ref count issue. I am not
sure now that this is the best solution. A "mode" is good for
components on the direct trace path responsible for transmitting trace
from source to sink, but perhaps less useful on the CTI/CTM system
which is both global and has multiple uses.

We effectively have three domains for CTIs all of which can be
programmed to affect trace capture -
1) CPU bound - on the trace path, possibly affected by core power down
depending on the implementation of the system and will be enabled as
helpers as the path is enabled.
2) Trace path  system CTIs - connected to other path devices - e.g.
funnels, etr etc, that will also be enabled as helpers as trace path
is enabled.
3) Other system CTIs - not directly connected to specific trace
devices, but can channel signals via the CTM to other trace path CTIs

The CTI driver ref-counts CTI enables / disables, and alos has a flag
to indicate when powered so that enables / disables are counted but
will not be acted on unless powered.

There is probably a case for ensuring that the enables/disables via
the sysfs files are balanced - i.e. a sysfs file disable should not
disable a helper enable, so a specific count on that route may be
needed.

Regards

Mike

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