CoreSight

coresight@lists.linaro.org

4 participants
2499 discussions

[PATCH v3 0/5] coresight: Add format attribute for setting the timestamp interval

by James Clark

Do some cleanups then add a new format attribute to set the timestamp interval for ETMv4 in Perf mode. The current interval is too high for most use cases, and particularly on the FVP the number of timestamps generated is excessive. Although it would be good to make only SYNC timestamps the default and have counter timestamps opt-in, this would be a breaking change. We can always do that later, or disable counter timestamps from Perf. This is added as an event format attribute, rather than a Coresight config because it's something that the driver is already configuring automatically in Perf mode with any unused counter, so it's not possible to modify this with a config. Applies to coresight/next Signed-off-by: James Clark <james.clark(a)linaro.org> --- Changes in v3: - Move the format attr definitions to coresight-etm-perf.h we can compile on arm32 without #ifdefs - (Leo) - Convert the new #ifdefs to a single one in an is_visible() function so that the code is cleaner - (Leo) - Drop the change to remove the holes in struct etmv4_config as they were grouped by function - (Mike) - Link to v2: https://lore.kernel.org/r/20250814-james-cs-syncfreq-v2-0-c76fcb87696d@lina… Changes in v2: - Only show the attribute for ETMv4 to improve usability and fix the arm32 build error. Wrapping everything in IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM4X) isn't ideal, but the -perf.c file is shared between ETMv3 and ETMv4, and there is already precedent for doing it this way. - Link to v1: https://lore.kernel.org/r/20250811-james-cs-syncfreq-v1-0-b001cd6e3404@lina… --- James Clark (5): coresight: Change syncfreq to be a u8 coresight: Repack struct etmv4_drvdata coresight: Refactor etm4_config_timestamp_event() coresight: Add format attribute for setting the timestamp interval coresight: docs: Document etm4x ts_interval Documentation/trace/coresight/coresight.rst | 14 +++ drivers/hwtracing/coresight/coresight-etm-perf.c | 16 ++- drivers/hwtracing/coresight/coresight-etm-perf.h | 7 ++ drivers/hwtracing/coresight/coresight-etm4x-core.c | 110 +++++++++++++-------- drivers/hwtracing/coresight/coresight-etm4x.h | 61 +++++++----- 5 files changed, 143 insertions(+), 65 deletions(-) --- base-commit: 01f96b812526a2c8dcd5c0e510dda37e09ec8bcd change-id: 20250724-james-cs-syncfreq-7c2257a38ed3 Best regards, -- James Clark <james.clark(a)linaro.org>

9 hours, 1 minute

Re: [PATCH] perf sample: Fix the wrong format specifier

by Mike Leach

On Mon, 22 Sept 2025 at 10:51, liujing <liujing(a)cmss.chinamobile.com> wrote: > > In the file tools/perf/util/cs-etm.c, queue_nr is of type unsigned > int and should be printed with %u. > > Signed-off-by: liujing <liujing(a)cmss.chinamobile.com> > --- > tools/perf/util/cs-etm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c > index 30f4bb3e7fa3..d13575285b19 100644 > --- a/tools/perf/util/cs-etm.c > +++ b/tools/perf/util/cs-etm.c > @@ -777,7 +777,7 @@ static void cs_etm__packet_dump(const char *pkt_string, void *data) > char queue_nr[64]; > > if (verbose) > - snprintf(queue_nr, sizeof(queue_nr), "Qnr:%d; ", etmq->queue_nr); > + snprintf(queue_nr, sizeof(queue_nr), "Qnr:%u; ", etmq->queue_nr); > else > queue_nr[0] = '\0'; > > -- > 2.27.0 > > > > Reviewed-by: Mike Leach <mike.leach(a)linaro.org> -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

10 hours, 48 minutes

[PATCH v3 00/31] CoreSight: Address CPU Power Management Issues

by Leo Yan

This series addresses CPU power management issues in the CoreSight drivers. For easier review, the patches are organized into two categories: o Patches 01 ~ 10 focus on CPU power management within the ETM drivers. These patches fix SMP-safe access to the mode, correct context synchronization, and refactor the CPU suspend/resume flows. o Patches 11 ~ 31 extend CPU power management to cover activated paths, including helpers, links, and sinks. These changes move CPU PM and hotplug notifiers from the ETMv4 driver into the CoreSight core layer. Summary: - Patches 01 ~ 03: Fix device mode access in the SMP mode. - Patch 04 : A minor fix for polling bit. - Patches 05 ~ 07: Improve the context synchronization based on the ETM specification (IHI0064H.b) and Arm ARM (ARM DDI 0487 L.a). - Patches 08 ~ 10: Refactor the context save/restore flow in the ETMv4 driver, in the end, the CPU PM callbacks reuse the normal enabling and disabling flows. - Patches 11 ~ 17: Move CPU PM code from ETMv4 driver to the core layer. - Patches 18 ~ 23: Enhance the CTI driver for preparation dynamically controlling CTI devices in PM flows. This includes device mode handling in the CTI driver and distinguishing trace modes (Perf or SysFS). Refactor the PM notifier and improve locking usage (including for syscfg). - Patches 24 ~ 31: Support save and restore context for TRBE and manages activated paths during CPU idle and CPU hotplug. Verification: This series has been verified on Juno-r0 and r2 platform. Stress test script: #!/usr/bin/bash echo 1 > /sys/bus/coresight/devices/tmc_etr0/enable_sink while true; do echo 0 > /sys/devices/system/cpu/cpu2/online; echo 1 > /sys/devices/system/cpu/cpu2/online; done & while true; do echo 1 > /sys/bus/coresight/devices/etm2/enable_source; echo 0 > /sys/bus/coresight/devices/etm2/enable_source; done & Test script with kernel module insmod / rmmod: #!/bin/bash modules=( "coresight" "coresight_dummy" "coresight_replicator" "coresight_tpiu" "coresight_cpu_debug" "coresight_etb10" "coresight_stm" "coresight_trbe" "coresight_tmc" "coresight_ctcu" "coresight_catu" "coresight_etm4x" "coresight_cti" "coresight_funnel" "coresight_tnoc" ) module_dir="/mnt/build/drivers/hwtracing/coresight/" if [[ "$1" == "in" ]]; then echo "Inserting modules..." for mod in "${modules[@]}"; do modprobe $mod && echo "Loaded $mod" || echo "Failed to load $mod" done elif [[ "$1" == "rm" ]]; then echo "Removing modules..." # Remove in reverse order to respect dependencies for (( idx=${#modules[@]}-1 ; idx>=0 ; idx-- )); do mod="${modules[$idx]}" echo "Removing $mod..." rmmod "$mod" && echo "Removed $mod" || echo "Failed to remove $mod" done fi --- Changes in v3: - Fixed building failure in ETMv3 driver (kernel test robot). - Refactoring ETMv3 change for checking CPU ID (Levi). - Fixed NULL pointer issue during CPU idle (James). - Fixed lockdep complaint for HARDIRQ-safe and HARDIRA-unsafe (James). - Fixed acquiring mutex in atomic context (James). - Rebased on the latest coresight-next branch. - Link to v2: https://lore.kernel.org/r/20250701-arm_cs_pm_fix_v3-v2-0-23ebb864fcc1@arm.c… Changes in v2: - Refactored ETMv4 suspend and resume for reusing the normal enabling and disabling flows (James). - Used a per-CPU structure to maintain path pointers (James). - Supported helpers in CPU PM flows (James). - Fixed the SMP-safe access to device mode. - Fixed the context synchronization in ETMv4x driver. - Link to v1: https://lore.kernel.org/linux-arm-kernel/20250516160742.1200904-1-leo.yan@a… Signed-off-by: Leo Yan <leo.yan(a)arm.com> --- Leo Yan (30): coresight: Change device mode to atomic type coresight: etm4x: Always set tracer's device mode on target CPU coresight: etm3x: Always set tracer's device mode on target CPU coresight: etm4x: Correct polling IDLE bit coresight: etm4x: Ensure context synchronization is not ignored coresight: etm4x: Add context synchronization before enabling trace coresight: etm4x: Properly control filter in CPU idle with FEAT_TRF coresight: etm4x: Remove the state_needs_restore flag coresight: etm4x: Add flag to control single-shot restart coresight: etm4x: Reuse normal enable and disable logic in CPU idle coresight: Populate CPU ID into the coresight_device structure coresight: sysfs: Validate CPU online status for per-CPU sources coresight: Set per CPU source pointer coresight: Register CPU PM notifier in core layer coresight: etm4x: Hook CPU PM callbacks coresight: Add callback to determine if context save/restore is needed coresight: etm4x: Remove redundant condition checks in save and restore coresight: cti: Fix race condition by using device mode coresight: cti: Introduce CS_MODE_DEBUG mode coresight: cti: Register PM notifier after data initialization coresight: cti: Properly handle modes in CPU PM notifiers coresight: cti: Make spin lock usage consistent coresight: syscfg: Use spinlock to protect active variables coresight: Add per-CPU path pointer coresight: Add 'in_idle' argument to path enable/disable functions coresight: Control path during CPU idle coresight: Add PM callbacks for percpu sink coresight: Take hotplug lock in enable_source_store() for Sysfs mode coresight: Move CPU hotplug callbacks to core layer coresight: Manage activated path during CPU hotplug Yabin Cui (1): coresight: trbe: Save and restore state across CPU low power state drivers/hwtracing/coresight/coresight-catu.c | 1 + drivers/hwtracing/coresight/coresight-core.c | 337 ++++++++++++-- drivers/hwtracing/coresight/coresight-ctcu-core.c | 1 + drivers/hwtracing/coresight/coresight-cti-core.c | 69 ++- drivers/hwtracing/coresight/coresight-cti-sysfs.c | 2 +- drivers/hwtracing/coresight/coresight-dummy.c | 1 + drivers/hwtracing/coresight/coresight-etb10.c | 1 + drivers/hwtracing/coresight/coresight-etm3x-core.c | 55 ++- drivers/hwtracing/coresight/coresight-etm4x-core.c | 491 ++++++--------------- drivers/hwtracing/coresight/coresight-etm4x.h | 62 --- drivers/hwtracing/coresight/coresight-funnel.c | 1 + drivers/hwtracing/coresight/coresight-replicator.c | 1 + drivers/hwtracing/coresight/coresight-stm.c | 1 + drivers/hwtracing/coresight/coresight-syscfg.c | 22 +- drivers/hwtracing/coresight/coresight-syscfg.h | 2 + drivers/hwtracing/coresight/coresight-sysfs.c | 10 + drivers/hwtracing/coresight/coresight-tmc-core.c | 1 + drivers/hwtracing/coresight/coresight-tpda.c | 1 + drivers/hwtracing/coresight/coresight-tpdm.c | 1 + drivers/hwtracing/coresight/coresight-tpiu.c | 1 + drivers/hwtracing/coresight/coresight-trbe.c | 85 ++++ drivers/hwtracing/coresight/ultrasoc-smb.c | 1 + include/linux/coresight.h | 55 ++- 23 files changed, 687 insertions(+), 515 deletions(-) --- base-commit: 559d6c380ea0a27e71d0269410301303515e4179 change-id: 20250909-arm_coresight_power_management_fix-139873f942e8 Best regards, -- Leo Yan <leo.yan(a)arm.com>

2 days, 11 hours

[PATCH 0/6] coresight: Add format attribute for setting the timestamp interval

by James Clark

1 week

[PATCH v2 0/6] coresight: Add format attribute for setting the timestamp interval

by James Clark

Do some cleanups then add a new format attribute to set the timestamp interval for ETMv4 in Perf mode. The current interval is too high for most use cases, and particularly on the FVP the number of timestamps generated is excessive. Although it would be good to make only SYNC timestamps the default and have counter timestamps opt-in, this would be a breaking change. We can always do that later, or disable counter timestamps from Perf. This is added as an event format attribute, rather than a Coresight config because it's something that the driver is already configuring automatically in Perf mode with any unused counter, so it's not possible to modify this with a config. Applies to coresight/next Signed-off-by: James Clark <james.clark(a)linaro.org> --- Changes in v2: - Only show the attribute for ETMv4 to improve usability and fix the arm32 build error. Wrapping everything in IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM4X) isn't ideal, but the -perf.c file is shared between ETMv3 and ETMv4, and there is already precedent for doing it this way. - Link to v1: https://lore.kernel.org/r/20250811-james-cs-syncfreq-v1-0-b001cd6e3404@lina… --- James Clark (6): coresight: Change syncfreq to be a u8 coresight: Fix holes in struct etmv4_config coresight: Repack struct etmv4_drvdata coresight: Refactor etm4_config_timestamp_event() coresight: Add format attribute for setting the timestamp interval coresight: docs: Document etm4x ts_interval Documentation/trace/coresight/coresight.rst | 14 +++ drivers/hwtracing/coresight/coresight-etm-perf.c | 13 ++- drivers/hwtracing/coresight/coresight-etm4x-core.c | 110 +++++++++++++-------- drivers/hwtracing/coresight/coresight-etm4x.h | 86 ++++++++++------ 4 files changed, 151 insertions(+), 72 deletions(-) --- base-commit: a80198ba650f50d266d7fc4a6c5262df9970f9f2 change-id: 20250724-james-cs-syncfreq-7c2257a38ed3 Best regards, -- James Clark <james.clark(a)linaro.org>

1 week, 1 day

Re: [PATCH v5 2/3] coresight: Reorder coresight_device_release to match coresight_register

by Mike Leach

On Thu, 25 Sept 2025 at 16:04, Sean Anderson <sean.anderson(a)linux.dev> wrote: > > To make it easier to determine where to add new release actions, reorder > the actions in coresight_device_release to be the reverse of > coresight_register. > > Signed-off-by: Sean Anderson <sean.anderson(a)linux.dev> > --- > > Changes in v5: > - New > > drivers/hwtracing/coresight/coresight-core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c > index 022c8384b98d..305b1773cfbe 100644 > --- a/drivers/hwtracing/coresight/coresight-core.c > +++ b/drivers/hwtracing/coresight/coresight-core.c > @@ -1046,8 +1046,8 @@ static void coresight_device_release(struct device *dev) > { > struct coresight_device *csdev = to_coresight_device(dev); > > - fwnode_handle_put(csdev->dev.fwnode); > free_percpu(csdev->perf_sink_id_map.cpu_map); > + fwnode_handle_put(csdev->dev.fwnode); > kfree(csdev); > } > > -- > 2.35.1.1320.gc452695387.dirty > Reviewed-by: Mike Leach <mike.leach(a)linaro.org> -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

1 week, 6 days

Re: [PATCH v5 1/3] coresight: Fix fwnode leak in coresight_register error path

by Mike Leach

On Thu, 25 Sept 2025 at 16:04, Sean Anderson <sean.anderson(a)linux.dev> wrote: > > If registering the CPU map fails, we need to put the fwnode. free_percpu > works when called with a NULL pointer, so just use > coresight_device_release. > > Fixes: 5ad628a76176 ("coresight: Use per-sink trace ID maps for Perf sessions") > Signed-off-by: Sean Anderson <sean.anderson(a)linux.dev> > --- > > (no changes since v4) > > Changes in v4: > - New > > drivers/hwtracing/coresight/coresight-core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c > index fa758cc21827..022c8384b98d 100644 > --- a/drivers/hwtracing/coresight/coresight-core.c > +++ b/drivers/hwtracing/coresight/coresight-core.c > @@ -1352,7 +1352,7 @@ struct coresight_device *coresight_register(struct coresight_desc *desc) > raw_spin_lock_init(&csdev->perf_sink_id_map.lock); > csdev->perf_sink_id_map.cpu_map = alloc_percpu(atomic_t); > if (!csdev->perf_sink_id_map.cpu_map) { > - kfree(csdev); > + coresight_device_release(&csdev->dev); > ret = -ENOMEM; > goto err_out; > } > -- > 2.35.1.1320.gc452695387.dirty > Reviewed-by: Mike Leach <mike.leach(a)linaro.org> -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

1 week, 6 days

Re: [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path

by Mike Leach

Hi, On Tue, 23 Sept 2025 at 02:49, Jie Gan <jie.gan(a)oss.qualcomm.com> wrote: > > > > On 9/23/2025 1:31 AM, Carl Worth wrote: > > Jie Gan <jie.gan(a)oss.qualcomm.com> writes: > >> From: Carl Worth <carl(a)os.amperecomputing.com> > >> > >> The handle is essential for retrieving the AUX_EVENT of each CPU and is > >> required in perf mode. It has been added to the coresight_path so that > >> dependent devices can access it from the path when needed. > > > > I'd still like to have the original command I used to trigger the bug in > > the commit message. I really like having reproduction steps captured in > > commit messages when I look back at commits in the future. So, that was: > > > > perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null > > > > Sure, I’ll include your commit message in the formal patch series, I > think it's V3 since you have submitted two versions, if you're okay with > me sending it out. > > >> /** > >> * struct coresight_path - data needed by enable/disable path > >> - * @path_list: path from source to sink. > >> - * @trace_id: trace_id of the whole path. > >> + * @path_list: path from source to sink. > >> + * @trace_id: trace_id of the whole path. > >> + * struct perf_output_handle: handle of the aux_event. > >> */ > > > > Fixing to "@handle" was mentioned in another comment already. > > > > Something about the above still feels a little off to me. It feels like > > we're throwing new data into a structure just because it happens to be > > conveniently at hand for the code paths we're needing, and not because > > it really _belongs_ there. > > > This data is perf specific - not path generic; so I agree that this structure should go elsewhere. I would suggest in the csdev (coresight_device) structure itself. We already have some sink specific data in here e.g. perf_sink_id_map. This could then be set/clear in the functions coresight-etm-perf.c file, where there is a significant amount of code dealing with the perf handle and ensuring it is valid and in scope. This can then be set only when appropriate - for source / sink devices and only when in perf mode, and avoid the need to pass the handle around as API call parameters. Regards Mike. > The core idea behind coresight_path is that it can hold all the data > potentially needed by any device along the path. > > For example with the path ETM->Link->ETR->CATU: > > All the mentioned devices operate by forming a path, for which the > system constructs a coresight_path. This 'path' is then passed to each > device along the route, allowing any device to directly access the > required data from coresight_path instead of receiving it as a separate > argument. > > Imagine a device that requires more than two or three arguments, and you > want to pass them through coresight_enable_path or similar functions... > > For certain coresight_path instances, we may not need the handle or > other parameters. Since these values are initialized, it's acceptable to > leave them as NULL or 0. > > > > Or, maybe it's the right place for it, and the cause of my concern is > > that "path" is an overly-narrow name in struct coresight_path? > > > > It defines the direction of data flow—serving as the path for trace data. > > Thanks, > Jie > > > But if a renaming of this structure would improve the code, I'd also be > > fine with that happening in a subsequent commit, so I won't try to hold > > up the current series based on that. > > > > -Carl > -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

1 week, 6 days

Re: [PATCH v5 3/3] coresight: Fix possible deadlock in coresight_panic_cb

by Leo Yan

On Thu, Sep 25, 2025 at 11:03:42AM -0400, Sean Anderson wrote: > Panics can occur at any time, so taking locks may cause a deadlock (such > as if the panicking CPU held the lock). coresight_panic_cb uses > bus_for_each_dev, but that calls bus_to_subsys which takes > bus_kset->list_lock. > > Instead of registering a single panic notifier and iterating over > coresight devices, register a panic notifier for each coresight device > that requires it (letting the atomic notifier list handle iteration). > atomic_notifier_chain_unregister will just return -ENOENT if a notifier > block isn't on the list, so it's safe to call when we haven't registered > a notifier. > > Fixes: 46006ceb5d02 ("coresight: core: Add provision for panic callbacks") > Signed-off-by: Sean Anderson <sean.anderson(a)linux.dev> Reviewed-by: Leo Yan <leo.yan(a)arm.com>

2 weeks

Re: [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path

by Carl Worth

Jie Gan <jie.gan(a)oss.qualcomm.com> writes: > On 9/23/2025 1:31 AM, Carl Worth wrote: >> I'd still like to have the original command I used to trigger the bug in >> the commit message. I really like having reproduction steps captured in >> commit messages when I look back at commits in the future. So, that was: >> >> perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null > > Sure, I’ll include your commit message in the formal patch series, I > think it's V3 since you have submitted two versions, if you're okay with > me sending it out. Yes. Please do. And thank you. > The core idea behind coresight_path is that it can hold all the data > potentially needed by any device along the path. > > For example with the path ETM->Link->ETR->CATU: OK. That makes sense to me. The name of coresight_path definitely threw me off, since I interpreted it as being a description of the path, not a container for data to be consumed along the path. -Carl

2 weeks, 1 day

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight