CoreSight

coresight@lists.linaro.org

6 participants
2804 discussions

Re: [PATCH v2 2/2] coresight: tnoc: Fix clock refcount imbalance on platform remove

by Leo Yan

On Thu, Jul 02, 2026 at 04:54:20PM +0800, Jie Gan wrote: [...] > Resume the device with pm_runtime_get_sync() before tearing it down so > the clock is enabled again and balances the devm-managed disable. Then > pm_runtime_set_suspended() and pm_runtime_put_noidle() leave the device > in a coherent runtime PM state (suspended, usage count balanced) once > the devm action has disabled the clock. > > Fixes: 1abc1b212eff ("coresight: Appropriately disable programming clocks") > Signed-off-by: Jie Gan <jie.gan(a)oss.qualcomm.com> Reviewed-by: Leo Yan <leo.yan(a)arm.com>

2 weeks, 1 day

[PATCH v2 0/4] coresight: Prevent per-thread events from sharing a sink

by James Clark

Concurrent per-thread events results in a WARN on N1SDP which leads to the realization that per-thread events shouldn't have been sharing sinks in the first place. This slips through because different events will have the same PID if owned by the same process, and we only check the PID and nothing else. That results in unexpected WARNs because it looks like we assumed it couldn't happen (although exclusive PMU rules allow it). But even if it was supported it would result in trace from the wrong thread in another event's per-thread buffer, so we should disallow it. Fix it everywhere the same PID checking logic was copy pasted. Then the PIDs can be dropped from a few structs as they are now unused. Signed-off-by: James Clark <james.clark(a)linaro.org> --- Changes in v2: - Fix inherited events by following event->parent - Link to v1: https://lore.kernel.org/r/20260709-james-cs-multiple-per-threads-v1-0-d384e… --- James Clark (4): coresight: tmc-etr: Prevent per-thread events from sharing a sink coresight: tmc-etf: Prevent per-thread events from sharing a sink coresight: etb10: Prevent per-thread events from sharing a sink coresight: ultrasoc-smb: Prevent per-thread events from sharing a sink drivers/hwtracing/coresight/coresight-core.c | 31 ++++++++++++++++++++++++ drivers/hwtracing/coresight/coresight-etb10.c | 30 ++++++----------------- drivers/hwtracing/coresight/coresight-priv.h | 2 -- drivers/hwtracing/coresight/coresight-tmc-core.c | 2 -- drivers/hwtracing/coresight/coresight-tmc-etf.c | 23 ++++++------------ drivers/hwtracing/coresight/coresight-tmc-etr.c | 20 +++++---------- drivers/hwtracing/coresight/coresight-tmc.h | 2 +- drivers/hwtracing/coresight/ultrasoc-smb.c | 22 +++++------------ drivers/hwtracing/coresight/ultrasoc-smb.h | 5 ++-- include/linux/coresight.h | 3 +++ 10 files changed, 64 insertions(+), 76 deletions(-) --- base-commit: 98495b5a4d77dd22e106f462b76e1093a55b29a7 change-id: 20260708-james-cs-multiple-per-threads-ed1d25ed1734 Best regards, -- James Clark <james.clark(a)linaro.org>

2 weeks, 1 day

Re: [PATCH v2 1/2] coresight: Fix clock refcount imbalance on platform remove

by Leo Yan

On Thu, Jul 02, 2026 at 04:54:19PM +0800, Jie Gan wrote: [...] > static void etm4_remove_platform_dev(struct platform_device *pdev) > { > struct etmv4_drvdata *drvdata = dev_get_drvdata(&pdev->dev); > > if (drvdata) > etm4_remove_dev(drvdata); I understood this is not an issue caused by this patch, could you refine a bit as blow so can be consistent: if (WARN_ON(!drvdata)) return; > + /* > + * Resume the device so its clocks are enabled again, balancing the > + * clk_disable_unprepare() that devm runs when the driver detaches. > + * Then mark it suspended and drop the usage count taken here. > + */ > + pm_runtime_get_sync(&pdev->dev); etm4_remove_dev(drvdata); > pm_runtime_disable(&pdev->dev); > + pm_runtime_set_suspended(&pdev->dev); > + pm_runtime_put_noidle(&pdev->dev); > } With above change: Reviewed-by: Leo Yan <leo.yan(a)arm.com>

2 weeks, 1 day

[PATCH 0/4] coresight: Prevent per-thread events from sharing a sink

by James Clark

Concurrent per-thread events results in a WARN on N1SDP which leads to the realization that per-thread events shouldn't have been sharing sinks in the first place. This slips through because different events will have the same PID if owned by the same process, and we only check the PID and nothing else. That results in unexpected WARNs because it looks like we assumed it couldn't happen (although exclusive PMU rules allow it). But even if it was supported it would result in trace from the wrong thread in another event's per-thread buffer, so we should disallow it. Fix it everywhere the same PID checking logic was copy pasted. Then the PIDs can be dropped from a few structs as they are now unused. Signed-off-by: James Clark <james.clark(a)linaro.org> --- James Clark (4): coresight: tmc-etr: Prevent per-thread events from sharing a sink coresight: tmc-etf: Prevent per-thread events from sharing a sink coresight: etb10: Prevent per-thread events from sharing a sink coresight: ultrasoc-smb: Prevent per-thread events from sharing a sink drivers/hwtracing/coresight/coresight-core.c | 24 +++++++++++++++++++ drivers/hwtracing/coresight/coresight-etb10.c | 30 +++++++----------------- drivers/hwtracing/coresight/coresight-priv.h | 2 -- drivers/hwtracing/coresight/coresight-tmc-core.c | 2 -- drivers/hwtracing/coresight/coresight-tmc-etf.c | 23 ++++++------------ drivers/hwtracing/coresight/coresight-tmc-etr.c | 20 +++++----------- drivers/hwtracing/coresight/coresight-tmc.h | 2 +- drivers/hwtracing/coresight/ultrasoc-smb.c | 22 +++++------------ drivers/hwtracing/coresight/ultrasoc-smb.h | 5 ++-- include/linux/coresight.h | 3 +++ 10 files changed, 57 insertions(+), 76 deletions(-) --- base-commit: 98495b5a4d77dd22e106f462b76e1093a55b29a7 change-id: 20260708-james-cs-multiple-per-threads-ed1d25ed1734 Best regards, -- James Clark <james.clark(a)linaro.org>

2 weeks, 1 day

[PATCH v3 0/1] coresight: fix issue with insufficient claim tags

by Mike Leach

All CoreSight compliant components have an implementation defined number of 0 to 8 claim tag bits in the claim tag registers. These are used to claim the CoreSight resources by system agents. ARM recommends implementions have 4 claim tag bits, though a valid implementation can have 0 claim tags bits. The CoreSight drivers implement a 2 claim tag bit protocol to allow self hosted and external debug agents to manage access to the hardware. However, if there are less than 2 claim tags available the protocol incorrectly returns an error on device claim, as no checks are made. If insufficient claim tags are present in a component then the protocol must return success on claim / disclaim to allow components to be used normally. Add initialisation to read the CLAIMSET bits to establish the number of available claim tag bits, and adjust the claim returns accordingly. Cache the claimtag protocol availablity in the coresight_device to reduce reads for the main claim/disclaim api. changes since v2: 1) consolidated API to remove the API calls using just cs_access, which were used purely to clear down stale self claim tags, replace with a normal coresight_device API for initialisation, to match the claim/disclaim API. This does both the check on availability and the stale tag clearance. Updated all drivers to use the new init functionality 2) Added option for drivers to skip claim tag checking completely for devices with no-compliant hardware, that do not implement registers at the claim tag location, or do not operate correctly to indicate the correct number of claim tags for the device. changes since v1: 1) Added claim tag availability cache into coresight_device when using the main coresight_claim_device() / coresight_disclaim_device() API. Applies to coresight/next Mike Leach (1): coresight: fix issue where coresight component has no claimtags drivers/hwtracing/coresight/coresight-catu.c | 6 +- drivers/hwtracing/coresight/coresight-core.c | 139 ++++++++++++++++-- .../hwtracing/coresight/coresight-cti-core.c | 7 +- drivers/hwtracing/coresight/coresight-etb10.c | 9 +- .../coresight/coresight-etm3x-core.c | 8 +- .../coresight/coresight-etm4x-core.c | 8 +- .../hwtracing/coresight/coresight-funnel.c | 7 +- drivers/hwtracing/coresight/coresight-priv.h | 7 + .../coresight/coresight-replicator.c | 9 +- .../hwtracing/coresight/coresight-tmc-core.c | 7 +- include/linux/coresight.h | 23 ++- 11 files changed, 205 insertions(+), 25 deletions(-) -- 2.43.0

2 weeks, 2 days

Re: [PATCH] coresight: tnoc: Constify amba_id table

by Leo Yan

On Sun, Jul 05, 2026 at 07:19:35PM +0200, Krzysztof Kozlowski wrote: > Static 'struct amba_id' table is not modified so can be changed to const > for more safety. > > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)oss.qualcomm.com> Reviewed-by: Leo Yan <leo.yan(a)arm.com>

2 weeks, 4 days

[PATCH v11 0/9] perf cs-etm: Support thread stack and callchain

by Leo Yan

This series adds thread-stack and synthesized callchain support for Arm CoreSight, which comes from older series [1] but heavily rewritten. CS ETM previously kept last-branch state in a per-trace-queue buffer. That effectively makes the state per CPU, while the call/return history belongs to a thread. This series moves branch tracking to the common thread-stack code. The series records CoreSight branches with thread_stack__event(), uses thread_stack__br_sample() for last branch entries, flushes thread stacks after decoder resets. A decoder reset between AUX trace buffers is treated as a global trace discontinuity, so all thread stacks are flushed, so avoids carrying stale call/return history across a trace discontinuity. One limitation remains for instructions emulated by the kernel. In that case the exception return address may not match the return address stored in the thread stack, because after exception return can be one instruction ahead. The stack can still recover when a later return matches an upper caller. Given emulated instructions are not the common target for performance callchain analysis. Supporting this would require extending the common thread-stack path to accept both the real target address and an adjusted address for stack matching, so this series leaves that extra complexity out. The series has been tested on Orion6 board: perf test 136 -vvv 136: CoreSight synthesized callchain: --- start --- test child forked, pid 3539 ---- end(0) ---- 136: CoreSight synthesized callchain : Ok perf script --itrace=g16i10il64 callchain_test 17468 [005] 1031003.229943: 10 instructions: aaaac32507c4 main+0x8 (/home/kernel/leoy/test_cs_callchain/callchain_test) ffff90bd225c __libc_start_call_main+0x7c (/usr/lib/aarch64-linux-gnu/libc.so.6) ffff90bd233c call_init+0x9c (inlined) ffff90bd233c __libc_start_main_impl+0x9c (inlined) aaaac3250670 _start+0x30 (/home/kernel/leoy/test_cs_callchain/callchain_test) callchain_test 17468 [005] 1031003.229943: 10 instructions: aaaac3250774 do_svc+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test) aaaac3250798 print+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test) aaaac32507b0 foo+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test) aaaac32507c8 main+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test) ffff90bd225c __libc_start_call_main+0x7c (/usr/lib/aarch64-linux-gnu/libc.so.6) ffff90bd233c call_init+0x9c (inlined) ffff90bd233c __libc_start_main_impl+0x9c (inlined) aaaac3250670 _start+0x30 (/home/kernel/leoy/test_cs_callchain/callchain_test) callchain_test 17468 [005] 1031003.229944: 10 instructions: ffff800080010c20 vectors+0x420 ([kernel.kallsyms]) aaaac3250784 do_svc+0x1c (/home/kernel/leoy/test_cs_callchain/callchain_test) aaaac3250798 print+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test) aaaac32507b0 foo+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test) aaaac32507c8 main+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test) ffff90bd225c __libc_start_call_main+0x7c (/usr/lib/aarch64-linux-gnu/libc.so.6) ffff90bd233c call_init+0x9c (inlined) ffff90bd233c __libc_start_main_impl+0x9c (inlined) aaaac3250670 _start+0x30 (/home/kernel/leoy/test_cs_callchain/callchain_test) Note, the test fails on Juno board which is caused by many discontinuity packets (mainly caused by NO_SYNC elem). This is likely caused by the FIFO overflow on the path. [1] https://lore.kernel.org/linux-arm-kernel/20200220052701.7754-1-leo.yan@lina… Signed-off-by: Leo Yan <leo.yan(a)arm.com> --- Changes in v11: - Rebase on latest perf-tools-next. - Verified with "perf test coresight" and no regression. - Link to v10: https://lore.kernel.org/r/20260617-b4-arm_cs_callchain_support_v1-v10-0-e8b… Changes in v10: - Change to syscall(SYS_gettid) for build failure on x86 (James). - Extracted sample thread stack into cs_etm__sample_branch_stack(). - Link to v9: https://lore.kernel.org/r/20260616-b4-arm_cs_callchain_support_v1-v9-0-f8fa… Changes in v9: - Added patch 01 to fixed thread leak during trace queue init (sashiko). - Added check in instruction and branch samples in cs_etm__add_stack_event() (sashiko). - Released frontend_thread properly in cs_etm__context() (sashiko). - Refined cs_etm__flush_all_stack() to use switch (sashiko). - Gathered James' review tags. - Rebased on the latest perf-tools-next. - Link to v8: https://lore.kernel.org/r/20260611-b4-arm_cs_callchain_support_v1-v8-0-7379… Changes in v8: - Updated test_arm_coresight_disasm.sh to pass "--itrace=b" and updated examples in arm-cs-trace-disasm.py (James). - Removed static annotation in callchain workload and renamed functions with prefix "callchain_" to reduce naming conflict (James). - For callchain test pre-condition check, removed the aarch64 check and added the root permission check (James). - Resolved the shellcheck errors (James). - Link to v7: https://lore.kernel.org/r/20260611-b4-arm_cs_callchain_support_v1-v7-0-1ba7… Changes in v7: - Rebased on the latest perf-tools-next. - Used struct_size() for allocation callchain struct (James). - Added a helper cs_etm__packet_has_taken_branch() (James). - Minor improvements for the callchain test (used record-ctl FIFO and reworked the validation callstack push / pop). - Link to v6: https://lore.kernel.org/r/20260526-b4-arm_cs_callchain_support_v1-v6-0-f9f4… Changes in v6: - Heavily rewrote the patches since restarted the work after 6 years. - Changed to use the common thread-stack for branch stack and callchain management. - Added a callchain test. - Link to v5: https://lore.kernel.org/linux-arm-kernel/20200220052701.7754-1-leo.yan@lina… Changes in v5: - Addressed Mike's suggestion for performance improvement for function cs_etm__instr_addr() for quick calculation for non T32; - Removed the patch 'perf cs-etm: Synchronize instruction sample with the thread stack' (Mike); - Fixed the issue for exception is taken for branch target address accessing, for the branch sample and stack thread handling, the related patches are 01, 02, 07; - Fixed the stack thread handling for instruction emulation and single step with patches 08, 09. - Link to v4: https://lore.kernel.org/linux-arm-kernel/20200203020716.31832-1-leo.yan@lin… --- Leo Yan (9): perf cs-etm: Fix thread leaks on trace queue init failure perf cs-etm: Filter synthesized branch samples perf cs-etm: Decode ETE exception packets perf cs-etm: Refactor instruction size handling perf cs-etm: Use thread-stack for last branch entries perf cs-etm: Flush thread stacks after decoder reset perf cs-etm: Support call indentation perf cs-etm: Synthesize callchains for instruction samples perf test: Add Arm CoreSight callchain test tools/perf/Documentation/perf-test.txt | 6 +- tools/perf/scripts/python/arm-cs-trace-disasm.py | 9 +- tools/perf/tests/builtin-test.c | 1 + tools/perf/tests/shell/coresight/callchain.sh | 172 ++++++++++ .../shell/coresight/test_arm_coresight_disasm.sh | 4 +- tools/perf/tests/tests.h | 1 + tools/perf/tests/workloads/Build | 2 + tools/perf/tests/workloads/callchain.c | 33 ++ tools/perf/util/cs-etm.c | 377 +++++++++++++-------- 9 files changed, 454 insertions(+), 151 deletions(-) --- base-commit: f6e5090f63b0a9f4c4c42c82348ade4132495ee7 change-id: 20260521-b4-arm_cs_callchain_support_v1-2c2a70719bcc Best regards, -- Leo Yan <leo.yan(a)arm.com>

3 weeks, 1 day

Re: [PATCH v10 0/9] perf cs-etm: Support thread stack and callchain

by Leo Yan

On Tue, Jun 30, 2026 at 04:57:34PM -0700, Namhyung Kim wrote: [...] > Hmm.. it's not applying anymore.. Please rebase. Thanks for reminding. I'll rebase it and resend today.

3 weeks, 2 days

Re: [PATCH 1/2] coresight: Fix clock refcount imbalance on platform remove

by Leo Yan

On Thu, Jul 02, 2026 at 09:56:05AM +0800, Jie Gan wrote: > static void funnel_platform_remove(struct platform_device *pdev) > { > struct funnel_drvdata *drvdata = dev_get_drvdata(&pdev->dev); > > if (WARN_ON(!drvdata)) > return; > > - funnel_remove(&pdev->dev); > + /* > + * Resume the device so its clocks are enabled again, balancing the > + * clk_disable_unprepare() that devm runs when the driver detaches. > + * Then mark it suspended and drop the usage count taken here. > + */ > pm_runtime_get_sync(&pdev->dev); > + funnel_remove(&pdev->dev); > pm_runtime_disable(&pdev->dev); > + pm_runtime_set_suspended(&pdev->dev); > + pm_runtime_put_noidle(&pdev->dev); LGTM. Thanks for writing up the comment. Please proceed.

3 weeks, 2 days

Re: [PATCH 1/2] coresight: Fix clock refcount imbalance on platform remove

by Leo Yan

On Wed, Jul 01, 2026 at 02:05:02PM +0800, Jie Gan wrote: > After probe, pm_runtime_put() allows the device to suspend and the > runtime suspend callback disables the same clocks. During remove the > device is left runtime suspended, so pm_runtime_disable() freezes it > with the clocks already disabled. The devm cleanup that runs afterwards > calls clk_disable_unprepare() a second time, underflowing the clock > enable refcount. Thanks for fixing the issue. The problem is that if the device has already been runtime suspended and its clock has been disabled, afterwards when remove the device, the devm cleanup disables the clock again, resulting in clock count underflow. > diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c > index 0abc11f0690c..4c5b94640e6a 100644 > --- a/drivers/hwtracing/coresight/coresight-funnel.c > +++ b/drivers/hwtracing/coresight/coresight-funnel.c > @@ -334,6 +334,7 @@ static void funnel_platform_remove(struct platform_device *pdev) > return; > > funnel_remove(&pdev->dev); > + pm_runtime_get_sync(&pdev->dev); > pm_runtime_disable(&pdev->dev); Let's use the funnel driver for the discussion. Once we agree on the approach, we can apply the same change to the other CoreSight platform drivers. How about the following teardown? static void funnel_platform_remove(struct platform_device *pdev) { struct funnel_drvdata *drvdata = dev_get_drvdata(&pdev->dev); + int ret; if (WARN_ON(!drvdata)) return; + ret = pm_runtime_get_sync(&pdev->dev); + if (ret < 0) + dev_warn(&pdev->dev, "failed to resume before remove: %d\n", ret); + funnel_remove(&pdev->dev); + pm_runtime_disable(&pdev->dev); + pm_runtime_set_suspended(&pdev->dev); + pm_runtime_put_noidle(&pdev->dev); } The idea is to first resume the device with pm_runtime_get_sync(), then perform the remove (which is safe if they need to access or clean up hardware state), and finally clean up the runtime PM states. I mainly referred to drivers/iio/adc/stm32-adc.c. Thanks, Leo

3 weeks, 2 days

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight