CoreSight

coresight@lists.linaro.org

8 participants
2690 discussions

Re: [PATCH v4 3/9] coresight: etm4x: fix leaked trace id

by Leo Yan

On Wed, Apr 15, 2026 at 09:21:21AM +0800, Jie Gan wrote: [...] > > > > @@ -918,8 +918,10 @@ static int etm4_enable_sysfs(struct coresight_device *csdev, struct coresight_pa > > > > cscfg_config_sysfs_get_active_cfg(&cfg_hash, &preset); > > > > if (cfg_hash) { > > > > ret = cscfg_csdev_enable_active_config(csdev, cfg_hash, preset); > > > > - if (ret) > > > > + if (ret) { > > > > + etm4_release_trace_id(drvdata); > > > > > > If so, even an ID is reserved for failures, and the ID map is big enough > > > for each CPU, we don't need to worry memory leak or ID used out issue ? > > > > However, in theory, this could lead to an ID leak, > > so it would be better to release it in error cases. > > What I am thinking is as SoCs continue to grow more complex with an > increasing number of subsystems, trace IDs may be exhausted in the near > future. (that's why we have dynamic trace ID allocation/release). Thanks for the input. I am wandering if we can use "dev->devt" as the trace ID. A device's major/minor number is unique in kernel and dev_t is defined as u32: typedef u32 __kernel_dev_t; And we can consolidate this for both SYSFS and PERF modes. Thanks, Leo

6 months, 2 weeks

Re: [RFC PATCH 00/12] Add Linux RISC-V trace support via CoreSight

by Zane Leung

Hi Bo, On 4/15/2026 8:10 AM, Bo Gan wrote: > Hi Zane, Anup, > > On 4/14/26 02:04, Zane Leung wrote: >> >> On 4/14/2026 3:23 PM, Anup Patel wrote: >>> On Tue, Apr 14, 2026 at 9:12 AM Zane Leung <liangzhen(a)linux.spacemit.com> wrote: >>>> From: liangzhen <zhen.liang(a)spacemit.com> >>>> >>>> This series adds Linux RISC-V trace support via CoreSight, implementing RISC-V >>>> trace drivers within the CoreSight framework and integrating them with perf tools. >>>> The K3 SoC contains RISC-V Encoder, Funnel, ATB, CoreSight Funnel, and CoreSight TMC >>>> components, which can be directly leveraged through the existing CoreSight infrastructure. >>>> >>>> Linux RISC-V trace support form Anup Patel: >>>> (https://patchwork.kernel.org/project/linux-riscv/cover/20260225062448.40279…) >>>> which currently lacks ATB component support and guidance on reusing CoreSight components. >>> What stops you from adding RISC-V trace funnel and ATB bridge drivers >>> on top of this series ? >>> >> Firstly, my works started much earlier than this series. Secondly, it is difficult to add the coresight funnel and coresight tmc components to this series. Based on the coresight framework, I can directly reuse them. >> >>> >>>> The series includes: >>>> - RISC-V trace driver implementation within the CoreSight framework >>> The RISC-V trace very different from the CoreSight framework in many ways: >>> 1) Types of components supported >>> 2) Trace packet formats >>> 3) The way MMIO based components are discoverd >>> 4) ... and more ... >> 1) I believe that RISC-V tracing is coresight-alike, where have encoders/funnel/sink/bridge that are described through DT and controlled by MMIO. >> 2) I think the difference in package format is nothing more than the coresight frame generated by the ATB component to distinguish the trace source. After removing it, it becomes riscv trace data. >> 3) The current CoreSight framework code does not introduce this mechanism, it is described through DT. >>>> - RISC-V Trace Encoder, Funnel, and ATB Bridge drivers as CoreSight devices >>>> - RISC-V trace PMU record capabilities and parsing events in perf. >>>> - RISC-V Nexus Trace decoder for perf tools >>>> >>>> Any comments or suggestions are welcome. >>>> >>>> Verification on K3 SoC: >>>> To verify this patch series on K3 hardware, the following device tree are required: >>>> 1. RISC-V Trace Encoder node (8) >>>> 2. RISC-V ATB Bridge node (8) >>>> 3. RISC-V Trace Funnel node (2) >>>> 3. CoreSight Funnel configuration for RISC-V (1) >>>> 4. CoreSight TMC configuration for trace buffer (1) >>>> >>>> /{ >>>> dummy_clk: apb-pclk { >>>> compatible = "fixed-clock"; >>>> #clock-cells = <0x0>; >>>> clock-output-names = "clk14mhz"; >>>> clock-frequency = <14000000>; >>>> }; >>>> >>>> >>>> soc: soc { >>>> #address-cells = <2>; >>>> #size-cells = <2>; >>>> >>>> encoder0: encoder@d9002000 { >>>> compatible = "riscv,trace-encoder"; >>>> reg = <0x0 0xd9002000 0x0 0x1000>; >>>> cpus = <&cpu_0>; >>>> out-ports { >>>> port { >>>> cluster0_encoder0_out_port: endpoint { >>>> remote-endpoint = <&cluster0_bridge0_in_port>; >>>> }; >>>> }; >>>> }; >>>> }; >>>> >>>> bridge0: bridge@d9003000 { >>>> compatible = "riscv,trace-atbbridge"; >>>> reg = <0x0 0xd9003000 0x0 0x1000>; >>>> cpus = <&cpu_0>; >>>> out-ports { >>>> port { >>>> cluster0_bridge0_out_port: endpoint { >>>> remote-endpoint = <&cluster0_funnel_in_port0>; >>>> }; >>>> }; >>>> }; >>>> in-ports { >>>> port { >>>> cluster0_bridge0_in_port: endpoint { >>>> remote-endpoint = <&cluster0_encoder0_out_port>; >>>> }; >>>> }; >>>> }; >>>> }; >>>> >>>> ... >>>> >>>> cluster0_funnel: funnel@d9000000 { >>>> compatible = "riscv,trace-funnel"; >>>> reg = <0x0 0xd9000000 0x0 0x1000>; >>>> cpus = <&cpu_0>, <&cpu_1>, <&cpu_2>, <&cpu_3>; >>>> riscv,timestamp-present; >>>> out-ports { >>>> port { >>>> cluster0_funnel_out_port: endpoint { >>>> remote-endpoint = <&main_funnel_in_port0>; >>>> }; >>>> }; >>>> }; >>>> in-ports { >>>> #address-cells = <1>; >>>> #size-cells = <0>; >>>> >>>> port@0 { >>>> reg = <0>; >>>> cluster0_funnel_in_port0: endpoint { >>>> remote-endpoint = <&cluster0_bridge0_out_port>; >>>> }; >>>> }; >>>> >>>> port@1 { >>>> reg = <1>; >>>> cluster0_funnel_in_port1: endpoint { >>>> remote-endpoint = <&cluster0_bridge1_out_port>; >>>> }; >>>> }; >>>> >>>> port@2 { >>>> reg = <2>; >>>> cluster0_funnel_in_port2: endpoint { >>>> remote-endpoint = <&cluster0_bridge2_out_port>; >>>> }; >>>> }; >>>> >>>> port@3 { >>>> reg = <3>; >>>> cluster0_funnel_in_port3: endpoint { >>>> remote-endpoint = <&cluster0_bridge3_out_port>; >>>> }; >>>> }; >>>> }; >>>> }; >>>> >>>> cluster1_funnel: funnel@d9010000 { >>>> compatible = "riscv,trace-funnel"; >>>> reg = <0x0 0xd9010000 0x0 0x1000>; >>>> cpus = <&cpu_4>, <&cpu_5>, <&cpu_6>, <&cpu_7>; >>>> riscv,timestamp-present; >>>> out-ports { >>>> port { >>>> cluster1_funnel_out_port: endpoint { >>>> remote-endpoint = <&main_funnel_in_port1>; >>>> }; >>>> }; >>>> }; >>>> in-ports { >>>> #address-cells = <1>; >>>> #size-cells = <0>; >>>> >>>> port@0 { >>>> reg = <0>; >>>> cluster1_funnel_in_port0: endpoint { >>>> remote-endpoint = <&cluster1_bridge0_out_port>; >>>> }; >>>> }; >>>> >>>> port@1 { >>>> reg = <1>; >>>> cluster1_funnel_in_port1: endpoint { >>>> remote-endpoint = <&cluster1_bridge1_out_port>; >>>> }; >>>> }; >>>> >>>> port@2 { >>>> reg = <2>; >>>> cluster1_funnel_in_port2: endpoint { >>>> remote-endpoint = <&cluster1_bridge2_out_port>; >>>> }; >>>> }; >>>> >>>> port@3 { >>>> reg = <3>; >>>> cluster1_funnel_in_port3: endpoint { >>>> remote-endpoint = <&cluster1_bridge3_out_port>; >>>> }; >>>> }; >>>> }; >>>> }; >>>> >>>> main_funnel: funnel@d9042000 { >>>> compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; >>> Is it legally allowed to mix and match ARM coresight IPs with >>> RISC-V trace components at hardware level ? >> The ATB Bridge allows sending RISC-V trace to Arm CoreSight infrastructure (instead of RISC-V compliant sink defined in this document) as an ATB initiator. see: >> https://github.com/riscv-non-isa/riscv-nexus-trace/blob/105dc1c349556622e4d… >> For ATB Bridge, read trace using Coresight components (ETB/TMC/TPIU). see: >> https://github.com/riscv-non-isa/riscv-nexus-trace/blob/105dc1c349556622e4d… >>> >>>> reg = <0x0 0xd9042000 0x0 0x1000>; >>>> clocks = <&dummy_clk>; >>>> clock-names = "apb_pclk"; >>>> out-ports { >>>> port { >>>> main_funnel_out_port: endpoint { >>>> remote-endpoint = <&etf_in_port>; >>>> }; >>>> }; >>>> }; >>>> in-ports { >>>> #address-cells = <1>; >>>> #size-cells = <0>; >>>> >>>> port@0 { >>>> reg = <0>; >>>> main_funnel_in_port0: endpoint { >>>> remote-endpoint = <&cluster0_funnel_out_port>; >>>> }; >>>> }; >>>> >>>> port@1 { >>>> reg = <1>; >>>> main_funnel_in_port1: endpoint { >>>> remote-endpoint = <&cluster1_funnel_out_port>; >>>> }; >>>> }; >>>> }; >>>> }; >>>> >>>> etf: etf@d9043000 { >>>> compatible = "arm,coresight-tmc", "arm,primecell"; >>>> reg = <0x0 0xd9043000 0x0 0x1000>; >>>> clocks = <&dummy_clk>; >>>> clock-names = "apb_pclk"; >>>> out-ports { >>>> port { >>>> etf_out_port: endpoint { >>>> remote-endpoint = <&etr_in_port>; >>>> }; >>>> }; >>>> }; >>>> in-ports { >>>> port { >>>> etf_in_port: endpoint { >>>> remote-endpoint = <&main_funnel_out_port>; >>>> }; >>>> }; >>>> }; >>>> }; >>>> >>>> etr: etr@d9044000 { >>>> compatible = "arm,coresight-tmc", "arm,primecell"; >>>> reg = <0x0 0xd9044000 0x0 0x1000>; >>>> clocks = <&dummy_clk>; >>>> clock-names = "apb_pclk"; >>>> arm,scatter-gather; >>>> in-ports { >>>> port { >>>> etr_in_port: endpoint { >>>> remote-endpoint = <&etf_out_port>; >>>> }; >>>> }; >>>> }; >>>> }; >>>> }; >>>> }; >>>> >>>> Verification case: >>>> >>>> ~ # perf list pmu >>>> rvtrace// [Kernel PMU event] >>>> >>>> ~ # perf record -e rvtrace/@tmc_etr0/ --per-thread uname >>>> Linux >>>> [ perf record: Woken up 1 times to write data ] >>>> [ perf record: Captured and wrote 0.191 MB perf.data ] >>>> ~ # perf script >>>> uname 137 [003] 1 branches: ffffffff80931470 rvtrace_poll_bit+0x38 ([kernel.kallsyms]) => ffffffff80931492 rvtrace_poll_bit+0x5a ([kernel.kallsyms]) >>>> uname 137 [003] 1 branches: ffffffff809328a6 encoder_enable_hw+0x252 ([kernel.kallsyms]) => ffffffff809328ba encoder_enable_hw+0x266 ([kernel.kallsyms]) >>>> uname 137 [003] 1 branches: ffffffff80932c4a encoder_enable+0x82 ([kernel.kallsyms]) => ffffffff80932c36 encoder_enable+0x6e ([kernel.kallsyms]) >>>> uname 137 [003] 1 branches: ffffffff80928198 etm_event_start+0xf0 ([kernel.kallsyms]) => ffffffff809281aa etm_event_start+0x102 ([kernel.kallsyms]) >>>> uname 137 [003] 1 branches: ffffffff809281e6 etm_event_start+0x13e ([kernel.kallsyms]) => ffffffff8092755e coresight_get_sink_id+0x16 ([kernel.kallsyms]) >>>> uname 137 [003] 1 branches: ffffffff8092820e etm_event_start+0x166 ([kernel.kallsyms]) => ffffffff80928226 etm_event_start+0x17e ([kernel.kallsyms]) >>>> uname 137 [003] 1 branches: ffffffff801c3bb4 perf_report_aux_output_id+0x0 ([kernel.kallsyms]) => ffffffff801c3bd6 perf_report_aux_output_id+0x22 ([kernel.kallsyms]) >>>> uname 137 [003] 1 branches: ffffffff801c3c5a perf_report_aux_output_id+0xa6 ([kernel.kallsyms]) => ffffffff801c3bf0 perf_report_aux_output_id+0x3c ([kernel.kallsyms]) >>>> uname 137 [003] 1 branches: ffffffff801c3c40 perf_report_aux_output_id+0x8c ([kernel.kallsyms]) => ffffffff801c3aea __perf_event_header__init_id+0x2a ([kernel.kallsyms]) >>>> uname 137 [003] 1 branches: ffffffff801c3b42 __perf_event_header__init_id+0x82 ([kernel.kallsyms]) => ffffffff801c3b4a __perf_event_header__init_id+0x8a ([kernel.kallsyms]) >>>> uname 137 [003] 1 branches: ffffffff801c3bb0 __perf_event_header__init_id+0xf0 ([kernel.kallsyms]) => ffffffff801c3b58 __perf_event_header__init_id+0x98 ([kernel.kallsyms]) >>>> uname 137 [003] 1 branches: ffffffff8004c658 __task_pid_nr_ns+0x0 ([kernel.kallsyms]) => ffffffff8004c696 __task_pid_nr_ns+0x3e ([kernel.kallsyms]) >>>> uname 137 [003] 1 branches: ffffffff8004c71e __task_pid_nr_ns+0xc6 ([kernel.kallsyms]) => ffffffff8004c6a4 __task_pid_nr_ns+0x4c ([kernel.kallsyms]) >>>> uname 137 [003] 1 branches: ffffffff8004c6e4 __task_pid_nr_ns+0x8c ([kernel.kallsyms]) => ffffffff8004c6e4 __task_pid_nr_ns+0x8c ([kernel.kallsyms]) >>>> ... >>>> >>>> liangzhen (12): >>>> coresight: Add RISC-V support to CoreSight tracing >>>> coresight: Initial implementation of RISC-V trace driver >>>> coresight: Add RISC-V Trace Encoder driver >>>> coresight: Add RISC-V Trace Funnel driver >>>> coresight: Add RISC-V Trace ATB Bridge driver >>>> coresight rvtrace: Add timestamp component support for encoder and >>>> funnel >>>> coresight: Add RISC-V PMU name support >>>> perf tools: riscv: making rvtrace PMU listable >>>> perf tools: Add RISC-V trace PMU record capabilities >>>> perf tools: Add Nexus RISC-V Trace decoder >>>> perf symbols: Add RISC-V PLT entry sizes >>>> perf tools: Integrate RISC-V trace decoder into auxtrace >>>> >>>> drivers/hwtracing/Kconfig | 2 + >>>> drivers/hwtracing/coresight/Kconfig | 46 +- >>>> drivers/hwtracing/coresight/Makefile | 6 + >>>> drivers/hwtracing/coresight/coresight-core.c | 8 + >>>> .../hwtracing/coresight/coresight-etm-perf.c | 1 - >>>> .../hwtracing/coresight/coresight-etm-perf.h | 21 + >>>> .../hwtracing/coresight/coresight-platform.c | 1 - >>>> .../hwtracing/coresight/coresight-tmc-etf.c | 4 + >>>> .../hwtracing/coresight/coresight-tmc-etr.c | 4 + >>>> .../hwtracing/coresight/rvtrace-atbbridge.c | 239 +++ >>>> drivers/hwtracing/coresight/rvtrace-core.c | 135 ++ >>>> .../coresight/rvtrace-encoder-core.c | 562 +++++++ >>>> .../coresight/rvtrace-encoder-sysfs.c | 363 +++++ >>>> drivers/hwtracing/coresight/rvtrace-encoder.h | 151 ++ >>>> drivers/hwtracing/coresight/rvtrace-funnel.c | 337 ++++ >>>> drivers/hwtracing/coresight/rvtrace-funnel.h | 39 + >>>> .../hwtracing/coresight/rvtrace-timestamp.c | 278 ++++ >>>> .../hwtracing/coresight/rvtrace-timestamp.h | 64 + >>>> include/linux/coresight-pmu.h | 4 + >>>> include/linux/rvtrace.h | 116 ++ >>>> tools/arch/riscv/include/asm/insn.h | 645 ++++++++ >>>> tools/perf/arch/riscv/util/Build | 2 + >>>> tools/perf/arch/riscv/util/auxtrace.c | 490 ++++++ >>>> tools/perf/arch/riscv/util/pmu.c | 20 + >>>> tools/perf/util/Build | 3 + >>>> tools/perf/util/auxtrace.c | 4 + >>>> tools/perf/util/auxtrace.h | 1 + >>>> tools/perf/util/nexus-rv-decoder/Build | 1 + >>>> .../util/nexus-rv-decoder/nexus-rv-decoder.c | 1364 +++++++++++++++++ >>>> .../util/nexus-rv-decoder/nexus-rv-decoder.h | 139 ++ >>>> .../perf/util/nexus-rv-decoder/nexus-rv-msg.h | 190 +++ >>>> tools/perf/util/rvtrace-decoder.c | 1039 +++++++++++++ >>>> tools/perf/util/rvtrace.h | 40 + >>>> tools/perf/util/symbol-elf.c | 4 + >>>> 34 files changed, 6320 insertions(+), 3 deletions(-) >>>> create mode 100644 drivers/hwtracing/coresight/rvtrace-atbbridge.c >>>> create mode 100644 drivers/hwtracing/coresight/rvtrace-core.c >>>> create mode 100644 drivers/hwtracing/coresight/rvtrace-encoder-core.c >>>> create mode 100644 drivers/hwtracing/coresight/rvtrace-encoder-sysfs.c >>>> create mode 100644 drivers/hwtracing/coresight/rvtrace-encoder.h >>>> create mode 100644 drivers/hwtracing/coresight/rvtrace-funnel.c >>>> create mode 100644 drivers/hwtracing/coresight/rvtrace-funnel.h >>>> create mode 100644 drivers/hwtracing/coresight/rvtrace-timestamp.c >>>> create mode 100644 drivers/hwtracing/coresight/rvtrace-timestamp.h >>>> create mode 100644 include/linux/rvtrace.h >>>> create mode 100644 tools/arch/riscv/include/asm/insn.h >>>> create mode 100644 tools/perf/arch/riscv/util/auxtrace.c >>>> create mode 100644 tools/perf/arch/riscv/util/pmu.c >>>> create mode 100644 tools/perf/util/nexus-rv-decoder/Build >>>> create mode 100644 tools/perf/util/nexus-rv-decoder/nexus-rv-decoder.c >>>> create mode 100644 tools/perf/util/nexus-rv-decoder/nexus-rv-decoder.h >>>> create mode 100644 tools/perf/util/nexus-rv-decoder/nexus-rv-msg.h >>>> create mode 100644 tools/perf/util/rvtrace-decoder.c >>>> create mode 100644 tools/perf/util/rvtrace.h >>>> >>>> -- >>>> 2.34.1 >>>> >>> NACK to this approach of retrofitting RISC-V trace into ARM coresight. >> I agree that integrating RISC-V trace directly into CoreSight is not a good approach, so I think we should abstract some of the logic of coresight and reuse it in RISC-V Trace. > > I think we should indeed abstract out some coresight logic so it can be > reused by both coresight/rvtrace, especially the way of handling trace > component topology. The generic logic of building a path from source -> > sink should be common among coresight/rvtrace and for future architecture. > To support ATB use case like the K3, I think the best way to approach this > is to model the atb driver as a separate rvtrace-atb drive and let it > drive the ARM coresight components. Don't treat risc-v trace as another > type of coresight. > > @Zane, can you also clarify that only the 2 X100 clusters have trace > encoders, and the A100 clusters do not? I don't see the 2 A100 clusters > listed in your sample devicetree. If that's the case, then we'll be faced > with heterogeneous trace setup, making it even more complicated. > The A100 clusters also have trace encoders, just like the X100 clusters. The reason I didn't include the two A100 clusters in the sample devicetree is to maintain consistency with the upstream k3.dtsi. >>> >>> Regards, >>> Anup >> >> Thanks, >> Zane > > Bo > Thanks, Zane

6 months, 2 weeks

Re: [PATCH v4 3/9] coresight: etm4x: fix leaked trace id

by Leo Yan

On Mon, Apr 13, 2026 at 03:19:56PM +0100, Yeoreum Yun wrote: > If etm4_enable_sysfs() fails in cscfg_csdev_enable_active_config(), > the trace ID may be leaked because it is not released. > > To address this, call etm4_release_trace_id() when etm4_enable_sysfs() > fails in cscfg_csdev_enable_active_config(). > > Signed-off-by: Yeoreum Yun <yeoreum.yun(a)arm.com> > --- > drivers/hwtracing/coresight/coresight-etm4x-core.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c > index 8ebfd3924143..1bc9f13e33f7 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > @@ -918,8 +918,10 @@ static int etm4_enable_sysfs(struct coresight_device *csdev, struct coresight_pa > cscfg_config_sysfs_get_active_cfg(&cfg_hash, &preset); > if (cfg_hash) { > ret = cscfg_csdev_enable_active_config(csdev, cfg_hash, preset); > - if (ret) > + if (ret) { > + etm4_release_trace_id(drvdata); I am not familiar with the trace ID, seems to me, it just allocate a ID for each tracer from the ID map and then always use this cached ID for the tracers. If so, even an ID is reserved for failures, and the ID map is big enough for each CPU, we don't need to worry memory leak or ID used out issue ? Thanks, Leo > return ret; > + } > } > > raw_spin_lock(&drvdata->spinlock); > -- > LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7} >

6 months, 2 weeks

Re: [PATCH v4 2/9] coresight: etm4x: exclude ss_status from drvdata->config

by Leo Yan

On Mon, Apr 13, 2026 at 03:19:55PM +0100, Yeoreum Yun wrote: > The purpose of TRCSSCSRn register is to show status of > the corresponding Single-shot Comparator Control and input supports. > That means writable field's purpose for reset or restore from idle status > not for configuration. > > Therefore, exclude ss_status from drvdata->config, move it to etm4x_caps. > This includes remove TRCSSCRn from configurable item and > remove saving in etm4_disable_hw(). > > Signed-off-by: Yeoreum Yun <yeoreum.yun(a)arm.com> > --- > .../hwtracing/coresight/coresight-etm4x-cfg.c | 1 - > .../hwtracing/coresight/coresight-etm4x-core.c | 18 +++++------------- > .../coresight/coresight-etm4x-sysfs.c | 7 ++----- > drivers/hwtracing/coresight/coresight-etm4x.h | 4 +++- > 4 files changed, 10 insertions(+), 20 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c > index c302072b293a..d14d7c8a23e5 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c > @@ -86,7 +86,6 @@ static int etm4_cfg_map_reg_offset(struct etmv4_drvdata *drvdata, > off_mask = (offset & GENMASK(11, 5)); > do { > CHECKREGIDX(TRCSSCCRn(0), ss_ctrl, idx, off_mask); > - CHECKREGIDX(TRCSSCSRn(0), ss_status, idx, off_mask); > CHECKREGIDX(TRCSSPCICRn(0), ss_pe_cmp, idx, off_mask); > } while (0); > } else if ((offset >= TRCCIDCVRn(0)) && (offset <= TRCVMIDCVRn(7))) { > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c > index 6443f3717b37..8ebfd3924143 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > @@ -91,7 +91,7 @@ static bool etm4x_sspcicrn_present(struct etmv4_drvdata *drvdata, int n) > const struct etmv4_caps *caps = &drvdata->caps; > > return (n < caps->nr_ss_cmp) && caps->nr_pe && > - (drvdata->config.ss_status[n] & TRCSSCSRn_PC); > + (caps->ss_status[n] & TRCSSCSRn_PC); Nitpick: The naming 'ss_status' is a bit confused for capability. Could we rename 'ss_status' to 'ss_comparator' or a simple one 'ss_cmp' ? > } > > u64 etm4x_sysreg_read(u32 offset, bool _relaxed, bool _64bit) > @@ -571,11 +571,9 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata) > etm4x_relaxed_write32(csa, config->res_ctrl[i], TRCRSCTLRn(i)); > > for (i = 0; i < caps->nr_ss_cmp; i++) { > - /* always clear status bit on restart if using single-shot */ > - if (config->ss_ctrl[i] || config->ss_pe_cmp[i]) > - config->ss_status[i] &= ~TRCSSCSRn_STATUS; > etm4x_relaxed_write32(csa, config->ss_ctrl[i], TRCSSCCRn(i)); > - etm4x_relaxed_write32(csa, config->ss_status[i], TRCSSCSRn(i)); > + /* always clear status and pending bits on restart if using single-shot */ > + etm4x_relaxed_write32(csa, caps->ss_status[i], TRCSSCSRn(i)); It is a bit weird to use caps to write a register. A smooth way is to clear STATUS and PENDING bits based on the read back value: val = etm4x_relaxed_read32(csa, TRCSSCSRn(i)); val &= ~(TRCSSCSRn_STATUS | TRCSSCSRn_PENDING); etm4x_relaxed_write32(csa, val, TRCSSCSRn(i)); > if (etm4x_sspcicrn_present(drvdata, i)) > etm4x_relaxed_write32(csa, config->ss_pe_cmp[i], TRCSSPCICRn(i)); > } > @@ -1053,12 +1051,6 @@ static void etm4_disable_hw(struct etmv4_drvdata *drvdata) > > etm4_disable_trace_unit(drvdata); > > - /* read the status of the single shot comparators */ > - for (i = 0; i < caps->nr_ss_cmp; i++) { > - config->ss_status[i] = > - etm4x_relaxed_read32(csa, TRCSSCSRn(i)); > - } > - > /* read back the current counter values */ > for (i = 0; i < caps->nr_cntr; i++) { > config->cntr_val[i] = > @@ -1501,8 +1493,8 @@ static void etm4_init_arch_data(void *info) > */ > caps->nr_ss_cmp = FIELD_GET(TRCIDR4_NUMSSCC_MASK, etmidr4); > for (i = 0; i < caps->nr_ss_cmp; i++) { > - drvdata->config.ss_status[i] = > - etm4x_relaxed_read32(csa, TRCSSCSRn(i)); > + caps->ss_status[i] = etm4x_relaxed_read32(csa, TRCSSCSRn(i)); > + caps->ss_status[i] &= ~(TRCSSCSRn_STATUS | TRCSSCSRn_PENDING); For init cap, we can use explict way: caps->ss_cmp &= (TRCSSCSRn_PC | TRCSSCSRn_DV | TRCSSCSRn_DA | TRCSSCSRn_INST); > } > /* NUMCIDC, bits[27:24] number of Context ID comparators for tracing */ > caps->numcidc = FIELD_GET(TRCIDR4_NUMCIDC_MASK, etmidr4); > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c > index 50408215d1ac..dd62f01674cf 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c > @@ -1827,8 +1827,6 @@ static ssize_t sshot_ctrl_store(struct device *dev, > raw_spin_lock(&drvdata->spinlock); > idx = config->ss_idx; > config->ss_ctrl[idx] = FIELD_PREP(TRCSSCCRn_SAC_ARC_RST_MASK, val); > - /* must clear bit 31 in related status register on programming */ > - config->ss_status[idx] &= ~TRCSSCSRn_STATUS; > raw_spin_unlock(&drvdata->spinlock); > return size; > } > @@ -1839,10 +1837,11 @@ static ssize_t sshot_status_show(struct device *dev, > { > unsigned long val; > struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent); > + const struct etmv4_caps *caps = &drvdata->caps; > struct etmv4_config *config = &drvdata->config; > > raw_spin_lock(&drvdata->spinlock); > - val = config->ss_status[config->ss_idx]; > + val = caps->ss_status[config->ss_idx]; I think cap->ss_cmp is a good refactoring, but for legacy reason, I am just wandering if we still need config->ss_status so that it can record the lastest status (mainly for STATUS bit and PENDING bit). Otherwise, this Sysfs interface can only provide capability rather than status value. Thanks, Leo > raw_spin_unlock(&drvdata->spinlock); > return scnprintf(buf, PAGE_SIZE, "%#lx\n", val); > } > @@ -1877,8 +1876,6 @@ static ssize_t sshot_pe_ctrl_store(struct device *dev, > raw_spin_lock(&drvdata->spinlock); > idx = config->ss_idx; > config->ss_pe_cmp[idx] = FIELD_PREP(TRCSSPCICRn_PC_MASK, val); > - /* must clear bit 31 in related status register on programming */ > - config->ss_status[idx] &= ~TRCSSCSRn_STATUS; > raw_spin_unlock(&drvdata->spinlock); > return size; > } > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h > index 8168676f2945..8864cfb76bad 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x.h > +++ b/drivers/hwtracing/coresight/coresight-etm4x.h > @@ -213,6 +213,7 @@ > #define TRCACATRn_EXLEVEL_MASK GENMASK(14, 8) > > #define TRCSSCSRn_STATUS BIT(31) > +#define TRCSSCSRn_PENDING BIT(30) > #define TRCSSCCRn_SAC_ARC_RST_MASK GENMASK(24, 0) > > #define TRCSSPCICRn_PC_MASK GENMASK(7, 0) > @@ -861,6 +862,7 @@ enum etm_impdef_type { > * @lpoverride: If the implementation can support low-power state over. > * @skip_power_up: Indicates if an implementation can skip powering up > * the trace unit. > + * @ss_status: The status of the corresponding single-shot comparator. > */ > struct etmv4_caps { > u8 nr_pe; > @@ -899,6 +901,7 @@ struct etmv4_caps { > bool atbtrig : 1; > bool lpoverride : 1; > bool skip_power_up : 1; > + u32 ss_status[ETM_MAX_SS_CMP]; > }; > > /** > @@ -977,7 +980,6 @@ struct etmv4_config { > u32 res_ctrl[ETM_MAX_RES_SEL]; /* TRCRSCTLRn */ > u8 ss_idx; > u32 ss_ctrl[ETM_MAX_SS_CMP]; > - u32 ss_status[ETM_MAX_SS_CMP]; > u32 ss_pe_cmp[ETM_MAX_SS_CMP]; > u8 addr_idx; > u64 addr_val[ETM_MAX_SINGLE_ADDR_CMP]; > -- > LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7} >

6 months, 2 weeks

Re: [RFC PATCH 00/12] Add Linux RISC-V trace support via CoreSight

by Zane Leung

On 4/14/2026 3:23 PM, Anup Patel wrote: > On Tue, Apr 14, 2026 at 9:12 AM Zane Leung <liangzhen(a)linux.spacemit.com> wrote: >> From: liangzhen <zhen.liang(a)spacemit.com> >> >> This series adds Linux RISC-V trace support via CoreSight, implementing RISC-V >> trace drivers within the CoreSight framework and integrating them with perf tools. >> The K3 SoC contains RISC-V Encoder, Funnel, ATB, CoreSight Funnel, and CoreSight TMC >> components, which can be directly leveraged through the existing CoreSight infrastructure. >> >> Linux RISC-V trace support form Anup Patel: >> (https://patchwork.kernel.org/project/linux-riscv/cover/20260225062448.40279…) >> which currently lacks ATB component support and guidance on reusing CoreSight components. > What stops you from adding RISC-V trace funnel and ATB bridge drivers > on top of this series ? > Firstly, my works started much earlier than this series. Secondly, it is difficult to add the coresight funnel and coresight tmc components to this series. Based on the coresight framework, I can directly reuse them. > >> The series includes: >> - RISC-V trace driver implementation within the CoreSight framework > The RISC-V trace very different from the CoreSight framework in many ways: > 1) Types of components supported > 2) Trace packet formats > 3) The way MMIO based components are discoverd > 4) ... and more ... 1) I believe that RISC-V tracing is coresight-alike, where have encoders/funnel/sink/bridge that are described through DT and controlled by MMIO. 2) I think the difference in package format is nothing more than the coresight frame generated by the ATB component to distinguish the trace source. After removing it, it becomes riscv trace data. 3) The current CoreSight framework code does not introduce this mechanism, it is described through DT. >> - RISC-V Trace Encoder, Funnel, and ATB Bridge drivers as CoreSight devices >> - RISC-V trace PMU record capabilities and parsing events in perf. >> - RISC-V Nexus Trace decoder for perf tools >> >> Any comments or suggestions are welcome. >> >> Verification on K3 SoC: >> To verify this patch series on K3 hardware, the following device tree are required: >> 1. RISC-V Trace Encoder node (8) >> 2. RISC-V ATB Bridge node (8) >> 3. RISC-V Trace Funnel node (2) >> 3. CoreSight Funnel configuration for RISC-V (1) >> 4. CoreSight TMC configuration for trace buffer (1) >> >> /{ >> dummy_clk: apb-pclk { >> compatible = "fixed-clock"; >> #clock-cells = <0x0>; >> clock-output-names = "clk14mhz"; >> clock-frequency = <14000000>; >> }; >> >> >> soc: soc { >> #address-cells = <2>; >> #size-cells = <2>; >> >> encoder0: encoder@d9002000 { >> compatible = "riscv,trace-encoder"; >> reg = <0x0 0xd9002000 0x0 0x1000>; >> cpus = <&cpu_0>; >> out-ports { >> port { >> cluster0_encoder0_out_port: endpoint { >> remote-endpoint = <&cluster0_bridge0_in_port>; >> }; >> }; >> }; >> }; >> >> bridge0: bridge@d9003000 { >> compatible = "riscv,trace-atbbridge"; >> reg = <0x0 0xd9003000 0x0 0x1000>; >> cpus = <&cpu_0>; >> out-ports { >> port { >> cluster0_bridge0_out_port: endpoint { >> remote-endpoint = <&cluster0_funnel_in_port0>; >> }; >> }; >> }; >> in-ports { >> port { >> cluster0_bridge0_in_port: endpoint { >> remote-endpoint = <&cluster0_encoder0_out_port>; >> }; >> }; >> }; >> }; >> >> ... >> >> cluster0_funnel: funnel@d9000000 { >> compatible = "riscv,trace-funnel"; >> reg = <0x0 0xd9000000 0x0 0x1000>; >> cpus = <&cpu_0>, <&cpu_1>, <&cpu_2>, <&cpu_3>; >> riscv,timestamp-present; >> out-ports { >> port { >> cluster0_funnel_out_port: endpoint { >> remote-endpoint = <&main_funnel_in_port0>; >> }; >> }; >> }; >> in-ports { >> #address-cells = <1>; >> #size-cells = <0>; >> >> port@0 { >> reg = <0>; >> cluster0_funnel_in_port0: endpoint { >> remote-endpoint = <&cluster0_bridge0_out_port>; >> }; >> }; >> >> port@1 { >> reg = <1>; >> cluster0_funnel_in_port1: endpoint { >> remote-endpoint = <&cluster0_bridge1_out_port>; >> }; >> }; >> >> port@2 { >> reg = <2>; >> cluster0_funnel_in_port2: endpoint { >> remote-endpoint = <&cluster0_bridge2_out_port>; >> }; >> }; >> >> port@3 { >> reg = <3>; >> cluster0_funnel_in_port3: endpoint { >> remote-endpoint = <&cluster0_bridge3_out_port>; >> }; >> }; >> }; >> }; >> >> cluster1_funnel: funnel@d9010000 { >> compatible = "riscv,trace-funnel"; >> reg = <0x0 0xd9010000 0x0 0x1000>; >> cpus = <&cpu_4>, <&cpu_5>, <&cpu_6>, <&cpu_7>; >> riscv,timestamp-present; >> out-ports { >> port { >> cluster1_funnel_out_port: endpoint { >> remote-endpoint = <&main_funnel_in_port1>; >> }; >> }; >> }; >> in-ports { >> #address-cells = <1>; >> #size-cells = <0>; >> >> port@0 { >> reg = <0>; >> cluster1_funnel_in_port0: endpoint { >> remote-endpoint = <&cluster1_bridge0_out_port>; >> }; >> }; >> >> port@1 { >> reg = <1>; >> cluster1_funnel_in_port1: endpoint { >> remote-endpoint = <&cluster1_bridge1_out_port>; >> }; >> }; >> >> port@2 { >> reg = <2>; >> cluster1_funnel_in_port2: endpoint { >> remote-endpoint = <&cluster1_bridge2_out_port>; >> }; >> }; >> >> port@3 { >> reg = <3>; >> cluster1_funnel_in_port3: endpoint { >> remote-endpoint = <&cluster1_bridge3_out_port>; >> }; >> }; >> }; >> }; >> >> main_funnel: funnel@d9042000 { >> compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; > Is it legally allowed to mix and match ARM coresight IPs with > RISC-V trace components at hardware level ? The ATB Bridge allows sending RISC-V trace to Arm CoreSight infrastructure (instead of RISC-V compliant sink defined in this document) as an ATB initiator. see: https://github.com/riscv-non-isa/riscv-nexus-trace/blob/105dc1c349556622e4d… For ATB Bridge, read trace using Coresight components (ETB/TMC/TPIU). see: https://github.com/riscv-non-isa/riscv-nexus-trace/blob/105dc1c349556622e4d… > >> reg = <0x0 0xd9042000 0x0 0x1000>; >> clocks = <&dummy_clk>; >> clock-names = "apb_pclk"; >> out-ports { >> port { >> main_funnel_out_port: endpoint { >> remote-endpoint = <&etf_in_port>; >> }; >> }; >> }; >> in-ports { >> #address-cells = <1>; >> #size-cells = <0>; >> >> port@0 { >> reg = <0>; >> main_funnel_in_port0: endpoint { >> remote-endpoint = <&cluster0_funnel_out_port>; >> }; >> }; >> >> port@1 { >> reg = <1>; >> main_funnel_in_port1: endpoint { >> remote-endpoint = <&cluster1_funnel_out_port>; >> }; >> }; >> }; >> }; >> >> etf: etf@d9043000 { >> compatible = "arm,coresight-tmc", "arm,primecell"; >> reg = <0x0 0xd9043000 0x0 0x1000>; >> clocks = <&dummy_clk>; >> clock-names = "apb_pclk"; >> out-ports { >> port { >> etf_out_port: endpoint { >> remote-endpoint = <&etr_in_port>; >> }; >> }; >> }; >> in-ports { >> port { >> etf_in_port: endpoint { >> remote-endpoint = <&main_funnel_out_port>; >> }; >> }; >> }; >> }; >> >> etr: etr@d9044000 { >> compatible = "arm,coresight-tmc", "arm,primecell"; >> reg = <0x0 0xd9044000 0x0 0x1000>; >> clocks = <&dummy_clk>; >> clock-names = "apb_pclk"; >> arm,scatter-gather; >> in-ports { >> port { >> etr_in_port: endpoint { >> remote-endpoint = <&etf_out_port>; >> }; >> }; >> }; >> }; >> }; >> }; >> >> Verification case: >> >> ~ # perf list pmu >> rvtrace// [Kernel PMU event] >> >> ~ # perf record -e rvtrace/@tmc_etr0/ --per-thread uname >> Linux >> [ perf record: Woken up 1 times to write data ] >> [ perf record: Captured and wrote 0.191 MB perf.data ] >> ~ # perf script >> uname 137 [003] 1 branches: ffffffff80931470 rvtrace_poll_bit+0x38 ([kernel.kallsyms]) => ffffffff80931492 rvtrace_poll_bit+0x5a ([kernel.kallsyms]) >> uname 137 [003] 1 branches: ffffffff809328a6 encoder_enable_hw+0x252 ([kernel.kallsyms]) => ffffffff809328ba encoder_enable_hw+0x266 ([kernel.kallsyms]) >> uname 137 [003] 1 branches: ffffffff80932c4a encoder_enable+0x82 ([kernel.kallsyms]) => ffffffff80932c36 encoder_enable+0x6e ([kernel.kallsyms]) >> uname 137 [003] 1 branches: ffffffff80928198 etm_event_start+0xf0 ([kernel.kallsyms]) => ffffffff809281aa etm_event_start+0x102 ([kernel.kallsyms]) >> uname 137 [003] 1 branches: ffffffff809281e6 etm_event_start+0x13e ([kernel.kallsyms]) => ffffffff8092755e coresight_get_sink_id+0x16 ([kernel.kallsyms]) >> uname 137 [003] 1 branches: ffffffff8092820e etm_event_start+0x166 ([kernel.kallsyms]) => ffffffff80928226 etm_event_start+0x17e ([kernel.kallsyms]) >> uname 137 [003] 1 branches: ffffffff801c3bb4 perf_report_aux_output_id+0x0 ([kernel.kallsyms]) => ffffffff801c3bd6 perf_report_aux_output_id+0x22 ([kernel.kallsyms]) >> uname 137 [003] 1 branches: ffffffff801c3c5a perf_report_aux_output_id+0xa6 ([kernel.kallsyms]) => ffffffff801c3bf0 perf_report_aux_output_id+0x3c ([kernel.kallsyms]) >> uname 137 [003] 1 branches: ffffffff801c3c40 perf_report_aux_output_id+0x8c ([kernel.kallsyms]) => ffffffff801c3aea __perf_event_header__init_id+0x2a ([kernel.kallsyms]) >> uname 137 [003] 1 branches: ffffffff801c3b42 __perf_event_header__init_id+0x82 ([kernel.kallsyms]) => ffffffff801c3b4a __perf_event_header__init_id+0x8a ([kernel.kallsyms]) >> uname 137 [003] 1 branches: ffffffff801c3bb0 __perf_event_header__init_id+0xf0 ([kernel.kallsyms]) => ffffffff801c3b58 __perf_event_header__init_id+0x98 ([kernel.kallsyms]) >> uname 137 [003] 1 branches: ffffffff8004c658 __task_pid_nr_ns+0x0 ([kernel.kallsyms]) => ffffffff8004c696 __task_pid_nr_ns+0x3e ([kernel.kallsyms]) >> uname 137 [003] 1 branches: ffffffff8004c71e __task_pid_nr_ns+0xc6 ([kernel.kallsyms]) => ffffffff8004c6a4 __task_pid_nr_ns+0x4c ([kernel.kallsyms]) >> uname 137 [003] 1 branches: ffffffff8004c6e4 __task_pid_nr_ns+0x8c ([kernel.kallsyms]) => ffffffff8004c6e4 __task_pid_nr_ns+0x8c ([kernel.kallsyms]) >> ... >> >> liangzhen (12): >> coresight: Add RISC-V support to CoreSight tracing >> coresight: Initial implementation of RISC-V trace driver >> coresight: Add RISC-V Trace Encoder driver >> coresight: Add RISC-V Trace Funnel driver >> coresight: Add RISC-V Trace ATB Bridge driver >> coresight rvtrace: Add timestamp component support for encoder and >> funnel >> coresight: Add RISC-V PMU name support >> perf tools: riscv: making rvtrace PMU listable >> perf tools: Add RISC-V trace PMU record capabilities >> perf tools: Add Nexus RISC-V Trace decoder >> perf symbols: Add RISC-V PLT entry sizes >> perf tools: Integrate RISC-V trace decoder into auxtrace >> >> drivers/hwtracing/Kconfig | 2 + >> drivers/hwtracing/coresight/Kconfig | 46 +- >> drivers/hwtracing/coresight/Makefile | 6 + >> drivers/hwtracing/coresight/coresight-core.c | 8 + >> .../hwtracing/coresight/coresight-etm-perf.c | 1 - >> .../hwtracing/coresight/coresight-etm-perf.h | 21 + >> .../hwtracing/coresight/coresight-platform.c | 1 - >> .../hwtracing/coresight/coresight-tmc-etf.c | 4 + >> .../hwtracing/coresight/coresight-tmc-etr.c | 4 + >> .../hwtracing/coresight/rvtrace-atbbridge.c | 239 +++ >> drivers/hwtracing/coresight/rvtrace-core.c | 135 ++ >> .../coresight/rvtrace-encoder-core.c | 562 +++++++ >> .../coresight/rvtrace-encoder-sysfs.c | 363 +++++ >> drivers/hwtracing/coresight/rvtrace-encoder.h | 151 ++ >> drivers/hwtracing/coresight/rvtrace-funnel.c | 337 ++++ >> drivers/hwtracing/coresight/rvtrace-funnel.h | 39 + >> .../hwtracing/coresight/rvtrace-timestamp.c | 278 ++++ >> .../hwtracing/coresight/rvtrace-timestamp.h | 64 + >> include/linux/coresight-pmu.h | 4 + >> include/linux/rvtrace.h | 116 ++ >> tools/arch/riscv/include/asm/insn.h | 645 ++++++++ >> tools/perf/arch/riscv/util/Build | 2 + >> tools/perf/arch/riscv/util/auxtrace.c | 490 ++++++ >> tools/perf/arch/riscv/util/pmu.c | 20 + >> tools/perf/util/Build | 3 + >> tools/perf/util/auxtrace.c | 4 + >> tools/perf/util/auxtrace.h | 1 + >> tools/perf/util/nexus-rv-decoder/Build | 1 + >> .../util/nexus-rv-decoder/nexus-rv-decoder.c | 1364 +++++++++++++++++ >> .../util/nexus-rv-decoder/nexus-rv-decoder.h | 139 ++ >> .../perf/util/nexus-rv-decoder/nexus-rv-msg.h | 190 +++ >> tools/perf/util/rvtrace-decoder.c | 1039 +++++++++++++ >> tools/perf/util/rvtrace.h | 40 + >> tools/perf/util/symbol-elf.c | 4 + >> 34 files changed, 6320 insertions(+), 3 deletions(-) >> create mode 100644 drivers/hwtracing/coresight/rvtrace-atbbridge.c >> create mode 100644 drivers/hwtracing/coresight/rvtrace-core.c >> create mode 100644 drivers/hwtracing/coresight/rvtrace-encoder-core.c >> create mode 100644 drivers/hwtracing/coresight/rvtrace-encoder-sysfs.c >> create mode 100644 drivers/hwtracing/coresight/rvtrace-encoder.h >> create mode 100644 drivers/hwtracing/coresight/rvtrace-funnel.c >> create mode 100644 drivers/hwtracing/coresight/rvtrace-funnel.h >> create mode 100644 drivers/hwtracing/coresight/rvtrace-timestamp.c >> create mode 100644 drivers/hwtracing/coresight/rvtrace-timestamp.h >> create mode 100644 include/linux/rvtrace.h >> create mode 100644 tools/arch/riscv/include/asm/insn.h >> create mode 100644 tools/perf/arch/riscv/util/auxtrace.c >> create mode 100644 tools/perf/arch/riscv/util/pmu.c >> create mode 100644 tools/perf/util/nexus-rv-decoder/Build >> create mode 100644 tools/perf/util/nexus-rv-decoder/nexus-rv-decoder.c >> create mode 100644 tools/perf/util/nexus-rv-decoder/nexus-rv-decoder.h >> create mode 100644 tools/perf/util/nexus-rv-decoder/nexus-rv-msg.h >> create mode 100644 tools/perf/util/rvtrace-decoder.c >> create mode 100644 tools/perf/util/rvtrace.h >> >> -- >> 2.34.1 >> > NACK to this approach of retrofitting RISC-V trace into ARM coresight. I agree that integrating RISC-V trace directly into CoreSight is not a good approach, so I think we should abstract some of the logic of coresight and reuse it in RISC-V Trace. > > Regards, > Anup Thanks, Zane

6 months, 2 weeks

Re: [RFC PATCH 00/12] Add Linux RISC-V trace support via CoreSight

by Zane Leung

On 4/14/2026 12:15 PM, Jie Gan wrote: > > I dont think you have looped relevant maintainers and reviewers for the Coresight subsystem. > > Thanks, > Jie I will send it to all relevant maintainers and reviewers for the Coresight subsystem in next revision. Thanks, Zane

6 months, 2 weeks

Re: [PATCH v10 00/20] CoreSight: Refactor power management for CoreSight path

by Leo Yan

On Tue, Apr 14, 2026 at 11:30:39AM +0800, Jie Gan wrote: [...] > > > Tested-by: Jie Gan <jie.gan(a)oss.qualcomm.com> > > > > Just heads up: since Sashiko [1] pointed out a corner case where an SMP call > > may fail when disabling the source device, the per-CPU path pointer > > might not be cleared. If the ETMv4 device is then removed (e.g. if the > > user unloads the ETMv4 module), CPU PM notifier might access the stale > > path pointer. Though this is a rare case, we should handle it safely. > > This is why the series was not picked for the v7.1 merge window. > > > > Thanks a lot for the testing, Jie! It's very helpful, and I will add > > your test tags in the next spin. > > > > Anyway, please expect more iterations. > > Noted, will run the test cases on new iterations. Thank you!

6 months, 2 weeks

Re: [PATCH v4 1/9] coresight: etm4x: introduce struct etm4_caps

by Leo Yan

On Mon, Apr 13, 2026 at 03:19:54PM +0100, Yeoreum Yun wrote: > Introduce struct etm4_caps to describe ETMv4 capabilities > and move capabilities information into it. > > Signed-off-by: Yeoreum Yun <yeoreum.yun(a)arm.com> LGTM: Reviewed-by: Leo Yan <leo.yan(a)arm.com> FWIW, two comments from Sashiko are valuable for me, please see below. > --- > .../coresight/coresight-etm4x-core.c | 234 +++++++++--------- > .../coresight/coresight-etm4x-sysfs.c | 190 ++++++++------ > drivers/hwtracing/coresight/coresight-etm4x.h | 176 ++++++------- > 3 files changed, 328 insertions(+), 272 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c > index d565a73f0042..6443f3717b37 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > @@ -88,8 +88,9 @@ static int etm4_probe_cpu(unsigned int cpu); > */ > static bool etm4x_sspcicrn_present(struct etmv4_drvdata *drvdata, int n) > { > - return (n < drvdata->nr_ss_cmp) && > - drvdata->nr_pe && > + const struct etmv4_caps *caps = &drvdata->caps; > + > + return (n < caps->nr_ss_cmp) && caps->nr_pe && > (drvdata->config.ss_status[n] & TRCSSCSRn_PC); As Sashiko suggests: "This isn't a regression introduced by this patch, but should this be checking caps->nr_pe_cmp instead of caps->nr_pe?" I confirmed the ETMv4 specification (ARM IHI0064H.b), the comment above is valid as the we should check caps->nr_pe_cmp instead. Could you first use a patch to fix the typo and then apply capabilities afterwards? This is helpful for porting to stable kernels. [...] > @@ -525,14 +530,14 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata) > if (etm4x_wait_status(csa, TRCSTATR_IDLE_BIT, 1)) > dev_err(etm_dev, > "timeout while waiting for Idle Trace Status\n"); > - if (drvdata->nr_pe) > + if (caps->nr_pe) > etm4x_relaxed_write32(csa, config->pe_sel, TRCPROCSELR); > etm4x_relaxed_write32(csa, config->cfg, TRCCONFIGR); > /* nothing specific implemented */ > etm4x_relaxed_write32(csa, 0x0, TRCAUXCTLR); > etm4x_relaxed_write32(csa, config->eventctrl0, TRCEVENTCTL0R); > etm4x_relaxed_write32(csa, config->eventctrl1, TRCEVENTCTL1R); > - if (drvdata->stallctl) > + if (caps->stallctl) > etm4x_relaxed_write32(csa, config->stall_ctrl, TRCSTALLCTLR); > etm4x_relaxed_write32(csa, config->ts_ctrl, TRCTSCTLR); > etm4x_relaxed_write32(csa, config->syncfreq, TRCSYNCPR); > @@ -542,17 +547,17 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata) > etm4x_relaxed_write32(csa, config->vinst_ctrl, TRCVICTLR); > etm4x_relaxed_write32(csa, config->viiectlr, TRCVIIECTLR); > etm4x_relaxed_write32(csa, config->vissctlr, TRCVISSCTLR); > - if (drvdata->nr_pe_cmp) > + if (caps->nr_pe_cmp) > etm4x_relaxed_write32(csa, config->vipcssctlr, TRCVIPCSSCTLR); > - for (i = 0; i < drvdata->nrseqstate - 1; i++) > + for (i = 0; i < caps->nrseqstate - 1; i++) > etm4x_relaxed_write32(csa, config->seq_ctrl[i], TRCSEQEVRn(i)); Sashiko's comment: "If the hardware does not implement a sequencer, caps->nrseqstate (a u8) will be 0. Does 0 - 1 evaluate to -1 as an int, which then gets promoted to ULONG_MAX against val (an unsigned long)?" This is a good catch. The condition check should be: for (i = 0; i < caps->nrseqstate; i++) ...; The issue is irrelevant to your patch, but could you use a patch to fix "nrseqstate - 1" first and then apply the cap refactoring on it? This would be friendly for porting to stable kernel. Thanks, Leo

6 months, 2 weeks

Re: [PATCH v10 00/20] CoreSight: Refactor power management for CoreSight path

by Leo Yan

On Mon, Apr 13, 2026 at 06:30:18PM +0800, Jie Gan wrote: [...] > tested on QCOM sa8775-ride: > > === 1. Sysfs mode: basic enable/disable === > PASS: Sink tmc_etr0 enabled > PASS: Source etm0 enabled > PASS: Source etm0 disabled cleanly > PASS: Sink tmc_etr0 disabled cleanly > > === 2. Sysfs mode: repeated enable/disable cycles (10x) === > PASS: 10 enable/disable cycles completed without error > > === 3. Sysfs mode: enable source with no active sink === > PASS: Enable without sink returned error (expected) > > === 4. Sysfs mode: enable/disable all per-CPU sources === > etm0 (cpu0): enabled OK > etm1 (cpu1): enabled OK > etm2 (cpu2): enabled OK > etm3 (cpu3): enabled OK > etm4 (cpu4): enabled OK > etm5 (cpu5): enabled OK > etm6 (cpu6): enabled OK > etm7 (cpu7): enabled OK > PASS: All online per-CPU sources enabled/disabled successfully > > === 5. CPU hotplug: offline CPU while sysfs tracing active === > Using source etm1 on cpu1 > Tracing active on cpu1, offlining CPU... > [ 82.805359] psci: CPU1 killed (polled 0 ms) > PASS: Source auto-disabled on CPU offline > [ 83.346033] Detected PIPT I-cache on CPU1 > [ 83.346114] GICv3: CPU1: found redistributor 100 region > 0:0x0000000017a80000 > [ 83.346283] CPU1: Booted secondary processor 0x0000000100 [0x410fd4b2] > PASS: Source re-enabled after CPU re-online > > === 6. Sysfs: enable source on offline CPU (expect ENODEV) === > [ 84.013788] psci: CPU1 killed (polled 0 ms) > PASS: Enable on offline cpu1 rejected (enable_source=0) > [ 84.349558] Detected PIPT I-cache on CPU1 > [ 84.349640] GICv3: CPU1: found redistributor 100 region > 0:0x0000000017a80000 > [ 84.349811] CPU1: Booted secondary processor 0x0000000100 [0x410fd4b2] > > === 7. CPU PM: trace survives CPU idle entry/exit === > Sleeping 3s to allow CPU idle entry... > Idle entries on cpu0 during test: 35 > PASS: Source still enabled after idle (PM save/restore working) > > === 8. Perf mode: basic cs_etm recording === > SKIP: perf not found in PATH > > === 11. TRBE: check save/restore sysfs nodes (if present) === > SKIP: No TRBE devices found > > Tested-by: Jie Gan <jie.gan(a)oss.qualcomm.com> Just heads up: since Sashiko [1] pointed out a corner case where an SMP call may fail when disabling the source device, the per-CPU path pointer might not be cleared. If the ETMv4 device is then removed (e.g. if the user unloads the ETMv4 module), CPU PM notifier might access the stale path pointer. Though this is a rare case, we should handle it safely. This is why the series was not picked for the v7.1 merge window. Thanks a lot for the testing, Jie! It's very helpful, and I will add your test tags in the next spin. Anyway, please expect more iterations. Thanks, Leo [1] https://sashiko.dev/#/patchset/20260405-arm_coresight_path_power_management…

6 months, 2 weeks

Re: [PATCH v10 16/20] coresight: Add PM callbacks for sink device

by Leo Yan

On Mon, Apr 13, 2026 at 01:45:50PM +0800, Jie Gan wrote: [...] > > @@ -1787,15 +1808,32 @@ static int coresight_pm_save(struct coresight_path *path) > > to = list_prev_entry(coresight_path_last_node(path), link); > > coresight_disable_path_from_to(path, from, to); > > + ret = coresight_pm_device_save(coresight_get_sink(path)); > > + if (ret) > > + goto sink_failed; > > + > > return 0; > > + > > +sink_failed: > > + if (!coresight_enable_path_from_to(path, coresight_get_mode(source), > > + from, to)) > > + coresight_pm_device_restore(source); > > I have go through the history messages. I have a question about this point > here: > > how can we handle the scenario if coresight_enable_path_from_to failed? It > means we are never calling coresight_pm_device_restore for the ETM and > leaving the ETM with OS lock state until CPU reset? From a design perspective, if any failure occurs in the idle flow, the priority is to avoid further mess, especially partial enable/disable sequences that could lead to lockups. The case you mentioned is a typical risk - if a path after source to sink fails to be enabled, it is unsafe to arbitrarily enable the source further. We rely on the per-CPU flag "percpu_pm_failed" to disable idle states, if ETE/TRBE fails to be disabled, if CPU is turned off, this also might cause lockup. > Consider we are calling etm4_disable_hw with OS lock: > etm4_disable_hw -> etm4_disable_trace_unit -> etm4x_wait_status (may timeout > here?) This is expected. I don't want to introduce a _recovery_ mechanism for CPU PM failures, which is complex and over-engineering. CPU PM notifier is low level code, and in my experience, PM issues can be easily observed once CPU idle is enabled and should be resolved during the development phase. In many cases PM issues are often not caused by CoreSight drivers but by other modules (e.g., clock or regulator drivers). The log "Failed in coresight PM save ..." reminds developers the bugs. As said, percpu_pm_failed is used as a last resort to prevent the platform from locking up if there is a PM bug. Thanks, Leo

6 months, 2 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight