CoreSight

coresight@lists.linaro.org

6 participants
2768 discussions

Re: [PATCH v5 06/12] coresight: etm4x: fix leaked trace id

by Leo Yan

Hi Jie, On Fri, Apr 17, 2026 at 09:01:17AM +0800, Jie Gan wrote: [...] > ... we still need support static trace ID allocation in parallel for > the dummy sources and we should not break this logic in future refactor. Just confirm what is the reason you need to use static trace ID for the dummy sources? I am wandering if we could use dev->devt as trace ID for dummy devices. Since the device's MAJOR number is non-zero and occupies the upper bits (see MINORBITS), it is naturally separated from the hardware trace ID range. If so, we even don't need to bother ID alloc/release. Thanks, Leo

1 month, 3 weeks

Re: [PATCH v5 06/12] coresight: etm4x: fix leaked trace id

by Leo Yan

Hi Levi, On Thu, Apr 16, 2026 at 06:06:41PM +0100, Yeoreum Yun wrote: [...] > > We should use paired way for allocation and release. For example: > > > > coresight_enable_sysfs() > > { > > ... > > coresight_path_assign_trace_id(path); > > > > failed: > > coresight_path_unassign_trace_id(path); > > } > > > > coresight_disable_sysfs() > > { > > coresight_path_unassign_trace_id(path); > > } > > > > But this requires broader refactoring. E.g., the STM driver currently > > allocates system trace IDs statically during probe, we might need to > > consolidate for all modules to use dynamic allocation. > > So IIUC, Do we want to "map" per "session" and save this map information > in the "sink" driver? or just use "global" map but locate it in sink > driver? I prefer to save map in the sink's driver data, this is more scalable as the trace ID is allocated within a session rather than system wide. > I totally agree for above suggestion -- unsigned trace id > in the coresight_XXX function -- (but we need to add another callback > for this) but I think we don't need to sustain map per session > and it seems enough to use current storage for trace_id not move to > sink driver. > > Anyway It would be better to refactorying wiht another patchset... Yeah, we can come back to these ideas when work on it. Thanks, Leo

1 month, 3 weeks

Re: [PATCH v5 06/12] coresight: etm4x: fix leaked trace id

by Leo Yan

On Wed, Apr 15, 2026 at 05:55:22PM +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(). > > Reviewed-by: Jie Gan <jie.gan(a)oss.qualcomm.com> > 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 f55338a4989d..b199aebbdb60 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > @@ -920,8 +920,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); > return ret; > + } LGTM: Reviewed-by: Leo Yan <leo.yan(a)arm.com> Just recording a bit thoughts. As Suzuki mentioned, it would be better to allocate trace IDs within a session. We might consider maintaining the trace ID map in the sink driver data, since the sink driver is unique within a session so it is a central place to allocate trace ID. We should use paired way for allocation and release. For example: coresight_enable_sysfs() { ... coresight_path_assign_trace_id(path); failed: coresight_path_unassign_trace_id(path); } coresight_disable_sysfs() { coresight_path_unassign_trace_id(path); } But this requires broader refactoring. E.g., the STM driver currently allocates system trace IDs statically during probe, we might need to consolidate for all modules to use dynamic allocation. Thanks, Leo

1 month, 3 weeks

Re: [PATCH v5 01/12] coresight: etm4x: fix wrong check of etm4x_sspcicrn_present()

by Leo Yan

On Wed, Apr 15, 2026 at 05:55:17PM +0100, Yeoreum Yun wrote: > According to Embedded Trace Macrocell Architecture Specification > ETMv4.0 to ETM4.6 [0], TRCSSPCICR<n> is present only if all of > the following are true: > > - TRCIDR4.NUMSSCC > n. > - TRCIDR4.NUMPC > 0b0000. > - TRCSSCSR<n>.PC == 0b1. > > Comment for etm4x_sspcicrn_present() is align with the specification. > However, the check should use drvdata->nr_pe_cmp to check TRCIDR4.NUMPC > not nr_pe. > > Link: https://developer.arm.com/documentation/ihi0064/latest/ [0] > Signed-off-by: Yeoreum Yun <yeoreum.yun(a)arm.com> Reviewed-by: Leo Yan <leo.yan(a)arm.com>

1 month, 3 weeks

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

by Suzuki K Poulose

On 15/04/2026 09:45, Jie Gan wrote: > > > On 4/15/2026 4:32 PM, Leo Yan wrote: >> On Wed, Apr 15, 2026 at 09:01:09AM +0100, Yeoreum Yun wrote: >> >> [...] >> >>>>> 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. >>>> >>> >>> When I see the CORESIGHT_TRACE_ID_MAX: >>> >>> /* architecturally we have 128 IDs some of which are reserved */ >>> #define CORESIGHT_TRACE_IDS_MAX 128 >>> >>> I think this came from the hardware restriction for number of TRACE_IDs. >>> In this case, clamping the device_id to trace_id seems more complex and >>> reduce some performance perspective. >> >> Sigh, my stupid. Please ignore my previous comment, let us first fix >> ID leak issue. >> >> Given Jie's comment on the use-out issue, it is valid for me especially >> if a system have many dummy tracers. We can defer to refactor it >> later (e.g., use separate ranges for hardware and dummy tracers). >> >> thanks for correction! > > Just share some info: > > With my memory, The ARM AMBA ATB Protocol Specification defined a 7-bit > width field for the trace ID, that's where the 128 comes from. (in each > frame, we also have 7-bit field for containing the trace ID) That is true and some IDs in the range (0-128) are reserved. So we actually have less than 128. We need the dynamic allocation, preferrably isolated to a "pool" for the relevant session to make the full use of the space. Suzuki > > Thanks, > Jie >

1 month, 4 weeks

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

by Leo Yan

On Wed, Apr 15, 2026 at 09:01:09AM +0100, Yeoreum Yun wrote: [...] > > > 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. > > > > When I see the CORESIGHT_TRACE_ID_MAX: > > /* architecturally we have 128 IDs some of which are reserved */ > #define CORESIGHT_TRACE_IDS_MAX 128 > > I think this came from the hardware restriction for number of TRACE_IDs. > In this case, clamping the device_id to trace_id seems more complex and > reduce some performance perspective. Sigh, my stupid. Please ignore my previous comment, let us first fix ID leak issue. Given Jie's comment on the use-out issue, it is valid for me especially if a system have many dummy tracers. We can defer to refactor it later (e.g., use separate ranges for hardware and dummy tracers). thanks for correction!

1 month, 4 weeks

Re: [PATCH v7 0/4] Add Qualcomm extended CTI support

by Leo Yan

Hi Yingchao, On Wed, Apr 15, 2026 at 11:22:49AM +0800, Yingchao Deng (Consultant) wrote: [...] > Gentle reminder. This series would be on Mike's radar. I will also look into details once I finish Levi's series review. Thanks, Leo

1 month, 4 weeks

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

1 month, 4 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

1 month, 4 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} >

1 month, 4 weeks

← Newer
1
...
6
7
8
9
10
11
12
...
277
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight