CoreSight January 2024

coresight@lists.linaro.org

9 participants
31 discussions

[PATCH 0/8] coresight: Separate sysfs and Perf usage and some other cleanups

by James Clark

I've been finding it quite difficult to reason about some of the state and functions in coresight-core.c because they have generic names when they are actually only relevant to the sysfs usage of Coresight rather than usage through Perf. This is probably because sysfs came first and Perf was added later. This has caused a couple of issues where these things have been used in the wrong context, for example the first commit is a fixup. To fix this I've mainly just moved all of the sysfs stuff to the sysfs file and removed the 'enable' state, which was just for sysfs. While doing the refactor it became obvious that refcnt didn't need to be atomic either, so that can be simplified along with some other comment clarifications and simplifications. Hopefully it's also a step towards to removing all of the duplicate refcnt and mode tracking code from the individual devices. That tracking pretty much always results in a one-shot enable/disable and fixes the mode to either sysfs or Perf, and there is no reason that can't exist in the core layer outside of the devices. I tried to finish that in this set, but there turned out to be some complexities, so I cut it short at a point where I can be sure that there are no behavioral changes. James Clark (8): coresight: Fix issue where a source device's helpers aren't disabled coresight: Make language around "activated" sinks consistent coresight: Remove ops callback checks coresight: Move mode to struct coresight_device coresight: Remove the 'enable' field. coresight: Move all sysfs code to sysfs file coresight: Remove atomic type from refcnt coresight: Remove unused stubs drivers/hwtracing/coresight/coresight-core.c | 494 +----------------- drivers/hwtracing/coresight/coresight-etb10.c | 29 +- .../hwtracing/coresight/coresight-etm-perf.c | 2 +- drivers/hwtracing/coresight/coresight-etm.h | 2 - .../coresight/coresight-etm3x-core.c | 17 +- .../coresight/coresight-etm3x-sysfs.c | 4 +- .../coresight/coresight-etm4x-core.c | 4 +- drivers/hwtracing/coresight/coresight-priv.h | 9 +- drivers/hwtracing/coresight/coresight-stm.c | 24 +- drivers/hwtracing/coresight/coresight-sysfs.c | 391 ++++++++++++++ .../hwtracing/coresight/coresight-tmc-core.c | 2 +- .../hwtracing/coresight/coresight-tmc-etf.c | 46 +- .../hwtracing/coresight/coresight-tmc-etr.c | 33 +- drivers/hwtracing/coresight/coresight-tmc.h | 2 - drivers/hwtracing/coresight/coresight-tpda.c | 13 +- drivers/hwtracing/coresight/coresight-tpiu.c | 14 +- drivers/hwtracing/coresight/ultrasoc-smb.c | 22 +- drivers/hwtracing/coresight/ultrasoc-smb.h | 2 - include/linux/coresight.h | 114 +--- 19 files changed, 561 insertions(+), 663 deletions(-) -- 2.34.1

3 months, 2 weeks

Re: [PATCH v4 09/10] dt-bindings: arm: Add support for TPDM CMB MSR register

by Tao Zhang

On 1/22/2024 4:44 PM, Krzysztof Kozlowski wrote: > On 19/01/2024 04:23, Tao Zhang wrote: >> Add property "qcom,cmb_msr_num" to support CMB MSR(mux select register) >> for TPDM. It specifies the number of CMB MSR registers supported by >> the TDPM. > Please use subject prefixes matching the subsystem. You can get them for > example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory > your patch is touching. > > Missing "qcom,coresight-tpdm:" prefix. Checked the example of other changes. Which of the following prefixes do you prefer here? dt-bindings: arm: qcom: coresight-tpdm: dt-bindings: arm: qcom, coresight-tpdm: Best, Tao > > With this fixed: > > Reviewed-by: Krzysztof Kozlowski<krzysztof.kozlowski(a)linaro.org> > > Best regards, > Krzysztof >

3 months, 2 weeks

Re: [PATCH v4 03/10] dt-bindings: arm: Add support for CMB element size

by Tao Zhang

On 1/22/2024 4:42 PM, Krzysztof Kozlowski wrote: > On 19/01/2024 04:22, Tao Zhang wrote: >> Add property "qcom,cmb-elem-size" to support CMB(Continuous >> Multi-Bit) element for TPDM. The associated aggregator will read >> this size before it is enabled. CMB element size currently only >> supports 32-bit and 64-bit. >> >> Signed-off-by: Tao Zhang<quic_taozha(a)quicinc.com> >> Signed-off-by: Mao Jinlong<quic_jinlmao(a)quicinc.com> >> --- >> .../bindings/arm/qcom,coresight-tpdm.yaml | 27 +++++++++++++++++++ >> 1 file changed, 27 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml >> index 61ddc3b5b247..507a5f887097 100644 >> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml >> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml >> @@ -52,6 +52,15 @@ properties: >> $ref: /schemas/types.yaml#/definitions/uint8 >> enum: [32, 64] >> >> + qcom,cmb-element-size: >> + description: >> + Specifies the CMB(Continuous Multi-Bit) element size supported by >> + the monitor. The associated aggregator will read this size before it >> + is enabled. CMB element size currently only supports 8-bit, 32-bit >> + and 64-bit. >> + $ref: /schemas/types.yaml#/definitions/uint8 >> + enum: [8, 32, 64] > Is this in bits? If so, then qcom,cmb-element-bits or something similar. > I don't quite get what is "an element" here, but I assume you do, so you > will come with reasonable name. > > https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/prop… Yes, the unit of this element size is bit. This element size can be understood as that a CMB data set consists of values that are all N-bit binary vectors where N is 8, 32, or 64 bits. How about if we use "qcom,cmb-element-bits" here instead of "qcom,cmb-element-size"? > >> + >> qcom,dsb-msrs-num: >> description: >> Specifies the number of DSB(Discrete Single Bit) MSR(mux select register) >> @@ -110,4 +119,22 @@ examples: >> }; >> }; >> >> + tpdm@6c29000 { > You should explain why you need new example, so reviewers will not have > to go back to previous discussions to ask the same question over and > over again. Sure, I will add the explanation to the comments of the next commit. > >> + compatible = "qcom,coresight-tpdm", "arm,primecell"; >> + reg = <0x06c29000 0x1000>; >> + >> + qcom,cmb-element-size = /bits/ 8 <64>; >> + >> + clocks = <&aoss_qmp>; >> + clock-names = "apb_pclk"; >> + >> + out-ports { >> + port { >> + tpdm_ipcc_out_funnel_center: endpoint { >> + remote-endpoint = >> + <&funnel_center_in_tpdm_ipcc>; > Drop unneeded wrapping / line break. Sure, I will update in the next patch series. Best, Tao > > Best regards, > Krzysztof >

3 months, 2 weeks

[PATCH v3 0/2] arm64: dts: qcom: Add coresight nodes for sm8450

by Mao Jinlong

Add coresight components on Qualcomm SM8450 Soc. The components include TMC ETF/ETR, ETE, STM, TPDM, CTI. And remove the pattern of ete node name. Change since V2: 1. Change the name in binding as 'ete'. Change since V1: 1. Remove the pattern match of ETE node name. 2. Update the tmc-etr node name in DT. Mao Jinlong (2): dt-bindings: arm: coresight: Remove pattern match of ETE node name arm64: dts: qcom: Add coresight nodes for sm8450 .../arm/arm,embedded-trace-extension.yaml | 6 +- arch/arm64/boot/dts/qcom/sm8450.dtsi | 742 ++++++++++++++++++ 2 files changed, 744 insertions(+), 4 deletions(-) -- 2.41.0

3 months, 2 weeks

[PATCH v6 0/7]Coresight for Kernel panic and watchdog reset

by Linu Cherian

This patch series is rebased on v6.7-rc8 and is dependent on the below patch. - coresight: tmc: Make etr buffer mode user configurable from sysfs[1] Changelog from v5: * Fixed issues reported by CONFIG_DEBUG_ATOMIC_SLEEP * Fixed a memory leak while reading data from /dev/tmc_etrx in READ_PREVBOOT mode * Tested reading trace data from crashdump kernel Changelog from v4: * Device tree binding - Description is made more explicit on the usage of reserved memory region - Mismatch in memory region names in dts binding and driver fixed - Removed "mem" suffix from the memory region names * Rename "struct tmc_register_snapshot" -> "struct tmc_crash_metadata", since it contains more than register snapshot. Related variables are named accordingly. * Rename struct tmc_drvdata members resrv_buf -> crash_tbuf metadata -> crash_mdata * Size field in metadata refers to RSZ register and hence indicates the size in 32 bit words. ETR metadata follows this convention, the same has been extended to ETF metadata as well. * Added crc32 for more robust metadata and tracedata validation. * Added/modified dev_dbg messages during metadata validation * Fixed a typo in patch 5 commit description Changelog from v3: * Converted the Coresight ETM driver change to a named configuration. RFC tag has been removed with this change. * Fixed yaml issues reported by "make dt_binding_check" * Added names for reserved memory regions 0 and 1 * Added prevalidation checks for metadata processing * Fixed a regression introduced in RFC v3 - TMC Status register was getting saved wrongly * Reverted memremap attribute changes from _WB to _WC to match with the dma map attributes * Introduced reserved buffer mode specific .sync op. This fixes a possible crash when reserved buffer mode was used in normal trace capture, due to unwanted dma maintenance operations. v4 is posted here: https://lore.kernel.org/linux-arm-kernel/20230929133754.857678-1-lcherian@m… Please note, v4 got wrongly tagged as v1 during transitioning to nonRFC series. Using Coresight for Kernel panic and Watchdog reset =================================================== This patch series is about extending Linux coresight driver support to address kernel panic and watchdog reset scenarios. This would help coresight users to debug kernel panic and watchdog reset using coresight trace data. Coresight trace capture: Kernel panic ------------------------------------- From the coresight driver point of view, addressing the kernel panic situation has four main requirements. a. Support for allocation of trace buffer pages from reserved memory area. Platform can advertise this using a new device tree property added to relevant coresight nodes. b. Support for stopping coresight blocks at the time of panic c. Saving required metadata in the specified format d. Support for reading trace data captured at the time of panic Allocation of trace buffer pages from reserved RAM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A new optional device tree property "memory-region" is added to the ETR/ETF device nodes, that would give the base address and size of trace buffer. Static allocation of trace buffers would ensure that both IOMMU enabled and disabled cases are handled. Also, platforms that support persistent RAM will allow users to read trace data in the subsequent boot without booting the crashdump kernel. Note: For ETR sink devices, this reserved region will be used for both trace capture and trace data retrieval. For ETF sink devices, internal SRAM would be used for trace capture, and they would be synced to reserved region for retrieval. Note: Patches 1 & 2 adds support for this. Disabling coresight blocks at the time of panic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In order to avoid the situation of losing relevant trace data after a kernel panic, it would be desirable to stop the coresight blocks at the time of panic. This can be achieved by configuring the comparator, CTI and sink devices as below, Comparator(triggers on kernel panic) --->External out --->CTI -- | ETR/ETF stop <------External In <-------------- Note: * Patch 6 provides the necessary ETR configuration. * Patch 7 provides the necessary ETM configuration. Saving metadata at the time of kernel panic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Coresight metadata involves all additional data that are required for a successful trace decode in addition to the trace data. This involves ETR/ETF, ETE register snapshot etc. A new optional device property "memory-region" is added to the ETR/ETF/ETE device nodes for this. Note: Patches 3 & 4 adds support for this. Reading trace data captured at the time of panic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Trace data captured at the time of panic, can be read from rebooted kernel or from crashdump kernel using the below mentioned interface. Note: Patch 5 adds support for this. Steps for reading trace data captured in previous boot ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1. cd /sys/bus/coresight/devices/tmc_etrXX/ 2. Change to special mode called, read_prevboot. #echo 1 > read_prevboot 3. Dump trace buffer data to a file, #dd if=/dev/tmc_etrXX of=~/cstrace.bin 4. Reset back to normal mode #echo 0 > read_prevboot General flow of trace capture and decode incase of kernel panic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Enable source and sink on all the cores using the sysfs interface. ETR sink will have trace buffers allocated from reserved memory, by selecting "resrv" buffer mode from sysfs. 2. Run relevant tests. 3. On a kernel panic, all coresight blocks are disabled, necessary metadata is synced by kernel panic handler. System would eventually reboot or boot a crashdump kernel. 4. For platforms that supports crashdump kernel, raw trace data can be dumped using the coresight sysfs interface from the crashdump kernel itself. Persistent RAM is not a requirement in this case. 5. For platforms that supports persistent RAM, trace data can be dumped using the coresight sysfs interface in the subsequent Linux boot. Crashdump kernel is not a requirement in this case. Persistent RAM ensures that trace data is intact across reboot. Coresight trace capture: Watchdog reset --------------------------------------- The main difference between addressing the watchdog reset and kernel panic case are below, a. Saving coresight metadata need to be taken care by the SCP(system control processor) firmware in the specified format, instead of kernel. b. Reserved memory region given by firmware for trace buffer and metadata has to be in persistent RAM. Note: This is a requirement for watchdog reset case but optional in kernel panic case. Watchdog reset can be supported only on platforms that meet the above two requirements. Testing Kernel panic on Linux 6.7 --------------------------------- 1. Enable the preloaded ETM configuration #mount -t configfs configs /config #panic_addr=`cat /proc/kallsyms | grep "\<panic\>" | awk '{print $1}'` #cd /config/cs-syscfg/features/gen_etrig/params #echo "0x$panic_addr" > address/value #echo 1 > /config/cs-syscfg/configurations/panicstop/enable 2. Configure CTI using sysfs interface #./cti_setup.sh #cat cti_setup.sh cd /sys/bus/coresight/devices/ ap_cti_config () { #ETM trig out[0] trigger to Channel 0 echo 0 4 > channels/trigin_attach } etf_cti_config () { #ETF Flush in trigger from Channel 0 echo 0 1 > channels/trigout_attach echo 1 > channels/trig_filter_enable } etr_cti_config () { #ETR Flush in from Channel 0 echo 0 1 > channels/trigout_attach echo 1 > channels/trig_filter_enable } ctidevs=`find . -name "cti*"` for i in $ctidevs do cd $i connection=`find . -name "ete*"` if [ ! -z "$connection" ] then echo "AP CTI config for $i" ap_cti_config fi connection=`find . -name "tmc_etf*"` if [ ! -z "$connection" ] then echo "ETF CTI config for $i" etf_cti_config fi connection=`find . -name "tmc_etr*"` if [ ! -z "$connection" ] then echo "ETR CTI config for $i" etr_cti_config fi cd .. done Note: CTI connections are SOC specific and hence the above script is added just for reference. 3. Choose reserved buffer mode for ETR buffer #echo "resrv" > /sys/bus/coresight/devices/tmc_etr0/buf_mode_preferred 4. Start Coresight tracing on cores 1 and 2 using sysfs interface 5. Run some application on core 1 #taskset -c 1 dd if=/dev/urandom of=/dev/null & 6. Invoke kernel panic on core 2 #echo 1 > /proc/sys/kernel/panic #taskset -c 2 echo c > /proc/sysrq-trigger 7. From rebooted kernel or crashdump kernel, enable previous boot mode #echo 1 > /sys/bus/coresight/devices/tmc_etr0/read_prevboot Note: For crashdump kernel option, please make sure "crash_kexec_post_notifiers" is added to the kernel bootargs. 8. Read trace data #dd if=/dev/tmc_etr0 of=/trace/cstrace.bin 9. Run opencsd decoder tools/scripts to generate the instruction trace. Sample Core 1 instruction trace dump: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A etm4_enable_hw: ffff800008ae1dd4 CONTEXT EL2 etm4_enable_hw: ffff800008ae1dd4 I etm4_enable_hw: ffff800008ae1dd4: d503201f nop I etm4_enable_hw: ffff800008ae1dd8: d503201f nop I etm4_enable_hw: ffff800008ae1ddc: d503201f nop I etm4_enable_hw: ffff800008ae1de0: d503201f nop I etm4_enable_hw: ffff800008ae1de4: d503201f nop I etm4_enable_hw: ffff800008ae1de8: d503233f paciasp I etm4_enable_hw: ffff800008ae1dec: a9be7bfd stp x29, x30, [sp, #-32]! I etm4_enable_hw: ffff800008ae1df0: 910003fd mov x29, sp I etm4_enable_hw: ffff800008ae1df4: a90153f3 stp x19, x20, [sp, #16] I etm4_enable_hw: ffff800008ae1df8: 2a0003f4 mov w20, w0 I etm4_enable_hw: ffff800008ae1dfc: 900085b3 adrp x19, ffff800009b95000 <reserved_mem+0xc48> I etm4_enable_hw: ffff800008ae1e00: 910f4273 add x19, x19, #0x3d0 I etm4_enable_hw: ffff800008ae1e04: f8747a60 ldr x0, [x19, x20, lsl #3] E etm4_enable_hw: ffff800008ae1e08: b4000140 cbz x0, ffff800008ae1e30 <etm4_starting_cpu+0x50> I 149.039572921 etm4_enable_hw: ffff800008ae1e30: a94153f3 ldp x19, x20, [sp, #16] I 149.039572921 etm4_enable_hw: ffff800008ae1e34: 52800000 mov w0, #0x0 // #0 I 149.039572921 etm4_enable_hw: ffff800008ae1e38: a8c27bfd ldp x29, x30, [sp], #32 ..snip 149.052324811 chacha_block_generic: ffff800008642d80: 9100a3e0 add x0, I 149.052324811 chacha_block_generic: ffff800008642d84: b86178a2 ldr w2, [x5, x1, lsl #2] I 149.052324811 chacha_block_generic: ffff800008642d88: 8b010803 add x3, x0, x1, lsl #2 I 149.052324811 chacha_block_generic: ffff800008642d8c: b85fc063 ldur w3, [x3, #-4] I 149.052324811 chacha_block_generic: ffff800008642d90: 0b030042 add w2, w2, w3 I 149.052324811 chacha_block_generic: ffff800008642d94: b8217882 str w2, [x4, x1, lsl #2] I 149.052324811 chacha_block_generic: ffff800008642d98: 91000421 add x1, x1, #0x1 I 149.052324811 chacha_block_generic: ffff800008642d9c: f100443f cmp x1, #0x11 Sample Core 2 instruction trace dump(kernel panic triggered core): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A etm4_enable_hw: ffff800008ae1dd4 CONTEXT EL2 etm4_enable_hw: ffff800008ae1dd4 I etm4_enable_hw: ffff800008ae1dd4: d503201f nop I etm4_enable_hw: ffff800008ae1dd8: d503201f nop I etm4_enable_hw: ffff800008ae1ddc: d503201f nop I etm4_enable_hw: ffff800008ae1de0: d503201f nop I etm4_enable_hw: ffff800008ae1de4: d503201f nop I etm4_enable_hw: ffff800008ae1de8: d503233f paciasp I etm4_enable_hw: ffff800008ae1dec: a9be7bfd stp x29, x30, [sp, #-32]! I etm4_enable_hw: ffff800008ae1df0: 910003fd mov x29, sp I etm4_enable_hw: ffff800008ae1df4: a90153f3 stp x19, x20, [sp, #16] I etm4_enable_hw: ffff800008ae1df8: 2a0003f4 mov w20, w0 I etm4_enable_hw: ffff800008ae1dfc: 900085b3 adrp x19, ffff800009b95000 <reserved_mem+0xc48> I etm4_enable_hw: ffff800008ae1e00: 910f4273 add x19, x19, #0x3d0 I etm4_enable_hw: ffff800008ae1e04: f8747a60 ldr x0, [x19, x20, lsl #3] E etm4_enable_hw: ffff800008ae1e08: b4000140 cbz x0, ffff800008ae1e30 <etm4_starting_cpu+0x50> I 149.046243445 etm4_enable_hw: ffff800008ae1e30: a94153f3 ldp x19, x20, [sp, #16] I 149.046243445 etm4_enable_hw: ffff800008ae1e34: 52800000 mov w0, #0x0 // #0 I 149.046243445 etm4_enable_hw: ffff800008ae1e38: a8c27bfd ldp x29, x30, [sp], #32 I 149.046243445 etm4_enable_hw: ffff800008ae1e3c: d50323bf autiasp E 149.046243445 etm4_enable_hw: ffff800008ae1e40: d65f03c0 ret A ete_sysreg_write: ffff800008adfa18 ..snip I 149.05422547 panic: ffff800008096300: a90363f7 stp x23, x24, [sp, #48] I 149.05422547 panic: ffff800008096304: 6b00003f cmp w1, w0 I 149.05422547 panic: ffff800008096308: 3a411804 ccmn w0, #0x1, #0x4, ne // ne = any N 149.05422547 panic: ffff80000809630c: 540001e0 b.eq ffff800008096348 <panic+0xe0> // b.none I 149.05422547 panic: ffff800008096310: f90023f9 str x25, [sp, #64] E 149.05422547 panic: ffff800008096314: 97fe44ef bl ffff8000080276d0 <panic_smp_self_stop> A panic: ffff80000809634c I 149.05422547 panic: ffff80000809634c: 910102d5 add x21, x22, #0x40 I 149.05422547 panic: ffff800008096350: 52800020 mov w0, #0x1 // #1 E 149.05422547 panic: ffff800008096354: 94166b8b bl ffff800008631180 <bust_spinlocks> N 149.054225518 bust_spinlocks: ffff800008631180: 340000c0 cbz w0, ffff800008631198 <bust_spinlocks+0x18> I 149.054225518 bust_spinlocks: ffff800008631184: f000a321 adrp x1, ffff800009a98000 <pbufs.0+0xbb8> I 149.054225518 bust_spinlocks: ffff800008631188: b9405c20 ldr w0, [x1, #92] I 149.054225518 bust_spinlocks: ffff80000863118c: 11000400 add w0, w0, #0x1 I 149.054225518 bust_spinlocks: ffff800008631190: b9005c20 str w0, [x1, #92] E 149.054225518 bust_spinlocks: ffff800008631194: d65f03c0 ret A panic: ffff800008096358 TODO ---- * Explore changing CTI sysfs script to system configuration manager profile * Explore Perf based trace capture and decode Links: 1. https://lore.kernel.org/linux-arm-kernel/20230818082112.554638-1-anshuman.k… Linu Cherian (7): dt-bindings: arm: coresight-tmc: Add "memory-region" property coresight: tmc-etr: Add support to use reserved trace memory coresight: core: Add provision for panic callbacks coresight: tmc: Enable panic sync handling coresight: tmc: Add support for reading tracedata from previous boot coresight: tmc: Stop trace capture on FlIn coresight: config: Add preloaded configuration .../bindings/arm/arm,coresight-tmc.yaml | 25 ++ drivers/hwtracing/coresight/Makefile | 2 +- .../coresight/coresight-cfg-preload.c | 2 + .../coresight/coresight-cfg-preload.h | 2 + .../hwtracing/coresight/coresight-cfg-pstop.c | 83 +++++ drivers/hwtracing/coresight/coresight-core.c | 32 ++ .../coresight/coresight-etm4x-core.c | 1 + .../hwtracing/coresight/coresight-tmc-core.c | 173 +++++++++- .../hwtracing/coresight/coresight-tmc-etf.c | 146 ++++++++- .../hwtracing/coresight/coresight-tmc-etr.c | 309 +++++++++++++++++- drivers/hwtracing/coresight/coresight-tmc.h | 76 +++++ include/linux/coresight.h | 25 ++ 12 files changed, 870 insertions(+), 6 deletions(-) create mode 100644 drivers/hwtracing/coresight/coresight-cfg-pstop.c -- 2.34.1

3 months, 3 weeks

[PATCH 0/3] perf scripts python: arm-cs-trace-disasm.py:

by Ruidong Tian

Now the instruction flow disasmed by arm-cs-trace-disasm.py is ambiguous and uncorrect, fix them in one patch set. Please refer to each patch for details. Ruidong Tian (3): perf scripts python: arm-cs-trace-disasm.py: print dso base address perf scripts python: arm-cs-trace-disasm.py: set start vm addr of exectable file to 0 perf scripts python: arm-cs-trace-disasm.py: do not ignore disam first sample .../scripts/python/arm-cs-trace-disasm.py | 28 +++++++++++-------- 1 file changed, 16 insertions(+), 12 deletions(-) -- 2.33.1

3 months, 3 weeks

Re: [PATCH v2 1/2] dt-bindings: arm: coresight: Remove pattern match of ETE node name

by Jinlong Mao

On 1/17/2024 3:53 PM, Krzysztof Kozlowski wrote: > On 17/01/2024 08:49, Jinlong Mao wrote: >> >> >> On 1/17/2024 3:40 PM, Krzysztof Kozlowski wrote: >>> On 17/01/2024 03:14, Jinlong Mao wrote: >>>>>> - const: arm,embedded-trace-extension >>>>>> @@ -55,13 +53,13 @@ examples: >>>>>> # An ETE node without legacy CoreSight connections >>>>>> - | >>>>>> - ete0 { >>>>>> + ete-0 { >>>>> >>>>> Why do we need the number ? why not simply "ete" as Krzysztof suggested ? >>>>> >>>> >>>> Hi Suzuki & Krzysztof , >>>> >>>> If name all the ete nodes' name as 'ete', there will be error below when >>>> build images. >>>> >>>> arch/arm64/boot/dts/qcom/sm8450.dtsi:301.6-312.4: ERROR >>> >>> Why are you pasting DTSI for binding? How is it related? Do we talk >>> about DTSI here? No, this is a binding patch. >>> >> >> Hi Krzysztof, >> >> Do you mean the name in DTSI can be different from the name in binding ? > > Yes, we do not talk about DTSI here, so I did not suggest anything about > DTSI. Ok. I will use 'ete' as the name here. Thanks Jinlong Mao > > Best regards, > Krzysztof >

3 months, 3 weeks

Re: [PATCH v2 1/2] dt-bindings: arm: coresight: Remove pattern match of ETE node name

by Jinlong Mao

On 1/17/2024 3:40 PM, Krzysztof Kozlowski wrote: > On 17/01/2024 03:14, Jinlong Mao wrote: >>>> - const: arm,embedded-trace-extension >>>> @@ -55,13 +53,13 @@ examples: >>>> # An ETE node without legacy CoreSight connections >>>> - | >>>> - ete0 { >>>> + ete-0 { >>> >>> Why do we need the number ? why not simply "ete" as Krzysztof suggested ? >>> >> >> Hi Suzuki & Krzysztof , >> >> If name all the ete nodes' name as 'ete', there will be error below when >> build images. >> >> arch/arm64/boot/dts/qcom/sm8450.dtsi:301.6-312.4: ERROR > > Why are you pasting DTSI for binding? How is it related? Do we talk > about DTSI here? No, this is a binding patch. > Hi Krzysztof, Do you mean the name in DTSI can be different from the name in binding ? Thanks Jinlong Mao >

3 months, 3 weeks

[PATCH v2 0/2] arm64: dts: qcom: Add coresight nodes for sm8450

by Mao Jinlong

Add coresight components on Qualcomm SM8450 Soc. The components include TMC ETF/ETR, ETE, STM, TPDM, CTI. And remove the pattern of ete node name. Change since V1: 1. Remove the pattern match of ETE node name. 2. Update the tmc-etr node name in DT. Mao Jinlong (2): dt-bindings: arm: coresight: Remove pattern match of ETE node name arm64: dts: qcom: Add coresight nodes for sm8450 .../arm/arm,embedded-trace-extension.yaml | 6 +- arch/arm64/boot/dts/qcom/sm8450.dtsi | 742 ++++++++++++++++++ 2 files changed, 744 insertions(+), 4 deletions(-) -- 2.41.0

