Hi Leo,
On Fri, 3 Oct 2025 at 14:59, Leo Yan leo.yan@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@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