CoreSight June 2024

coresight@lists.linaro.org

5 participants
13 discussions

Re: [PATCH v1 0/2] perf mem: Support multiple Arm SPE PMUs

by James Clark

On 23/06/2024 14:34, Leo Yan wrote: > This patch series is to enable multiple Arm SPE PMUs. > > The patch 01 is to enable multiple Arm SPE PMUs. The second patch is to > print out warning if not all CPUs support memory events, this can give > users a hint that the memory profiling is absent on some CPUs. > > > Leo Yan (2): > perf arm-spe: Support multiple Arm SPE PMUs > perf mem: Warn if memory events are not supported on all CPUs > > tools/perf/arch/arm/util/pmu.c | 2 +- > tools/perf/util/mem-events.c | 14 ++++++++++++++ > 2 files changed, 15 insertions(+), 1 deletion(-) > Reviewed-by: James Clark <james.clark(a)arm.com>

2 hours, 56 minutes

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

by Linu Cherian

This patch series is rebased on coresight-next-v6.10. Changelog from v8: * Added missing exit path on error in __tmc_probe. * Few whitespace fixes, checkpatch fixes. * With perf sessions honouring stop_on_flush sysfs attribute, removed redundant variable stop_on_flush_en. Changelog from v7: * Fixed breakage on perf test -vvvv "arm coresight". No issues seen with and without "resrv" buffer mode * Moved the crashdev registration into a seperate function. * Removed redundant variable in tmc_etr_setup_crashdata_buf * Avoided a redundant memcpy in tmc_panic_sync_etf. * Tested kernel panic with trace session started uisng perf. Please see the title "Perf based testing" below for details. For this, stop_on_flush sysfs attribute is taken into consideration while starting perf sessions as well. Changelog from v6: * Added special device files for reading crashdata, so that read_prevboot mode flag is removed. * Added new sysfs TMC device attribute, stop_on_flush. Stop on flush trigger event is disabled by default. User need to explicitly enable this from sysfs for panic stop to work. * Address parameter for panicstop ETM configuration is chosen as kernel "panic" address by default. * Added missing tmc_wait_for_tmcready during panic handling * Few other misc code rearrangements. 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. v8 is posted here: https://lore.kernel.org/lkml/20240531042745.494222-4-lcherian@marvell.com/T/ 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. Dump trace buffer crashdata to a file, #dd if=/dev/crash_tmc_etrXX of=~/cstrace.bin 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.8 --------------------------------- 1. Enable the preloaded ETM configuration #echo 1 > /sys/kernel/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. Enable stop on flush trigger configuration #echo 1 > /sys/bus/coresight/devices/tmc_etr0/stop_on_flush 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, read crashdata Note: For crashdump kernel option, please make sure "crash_kexec_post_notifiers" is added to the kernel bootargs. #dd if=/dev/crash_tmc_etr0 of=/trace/cstrace.bin 8. 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 Perf based testing ------------------ Kernel panic during perf trace sessions has been tested with this series. Starting perf session ~~~~~~~~~~~~~~~~~~~~~ ETF: ./tools/perf/perf record -e cs_etm/panicstop,@tmc_etf1/ -C 1 ./tools/perf/perf record -e cs_etm/panicstop,@tmc_etf2/ -C 2 ETR: ./tools/perf/perf record -e cs_etm/panicstop,@tmc_etr0/ -C 1,2 Reading trace data after panic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Same sysfs based method explained above can be used to retrieve and decode the trace data after the reboot on kernel panic. Future Improvements ------------------- * Explore changing CTI sysfs script to system configuration manager profile 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 crash data coresight: tmc: Stop trace capture on FlIn coresight: config: Add preloaded configuration .../bindings/arm/arm,coresight-tmc.yaml | 26 ++ 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 | 37 +++ .../coresight/coresight-etm4x-core.c | 1 + .../hwtracing/coresight/coresight-tmc-core.c | 253 +++++++++++++- .../hwtracing/coresight/coresight-tmc-etf.c | 156 ++++++++- .../hwtracing/coresight/coresight-tmc-etr.c | 312 +++++++++++++++++- drivers/hwtracing/coresight/coresight-tmc.h | 81 +++++ include/linux/coresight.h | 25 ++ 12 files changed, 962 insertions(+), 18 deletions(-) create mode 100644 drivers/hwtracing/coresight/coresight-cfg-pstop.c -- 2.34.1

3 days, 1 hour

Re: [PATCH] coresight: constify the struct device_type usage

by Suzuki K Poulose

On Mon, 19 Feb 2024 10:43:05 -0300, Ricardo B. Marliere wrote: > Since commit aed65af1cc2f ("drivers: make device_type const"), the driver > core can properly handle constant struct device_type. Move the > coresight_dev_type variable to be a constant structure as well, placing it > into read-only memory which can not be modified at runtime. > > Applied, thanks! [1/1] coresight: constify the struct device_type usage https://git.kernel.org/coresight/c/4dcc0f95ca2a9738e5e4e3bd7571fd95a9cbf272 Best regards, -- Suzuki K Poulose <suzuki.poulose(a)arm.com>

3 days, 3 hours

Re: [PATCH v1 1/3] dt-bindings: arm: Add binding document for Coresight Slave Register device.

by Suzuki K Poulose

On 18/06/2024 08:27, Jie Gan wrote: > Add binding document for Coresight Slave Register device. Is this a made up name of the driver ? CoreSight Slave Register device sounds nowhere near to what it does. If you have a proper name for the "IP" please use that. > > Add a new property to TMC, qcom,csr-atid-offset, to indicate which > ATID registers will be used by the TMC ETR. Each TMC ETR device is > associated with four ATID registers that are continuous in address. > > Signed-off-by: Jie Gan <quic_jiegan(a)quicinc.com> > --- > .../bindings/arm/arm,coresight-tmc.yaml | 8 ++ > .../bindings/arm/qcom,coresight-csr.yaml | 76 +++++++++++++++++++ > 2 files changed, 84 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-csr.yaml > > diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml > index cb8dceaca70e..295641a96c21 100644 > --- a/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml > +++ b/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml > @@ -82,6 +82,14 @@ properties: > $ref: /schemas/types.yaml#/definitions/uint32 > maximum: 15 > > + qcom,csr-atid-offset: > + description: > + Offset to the coresight slave register component's ATID register > + that is used by specific TMC ETR. The ATID register can be programed according > + to the trace id to filter out specific trace data which gets through the ETR > + to the downstream components. > + $ref: /schemas/types.yaml#/definitions/uint32 Why do we need this ? Could this not be inferred from the "input port" to which this ETR is connected on the CSR ? e.g., input-0 : Offset 0 input-1 : Offset for Bank1 > + > in-ports: > $ref: /schemas/graph.yaml#/properties/ports > additionalProperties: false > diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-csr.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-csr.yaml > new file mode 100644 > index 000000000000..16f97cbe3d4b > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-csr.yaml > @@ -0,0 +1,76 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/qcom,coresight-csr.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: CoreSight Slave Register > + > +maintainers: > + - Yuanfang Zhang <quic_yuanfang(a)quicinc.com> > + - Mao Jinlong <quic_jinlmao(a)quicinc.com> > + - Jie Gan <quic_jiegan(a)quicinc.com> > + > +description: > + The Coresight Slave Register controls various Coresight behaviors. > + Used to enable/disable ETR’s data filter function based on trace ID. > + > +properties: > + compatible: > + const: qcom,coresight-csr > + > + reg: > + maxItems: 1 > + > + clocks: > + maxItems: 1 > + > + clock-names: > + maxItems: 1 > + items: > + - const: apb_pclk > + > + reg-names: > + items: > + - const: csr-base > + > + in-ports: > + $ref: /schemas/graph.yaml#/properties/ports > + > + patternProperties: > + '^port(@[0-7])?$': > + description: Input connections from CoreSight Trace bus > + $ref: /schemas/graph.yaml#/properties/port > + > +required: > + - compatible > + - reg > + - in-ports > + > +additionalProperties: false > + > +examples: > + - | > + syscon@10001000 { > + compatible = "qcom,coresight-csr"; > + reg = <0x0 0x10001000 0x0 0x1000>; > + reg-names = "csr-base"; > + > + in-ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + csr_in_port0: endpoint { > + remote-endpoint = <&etr0_out_port>; > + }; > + }; > + > + port@1 { > + reg = <1>; > + csr_in_port1: endpoint { > + remote-endpoint = <&etr1_out_port>; > + }; > + }; > + }; > + };

6 days, 2 hours

Re: [PATCH v1 0/3] Add coresight slave register driver to support data filter function

by Suzuki K Poulose

On 18/06/2024 08:27, Jie Gan wrote: > The Coresight Slave Register(CSR) device hosts miscellaneous configuration > registers to control various features related to TMC ETR device. > > The CSR device works as a helper device physically connected to the TMC ETR device. > --------------------------------------------------------- > |ETR0| |ETR1| > . \ / . > . \ / . > . \ / . > . \ / . > --------------------------------------------------- > ETR0ATID0-ETR0ATID3 CSR ETR1ATID0-ETR1ATID3 > --------------------------------------------------- > Each ETR has four ATID registers with 128 bits long in total. > e.g. ETR0ATID0-ETR0ATID3 registers are used by ETR0 device. What is the maximum number of connections possible for CSR ? 2 ETRs ? > > Based on the trace id which is programed in CSR ATID register of > specific ETR, trace data with that trace id can get into ETR's buffer How do you handle cases where there are multiple TraceIDs in a the stream ? e.g., perf tracing a multi-threaded app ? Each ETM will have a distinct traceid. Is there way to disable filtering by CSR ? Side note, with James's trace id allocation per sink series makes this easier for the ETR to know the trace ids allocated for the current session. Works only for perf though. > while other trace data gets ignored. CSR may contain several ATID registers. > Each ATID register is associated with an ETR device. > > To achieve this function, the trace id is obtained and stored in the related > ETR device's driver data just before enabling the CSR. Then, the CSR > device can easily obtain the trace ID from the ETR's driver data because the > ETR's driver data is passed to the CSR's enable/disable functions. > > Ensure that every source device has already allocated a trace ID in its probe > session because the sink device should always be the first device to How is that possible ? We are going backwards in the trace id allocation with your proposal. What is the purpose of this hardware when you could use a replicator with trace filtering based on masks ? > enable when operating coresight_enable_path function. As a helper device of the > ETR, the CSR device will program the ATID register of a specific ETR according to > the trace id to enable data filter function at a very early stage. Without the > correct trace ID, the enablement session will not work. > > Each CSR's enable session will set one bit in the ATID register. So is this a bitmap of "enable/disable" ATID ? I really don't see the usecase of the CSR "device" yet. Please could you share "usecase" ? Suzuki > Every CSR's disbale seesion will reset all bits of the ATID register. > > This patch only supports sysfs mode. I will send the perf mode part patch > once it is ready. > > Looking forward to receiving comments as this is a new driver. > > Thanks! > > Jie Gan (3): > dt-bindings: arm: Add binding document for Coresight Slave Register > device. > coresight: Add coresight slave register driver to support data filter > function in sysfs mode > arm64: dts: qcom: Add CSR and ETR nodes for SA8775p > > .../bindings/arm/arm,coresight-tmc.yaml | 8 + > .../bindings/arm/qcom,coresight-csr.yaml | 49 +++ > arch/arm64/boot/dts/qcom/sa8775p.dtsi | 167 ++++++++++ > drivers/hwtracing/coresight/Kconfig | 6 + > drivers/hwtracing/coresight/Makefile | 1 + > drivers/hwtracing/coresight/coresight-core.c | 6 +- > drivers/hwtracing/coresight/coresight-csr.c | 315 ++++++++++++++++++ > drivers/hwtracing/coresight/coresight-csr.h | 24 ++ > .../coresight/coresight-etm4x-core.c | 1 + > drivers/hwtracing/coresight/coresight-stm.c | 50 --- > drivers/hwtracing/coresight/coresight-sysfs.c | 45 ++- > .../hwtracing/coresight/coresight-tmc-core.c | 1 + > drivers/hwtracing/coresight/coresight-tmc.h | 2 + > include/linux/coresight-stm.h | 44 +++ > 14 files changed, 665 insertions(+), 54 deletions(-) > create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-csr.yaml > create mode 100644 drivers/hwtracing/coresight/coresight-csr.c > create mode 100644 drivers/hwtracing/coresight/coresight-csr.h >

6 days, 3 hours

[PATCH v3 00/14] coresight: Use per-sink trace ID maps for Perf sessions

by James Clark

This will allow sessions with more than CORESIGHT_TRACE_IDS_MAX ETMs as long as there are fewer than that many ETMs connected to each sink. Each sink owns its own trace ID map, and any Perf session connecting to that sink will allocate from it, even if the sink is currently in use by other users. This is similar to the existing behavior where the dynamic trace IDs are constant as long as there is any concurrent Perf session active. It's not completely optimal because slightly more IDs will be used than necessary, but the optimal solution involves tracking the PIDs of each session and allocating ID maps based on the session owner. This is difficult to do with the combination of per-thread and per-cpu modes and some scheduling issues. The complexity of this isn't likely to worth it because even with multiple users they'd just see a difference in the ordering of ID allocations rather than hitting any limits (unless the hardware does have too many ETMs connected to one sink). Per-thread mode works but only until there are any overlapping IDs, at which point Perf will error out. Both per-thread mode and sysfs mode are left to future changes, but both can be added on top of this initial implementation and only sysfs mode requires further driver changes. The HW_ID version field hasn't been bumped in order to not break Perf which already has an error condition for other values of that field. Instead a new minor version has been added which signifies that there are new fields but the old fields are backwards compatible. Changes since v2: * Rebase on coresight-next 6.10-rc2 (b9b25c8496). * Fix double free of csdev if device registration fails. * Fix leak of coresight_trace_id_perf_start() if trace ID allocation fails. * Don't resend HW_ID for sink changes in per-thread mode. The existing CPU field on AUX records can be used to track this instead. * Tidy function doc for coresight_trace_id_release_all() * Drop first two commits now that they are in coresight-next * Add a commit to make the trace ID spinlock local to the map Changes since V1: * Rename coresight_device.perf_id_map to perf_sink_id_map. * Instead of outputting a HW_ID for each reachable ETM, output the sink ID and continue to output only the HW_ID once for each mapping. * Keep the first two Perf patches so that it applies cleanly on coresight-next, although they have been applied on perf-tools-next * Add new *_map() functions to the trace ID public API instead of modifying existing ones. * Collapse "coresight: Pass trace ID map into source enable" into "coresight: Use per-sink trace ID maps for Perf sessions" because the first commit relied on the default map being accessible which is no longer necessary due to the previous bullet point. James Clark (14): perf: cs-etm: Create decoders after both AUX and HW_ID search passes perf: cs-etm: Allocate queues for all CPUs perf: cs-etm: Move traceid_list to each queue perf: cs-etm: Create decoders based on the trace ID mappings perf: cs-etm: Support version 0.1 of HW_ID packets coresight: Remove unused ETM Perf stubs coresight: Clarify comments around the PID of the sink owner coresight: Move struct coresight_trace_id_map to common header coresight: Expose map arguments in trace ID API coresight: Make CPU id map a property of a trace ID map coresight: Use per-sink trace ID maps for Perf sessions coresight: Remove pending trace ID release mechanism coresight: Emit sink ID in the HW_ID packets coresight: Make trace ID map spinlock local to the map drivers/hwtracing/coresight/coresight-core.c | 37 +- drivers/hwtracing/coresight/coresight-dummy.c | 3 +- .../hwtracing/coresight/coresight-etm-perf.c | 36 +- .../hwtracing/coresight/coresight-etm-perf.h | 18 - .../coresight/coresight-etm3x-core.c | 9 +- .../coresight/coresight-etm4x-core.c | 9 +- drivers/hwtracing/coresight/coresight-priv.h | 1 + drivers/hwtracing/coresight/coresight-stm.c | 3 +- drivers/hwtracing/coresight/coresight-sysfs.c | 3 +- .../hwtracing/coresight/coresight-tmc-etr.c | 5 +- drivers/hwtracing/coresight/coresight-tmc.h | 5 +- drivers/hwtracing/coresight/coresight-tpdm.c | 3 +- .../hwtracing/coresight/coresight-trace-id.c | 133 ++-- .../hwtracing/coresight/coresight-trace-id.h | 70 +- include/linux/coresight-pmu.h | 17 +- include/linux/coresight.h | 21 +- tools/include/linux/coresight-pmu.h | 17 +- .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 28 +- tools/perf/util/cs-etm.c | 600 +++++++++++------- tools/perf/util/cs-etm.h | 2 +- 20 files changed, 614 insertions(+), 406 deletions(-) -- 2.34.1

1 week, 5 days

[PATCH v2 00/16] coresight: Use per-sink trace ID maps for Perf sessions

by James Clark

This will allow sessions with more than CORESIGHT_TRACE_IDS_MAX ETMs as long as there are fewer than that many ETMs connected to each sink. Each sink owns its own trace ID map, and any Perf session connecting to that sink will allocate from it, even if the sink is currently in use by other users. This is similar to the existing behavior where the dynamic trace IDs are constant as long as there is any concurrent Perf session active. It's not completely optimal because slightly more IDs will be used than necessary, but the optimal solution involves tracking the PIDs of each session and allocating ID maps based on the session owner. This is difficult to do with the combination of per-thread and per-cpu modes and some scheduling issues. The complexity of this isn't likely to worth it because even with multiple users they'd just see a difference in the ordering of ID allocations rather than hitting any limits (unless the hardware does have too many ETMs connected to one sink). Per-thread mode works but only until there are any overlapping IDs, at which point Perf will error out. Both per-thread mode and sysfs mode are left to future changes, but both can be added on top of this initial implementation and only sysfs mode requires further driver changes. The HW_ID version field hasn't been bumped in order to not break Perf which already has an error condition for other values of that field. Instead a new minor version has been added which signifies that there are new fields but the old fields are backwards compatible. Changes since V1: * Rename coresight_device.perf_id_map to perf_sink_id_map. * Instead of outputting a HW_ID for each reachable ETM, output the sink ID and continue to output only the HW_ID once for each mapping. * Keep the first two Perf patches so that it applies cleanly on coresight-next, although they have been applied on perf-tools-next * Add new *_map() functions to the trace ID public API instead of modifying existing ones. * Collapse "coresight: Pass trace ID map into source enable" into "coresight: Use per-sink trace ID maps for Perf sessions" because the first commit relied on the default map being accessible which is no longer necessary due to the previous bullet point. James Clark (16): perf cs-etm: Print error for new PERF_RECORD_AUX_OUTPUT_HW_ID versions perf auxtrace: Allow number of queues to be specified perf: cs-etm: Create decoders after both AUX and HW_ID search passes perf: cs-etm: Allocate queues for all CPUs perf: cs-etm: Move traceid_list to each queue perf: cs-etm: Create decoders based on the trace ID mappings perf: cs-etm: Support version 0.1 of HW_ID packets coresight: Remove unused ETM Perf stubs coresight: Clarify comments around the PID of the sink owner coresight: Move struct coresight_trace_id_map to common header coresight: Expose map arguments in trace ID API coresight: Make CPU id map a property of a trace ID map coresight: Use per-sink trace ID maps for Perf sessions coresight: Remove pending trace ID release mechanism coresight: Re-emit trace IDs when the sink changes in per-thread mode coresight: Emit sink ID in the HW_ID packets drivers/hwtracing/coresight/coresight-core.c | 36 +- drivers/hwtracing/coresight/coresight-dummy.c | 3 +- .../hwtracing/coresight/coresight-etm-perf.c | 50 +- .../hwtracing/coresight/coresight-etm-perf.h | 20 +- .../coresight/coresight-etm3x-core.c | 9 +- .../coresight/coresight-etm4x-core.c | 9 +- drivers/hwtracing/coresight/coresight-priv.h | 1 + drivers/hwtracing/coresight/coresight-stm.c | 3 +- drivers/hwtracing/coresight/coresight-sysfs.c | 3 +- .../hwtracing/coresight/coresight-tmc-etr.c | 5 +- drivers/hwtracing/coresight/coresight-tmc.h | 5 +- drivers/hwtracing/coresight/coresight-tpdm.c | 3 +- .../hwtracing/coresight/coresight-trace-id.c | 109 ++-- .../hwtracing/coresight/coresight-trace-id.h | 70 +- include/linux/coresight-pmu.h | 17 +- include/linux/coresight.h | 20 +- tools/include/linux/coresight-pmu.h | 17 +- tools/perf/util/auxtrace.c | 9 +- tools/perf/util/auxtrace.h | 1 + .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 28 +- tools/perf/util/cs-etm.c | 603 ++++++++++++------ tools/perf/util/cs-etm.h | 2 +- 22 files changed, 628 insertions(+), 395 deletions(-) -- 2.34.1

1 week, 6 days

Re: [PATCH -next] coresight: tmc: Remove duplicated include in coresight-tmc-core.c

by Suzuki K Poulose

On Mon, 6 May 2024 09:11:21 +0800, Yang Li wrote: > The header files linux/acpi.h is included twice in coresight-tmc-core.c, > so one inclusion of each can be removed. > > Applied, thanks! [1/1] coresight: tmc: Remove duplicated include in coresight-tmc-core.c https://git.kernel.org/coresight/c/b9b25c8496019402ecd64ddc5ae56f9bd97b12b2 Best regards, -- Suzuki K Poulose <suzuki.poulose(a)arm.com>

2 weeks

[PATCH] coresight: Fix ref leak when of_coresight_parse_endpoint() fails

by James Clark

of_graph_get_next_endpoint() releases the reference to the previous endpoint on each iteration, but when parsing fails the loop exits early meaning the last reference is never dropped. Fix it by dropping the refcount in the exit condition. Fixes: d375b356e687 ("coresight: Fix support for sparsely populated ports") Signed-off-by: James Clark <james.clark(a)arm.com> --- drivers/hwtracing/coresight/coresight-platform.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/hwtracing/coresight/coresight-platform.c b/drivers/hwtracing/coresight/coresight-platform.c index 9d550f5697fa..57a009552cc5 100644 --- a/drivers/hwtracing/coresight/coresight-platform.c +++ b/drivers/hwtracing/coresight/coresight-platform.c @@ -297,8 +297,10 @@ static int of_get_coresight_platform_data(struct device *dev, continue; ret = of_coresight_parse_endpoint(dev, ep, pdata); - if (ret) + if (ret) { + of_node_put(ep); return ret; + } } return 0; -- 2.34.1

2 weeks

Re: [PATCH v2 02/16] perf auxtrace: Allow number of queues to be specified

by James Clark

On 05/06/2024 06:26, Adrian Hunter wrote: > On 4/06/24 17:30, James Clark wrote: >> Currently it's only possible to initialize with the default number of >> queues and then use auxtrace_queues__add_event() to grow the array. But >> that's problematic if you don't have a real event to pass into that >> function yet. >> >> The queues hold a void *priv member to store custom state, and for >> Coresight we want to create decoders upfront before receiving data, so >> add a new function that allows pre-allocating queues. One reason to do >> this is because we might need to store metadata (HW_ID events) that >> effects other queues, but never actually receive auxtrace data on that >> queue. >> >> Signed-off-by: James Clark <james.clark(a)arm.com> > > Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> > > Again ;-) > Oops yeah I should have picked that up. This one was already applied to perf-tools-next as well. Thanks >> --- >> tools/perf/util/auxtrace.c | 9 +++++++-- >> tools/perf/util/auxtrace.h | 1 + >> 2 files changed, 8 insertions(+), 2 deletions(-) >> >> diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c >> index 3684e6009b63..563b6c4fca31 100644 >> --- a/tools/perf/util/auxtrace.c >> +++ b/tools/perf/util/auxtrace.c >> @@ -218,15 +218,20 @@ static struct auxtrace_queue *auxtrace_alloc_queue_array(unsigned int nr_queues) >> return queue_array; >> } >> >> -int auxtrace_queues__init(struct auxtrace_queues *queues) >> +int auxtrace_queues__init_nr(struct auxtrace_queues *queues, int nr_queues) >> { >> - queues->nr_queues = AUXTRACE_INIT_NR_QUEUES; >> + queues->nr_queues = nr_queues; >> queues->queue_array = auxtrace_alloc_queue_array(queues->nr_queues); >> if (!queues->queue_array) >> return -ENOMEM; >> return 0; >> } >> >> +int auxtrace_queues__init(struct auxtrace_queues *queues) >> +{ >> + return auxtrace_queues__init_nr(queues, AUXTRACE_INIT_NR_QUEUES); >> +} >> + >> static int auxtrace_queues__grow(struct auxtrace_queues *queues, >> unsigned int new_nr_queues) >> { >> diff --git a/tools/perf/util/auxtrace.h b/tools/perf/util/auxtrace.h >> index 55702215a82d..8a6ec9565835 100644 >> --- a/tools/perf/util/auxtrace.h >> +++ b/tools/perf/util/auxtrace.h >> @@ -521,6 +521,7 @@ int auxtrace_mmap__read_snapshot(struct mmap *map, >> struct perf_tool *tool, process_auxtrace_t fn, >> size_t snapshot_size); >> >> +int auxtrace_queues__init_nr(struct auxtrace_queues *queues, int nr_queues); >> int auxtrace_queues__init(struct auxtrace_queues *queues); >> int auxtrace_queues__add_event(struct auxtrace_queues *queues, >> struct perf_session *session, >

2 weeks, 5 days

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight June 2024