3 months, 3 weeks

[PATCH v2 0/2] coresight: core: Add device name support

by Mao Jinlong

With current design, the name of the non-cpu bounded coresight component is the device type with the number. And with 'ls' command we can get the register address of the component. But from these information, we can't know what the HW or system the component belongs to. Add device-name in DT to support it. cti_sys0 -> ../../../devices/platform/soc(a)0/138f0000.cti/cti_sys0 cti_sys1 -> ../../../devices/platform/soc(a)0/13900000.cti/cti_sys1 tpdm0 -> ../../../devices/platform/soc(a)0/10b0d000.tpdm/tpdm0 tpdm1 -> ../../../devices/platform/soc(a)0/10c28000.tpdm/tpdm1 tpdm2 -> ../../../devices/platform/soc(a)0/10c29000.tpdm/tpdm2 Change since V1: 1. Change coresight-name to device name. 2. Add the device-name in coresight dt bindings. Mao Jinlong (2): coresight: core: Add device name support dt-bindings: arm: Add device-name in the coresight components .../bindings/arm/arm,coresight-catu.yaml | 5 +++ .../bindings/arm/arm,coresight-cpu-debug.yaml | 5 +++ .../bindings/arm/arm,coresight-cti.yaml | 5 +++ .../arm/arm,coresight-dummy-sink.yaml | 5 +++ .../arm/arm,coresight-dummy-source.yaml | 5 +++ .../arm/arm,coresight-dynamic-funnel.yaml | 5 +++ .../arm/arm,coresight-dynamic-replicator.yaml | 5 +++ .../bindings/arm/arm,coresight-etb10.yaml | 5 +++ .../bindings/arm/arm,coresight-etm.yaml | 5 +++ .../arm/arm,coresight-static-funnel.yaml | 5 +++ .../arm/arm,coresight-static-replicator.yaml | 5 +++ .../bindings/arm/arm,coresight-stm.yaml | 5 +++ .../bindings/arm/arm,coresight-tmc.yaml | 5 +++ .../bindings/arm/arm,coresight-tpiu.yaml | 5 +++ .../bindings/arm/qcom,coresight-tpda.yaml | 5 +++ .../bindings/arm/qcom,coresight-tpdm.yaml | 5 +++ drivers/hwtracing/coresight/coresight-core.c | 33 ++++++++++--------- .../hwtracing/coresight/coresight-platform.c | 31 +++++++++++++++++ include/linux/coresight.h | 1 + 19 files changed, 130 insertions(+), 15 deletions(-) -- 2.41.0

3 months, 3 weeks

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight January 2024