CoreSight October 2023

coresight@lists.linaro.org

11 participants
45 discussions

[PATCH v3 0/6] kvm/coresight: Support exclude guest and exclude host

by James Clark

This is a combination of the RFC for nVHE here [1] and v3 of VHE version here [2]. After a few of the review comments it seemed much simpler for both versions to use the same interface and be in the same patchset. FEAT_TRF is a Coresight feature that allows trace capture to be completely filtered at different exception levels, unlike the existing TRCVICTLR controls which may still emit target addresses of branches, even if the following trace is filtered. Without FEAT_TRF, it was possible to start a trace session on a host and also collect trace from the guest as TRCVICTLR was never programmed to exclude guests (and it could still emit target addresses even if it was). With FEAT_TRF, the current behavior of trace in guests exists depends on whether nVHE or VHE are being used. Both of the examples below are from the host's point of view, as Coresight isn't accessible from guests. This patchset is only relevant to when FEAT_TRF exists, otherwise there is no change. nVHE: Because the host and the guest are both using TRFCR_EL1, trace will be generated in guests depending on the same filter rules the host is using. For example if the host is tracing userspace only, then guest userspace trace will also be collected. (This is further limited by whether TRBE is used because an issue with TRBE means that it's completely disabled in nVHE guests, but it's possible to have other tracing components.) VHE: With VHE, the host filters will be in TRFCR_EL2, but the filters in TRFCR_EL1 will be active when the guest is running. Because we don't write to TRFCR_EL1, guest trace will be completely disabled. With this change, the guest filtering rules from the Perf session are honored for both nVHE and VHE modes. This is done by either writing to TRFCR_EL12 at the start of the Perf session and doing nothing else further, or caching the guest value and writing it at guest switch for nVHE. The first commit moves the register to sysreg because I add the EL12 version. --- Changes since V2: * Add a new iflag to signify presence of FEAT_TRF and keep the existing TRBE iflag. This fixes the issue where TRBLIMITR_EL1 was being accessed even if TRBE didn't exist * Reword a commit message Changes since V1: * Squashed all the arm64/tools/sysreg changes into the first commit * Add a new commit to move SPE and TRBE regs into the kvm sysreg array * Add a comment above the TRFCR global that it's per host CPU rather than vcpu Changes since nVHE RFC [1]: * Re-write just in terms of the register value to be written for the host and the guest. This removes some logic from the hyp code and a value of kvm_vcpu_arch:trfcr_el1 = 0 no longer means "don't restore". * Remove all the conditional compilation and new files. * Change the kvm_etm_update_vcpu_events macro to a function. * Re-use DEBUG_STATE_SAVE_TRFCR so iflags don't need to be expanded anymore. * Expand the cover letter. Changes since VHE v3 [2]: * Use the same interface as nVHE mode so TRFCR_EL12 is now written by kvm. [1]: https://lore.kernel.org/kvmarm/20230804101317.460697-1-james.clark@arm.com/ [2]: https://lore.kernel.org/kvmarm/20230905102117.2011094-1-james.clark@arm.com/ James Clark (6): arm64/sysreg: Move TRFCR definitions to sysreg arm64: KVM: Move SPE and trace registers to the sysreg array arm64: KVM: Add iflag for FEAT_TRF arm64: KVM: Add interface to set guest value for TRFCR register arm64: KVM: Write TRFCR value on guest switch with nVHE coresight: Pass guest TRFCR value to KVM arch/arm64/include/asm/kvm_host.h | 13 +-- arch/arm64/include/asm/kvm_hyp.h | 6 +- arch/arm64/include/asm/sysreg.h | 12 --- arch/arm64/kvm/arm.c | 1 + arch/arm64/kvm/debug.c | 48 +++++++++- arch/arm64/kvm/hyp/nvhe/debug-sr.c | 88 +++++++++++-------- arch/arm64/kvm/hyp/nvhe/switch.c | 4 +- arch/arm64/tools/sysreg | 41 +++++++++ .../coresight/coresight-etm4x-core.c | 42 +++++++-- drivers/hwtracing/coresight/coresight-etm4x.h | 2 +- drivers/hwtracing/coresight/coresight-priv.h | 3 + 11 files changed, 192 insertions(+), 68 deletions(-) -- 2.34.1

1 year, 1 month

[PATCH 0/7] Subject: coresight: Move remaining AMBA ACPI devices into platform driver

by Anshuman Khandual

This moves remaining AMBA ACPI devices into respective platform drivers for enabling ACPI based power management support. This series applies on latest coresight/next branch. This series has been built, and boot tested on a DT based coresight platform. Although this still requires some more testing on ACPI based coresight platforms. Cc: Lorenzo Pieralisi <lpieralisi(a)kernel.org> Cc: Sudeep Holla <sudeep.holla(a)arm.com> Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> Cc: Mike Leach <mike.leach(a)linaro.org> Cc: James Clark <james.clark(a)arm.com> Cc: Maxime Coquelin <mcoquelin.stm32(a)gmail.com> Cc: Alexandre Torgue <alexandre.torgue(a)foss.st.com> Cc: linux-acpi(a)vger.kernel.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-kernel(a)vger.kernel.org Cc: coresight(a)lists.linaro.org Cc: linux-stm32(a)st-md-mailman.stormreply.com Changes in V1: - Replaced all IS_ERR() instances with IS_ERR_OR_NULL() as per Suzuki Changes in RFC: https://lore.kernel.org/all/20230921042040.1334641-1-anshuman.khandual@arm.… Anshuman Khandual (7): coresight: replicator: Move ACPI support from AMBA driver to platform driver coresight: funnel: Move ACPI support from AMBA driver to platform driver coresight: catu: Move ACPI support from AMBA driver to platform driver coresight: tpiu: Move ACPI support from AMBA driver to platform driver coresight: tmc: Move ACPI support from AMBA driver to platform driver coresight: stm: Move ACPI support from AMBA driver to platform driver coresight: debug: Move ACPI support from AMBA driver to platform driver drivers/acpi/arm64/amba.c | 8 -- drivers/hwtracing/coresight/coresight-catu.c | 136 ++++++++++++++++-- drivers/hwtracing/coresight/coresight-catu.h | 1 + .../hwtracing/coresight/coresight-cpu-debug.c | 130 +++++++++++++++-- .../hwtracing/coresight/coresight-funnel.c | 49 ++++--- .../coresight/coresight-replicator.c | 44 +++--- drivers/hwtracing/coresight/coresight-stm.c | 80 +++++++++-- .../hwtracing/coresight/coresight-tmc-core.c | 127 ++++++++++++++-- drivers/hwtracing/coresight/coresight-tmc.h | 1 + drivers/hwtracing/coresight/coresight-tpiu.c | 76 +++++++++- 10 files changed, 549 insertions(+), 103 deletions(-) -- 2.25.1

1 year, 1 month

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

by Linu Cherian

This patch series is rebased on v6.6-rc3 and is dependent on the below two patches. - coresight: tmc: Make etr buffer mode user configurable from sysfs[1] - coresight: Fix run time warnings while reusing ETR buffer[2] Changelog from RFC 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. RFC V3 is posted here: https://lore.kernel.org/linux-arm-kernel/20230905153528.GA3428758-robh@kern… 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.6 --------------------------------- 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, enable previous boot mode #echo 1 > /sys/bus/coresight/devices/tmc_etr0/read_prevboot 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 * Reading tracedata from crashdump kernel is not tested. * Perf based trace capture and decode is not tested. Links: 1. https://lore.kernel.org/linux-arm-kernel/20230818082112.554638-1-anshuman.k… 2. https://lore.kernel.org/linux-arm-kernel/20230823042948.12879-1-lcherian@ma… 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 | 19 ++ 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 | 158 +++++++++- .../hwtracing/coresight/coresight-tmc-etf.c | 126 +++++++- .../hwtracing/coresight/coresight-tmc-etr.c | 292 +++++++++++++++++- drivers/hwtracing/coresight/coresight-tmc.h | 50 +++ include/linux/coresight.h | 25 ++ 12 files changed, 786 insertions(+), 6 deletions(-) create mode 100644 drivers/hwtracing/coresight/coresight-cfg-pstop.c -- 2.34.1

1 year, 1 month

[PATCH] coresight: etm4x: Fix width of CCITMIN field

by James Clark

CCITMIN is a 12 bit field and doesn't fit in a u8, so extend it to u16. This probably wasn't an issue previously because values higher than 255 never occurred. But since commit 0f55b43dedcd ("coresight: etm: Override TRCIDR3.CCITMIN on errata affected cpus"), a comparison with 256 was done to enable the errata, generating the following W=1 build error: coresight-etm4x-core.c:1188:24: error: result of comparison of constant 256 with expression of type 'u8' (aka 'unsigned char') is always false [-Werror,-Wtautological-constant-out-of-range-compare] if (drvdata->ccitmin == 256) Cc: stable(a)vger.kernel.org Fixes: 54ff892b76c6 ("coresight: etm4x: splitting struct etmv4_drvdata") Signed-off-by: James Clark <james.clark(a)arm.com> --- drivers/hwtracing/coresight/coresight-etm4x.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h index 20e2e4cb7614..da17b6c49b0f 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x.h +++ b/drivers/hwtracing/coresight/coresight-etm4x.h @@ -1036,7 +1036,7 @@ struct etmv4_drvdata { u8 ctxid_size; u8 vmid_size; u8 ccsize; - u8 ccitmin; + u16 ccitmin; u8 s_ex_level; u8 ns_ex_level; u8 q_support; -- 2.34.1

1 year, 1 month

[PATCH v2 0/8] Add support to configure TPDM CMB subunit

by Tao Zhang

Introduction of TPDM CMB(Continuous Multi Bit) subunit CMB subunit is responsible for creating a dataset element, and is also optionally responsible for packing it to fit multiple elements on a single ATB transfer if possible in the configuration. The TPDM Core Datapath requests timestamps be stored by the TPDA and then delivering ATB sized data (depending on ATB width and element size, this could be smaller or larger than a dataset element) to the ATB Mast FSM. The CMB makes trace elements in two modes. In �continuous� mode, every valid data cycle creates an element. In �trace on change� mode, when valid data changes on the bus, a trace element is created. In continuous mode, all cycles where this condition is true create trace elements. In trace on change mode, a data element is only when the previously sampled input is different from the current sampled input. The CMB subunit must be configured prior to enablement. This series adds support for TPDM to configure the configure CMB subunit. Once this series patches are applied properly, the new tpdm nodes for should be observed at the tpdm path /sys/bus/coresight/devices/tpdm* which supports CMB subunit. e.g. root@qemuarm64:/sys/devices/platform/soc@0/684c000.tpdm/tpdm0# ls -l -rw-r--r-- 1 root root 4096 Jan 1 00:00 cmb_mode drwxr-xr-x 2 root root 0 Jan 1 00:00 cmb_msr drwxr-xr-x 2 root root 0 Jan 1 00:00 cmb_patt drwxr-xr-x 2 root root 0 Jan 1 00:00 cmb_trig_patt -rw-r--r-- 1 root root 4096 Jan 1 00:00 cmb_trig_ts -rw-r--r-- 1 root root 4096 Jan 1 00:00 cmb_ts_all drwxr-xr-x 2 root root 0 Jan 1 00:00 connections drwxr-xr-x 2 root root 0 Jan 1 00:00 dsb_edge drwxr-xr-x 2 root root 0 Jan 1 00:00 dsb_msr drwxr-xr-x 2 root root 0 Jan 1 00:00 dsb_patt drwxr-xr-x 2 root root 0 Jan 1 00:00 dsb_trig_patt -rw-r--r-- 1 root root 4096 Jan 1 00:00 enable_source --w------- 1 root root 4096 Jan 1 00:00 integration_test drwxr-xr-x 2 root root 0 Ja? 1 00:00 power --w------- 1 root root 4096 Jan 1 00:00 reset_dataset lrwxrwxrwx 1 root root 0 Apr 5 2021 subsystem -> ../../../../../bus/coresight -rw-r--r-- 1 root root 4096 Apr 5 2021 uevent -r--r--r-- 1 root root 4096 Jan 1 00:00 waiting_for_supplier We can use the commands are similar to the below to configure the TPDMs which support CMB subunit. Enable coresight sink first. echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink echo 1 > /sys/bus/coresight/devices/tpdm0/reset_dataset echo 1 > /sys/bus/coresight/devices/tpdm0/cmb_mode echo 1 > /sys/bus/coresight/devices/tpdm0/cmb_patt/enable_ts echo 0xFFFFFFFF > /sys/bus/coresight/devices/tpdm0/cmb_patt/tpmr0 echo 0 > /sys/bus/coresight/devices/tpdm0/cmb_trig_ts echo 0xFFFFFFFF > /sys/bus/coresight/devices/tpdm0/cmb_trig_patt/xpr1 echo 1 > /sys/bus/coresight/devices/tpdm0/enable_source This patch series depends on patch "[v1] coresight-tpdm: Correct the property name of MSR number" https://patchwork.kernel.org/project/linux-arm-kernel/patch/1698128353-3115… codelinaro link: https://git.codelinaro.org/clo/linux-kernel/coresight/-/commits/tpdm-cmb-v2 Changes in V2: 1. Optimizate and modify this patch series based on the patch series "Add support to configure TPDM CMB subunit". 2. Modify the functions that read the element size of DSB/CMB in TPDA driver. Tao Zhang (8): dt-bindings: arm: Add support for CMB element size coresight-tpda: Add support to configure CMB element coresight-tpdm: Add CMB dataset support coresight-tpdm: Add support to configure CMB coresight-tpdm: Add pattern registers support for CMB coresight-tpdm: Add timestamp control register support for the CMB dt-bindings: arm: Add support for TPDM CMB MSR register coresight-tpdm: Add msr register support for CMB .../ABI/testing/sysfs-bus-coresight-devices-tpdm | 83 +++++ .../bindings/arm/qcom,coresight-tpdm.yaml | 37 ++ drivers/hwtracing/coresight/coresight-tpda.c | 108 +++--- drivers/hwtracing/coresight/coresight-tpda.h | 6 + drivers/hwtracing/coresight/coresight-tpdm.c | 390 ++++++++++++++++++++- drivers/hwtracing/coresight/coresight-tpdm.h | 87 +++++ 6 files changed, 663 insertions(+), 48 deletions(-) -- 2.7.4

1 year, 1 month

[PATCH v1] coresight-tpdm: Correct the property name of MSR number

by Tao Zhang

Correct the property name of the DSB MSR number that needs to be read in TPDM driver. The right property name is "qcom,dsb-msrs-num". Fixes： 90a7371cb08d ("coresight-tpdm: Add nodes for dsb msr support") Signed-off-by: Tao Zhang <quic_taozha(a)quicinc.com> --- drivers/hwtracing/coresight/coresight-tpdm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/hwtracing/coresight/coresight-tpdm.c index b25284e..97654aa 100644 --- a/drivers/hwtracing/coresight/coresight-tpdm.c +++ b/drivers/hwtracing/coresight/coresight-tpdm.c @@ -892,7 +892,7 @@ static int tpdm_probe(struct amba_device *adev, const struct amba_id *id) if (drvdata && tpdm_has_dsb_dataset(drvdata)) of_property_read_u32(drvdata->dev->of_node, - "qcom,dsb_msr_num", &drvdata->dsb_msr_num); + "qcom,dsb-msrs-num", &drvdata->dsb_msr_num); /* Set up coresight component description */ desc.name = coresight_alloc_device_name(&tpdm_devs, dev); -- 2.7.4

1 year, 1 month

Re: [RESEND] [GIT PULL] coresight: Update for v6.7

by Suzuki K Poulose

On 30/10/2023 12:44, Greg KH wrote: > On Mon, Oct 30, 2023 at 12:04:55PM +0000, Suzuki K Poulose wrote: >> Hi Greg >> >> On 30/10/2023 11:32, Greg KH wrote: >>> On Mon, Oct 30, 2023 at 11:02:04AM +0000, Suzuki K Poulose wrote: >>>> Hi Greg >>>> >>>> Please find the updates for Linux v6.7. Kindly pull. >>> >>> It's too late, sorry. Last week might have been too late too, why the >>> last-minute pull request? >> >> Apologies, I was out sick last week. I was hoping that there would be >> an rc8. The tree wasn't changed since last two weeks. I will try to >> send the pull request at rc5-rc6 now onwards. > > Thank you. > >>> Please send new changes after -rc1 is out for bugfixes and for normal >>> new features. >> >> Just to make sure I understand this correctly, >> - I can send a pull request with handpicked fixes for rc1 > > Yes, after -rc1 is out. > >> - What about the other new features ? Ok > > They need to wait until 6.8-rc1, you can send me a pull request for them > after -rc1 is out as well, for my -next branch. Ok. > >> (I can summaries the features below) >> - TRBE ACPI support ( Parts of this feature went into v6.6 via >> Will's perf subsystem, the coresight part was dropped due to >> a conflict. I queued it for v6.7 - 2patches) >> - CoreSight TPDM support for DSB feature (~10patches) >> - Support for configuring cycle count threshold for ETM (3 patches) >> Do they need to wait for v6.8 or could some of them go in for v6.7 ? >> >> >>> >>>> Please note the changes were queued and rebased onto v6.6-rc6 (which added >>>> some of the fixes in the cycle). >>> >>> Why rebase? What required that? >> >> This was to be on the safer side. I don't think there was any conflict. > > As Linus constantly says, NEVER rebase unless you have to. That just > makes history messy, and makes me think that something actually changed. > Merge conflicts are fine, we can handle them trivially, do not rewrite > history just for that. Noted. Thanks Suzuki > > thanks, > > greg k-h

1 year, 1 month

Re: [RESEND] [GIT PULL] coresight: Update for v6.7

by Suzuki K Poulose

Hi Greg On 30/10/2023 11:32, Greg KH wrote: > On Mon, Oct 30, 2023 at 11:02:04AM +0000, Suzuki K Poulose wrote: >> Hi Greg >> >> Please find the updates for Linux v6.7. Kindly pull. > > It's too late, sorry. Last week might have been too late too, why the > last-minute pull request? Apologies, I was out sick last week. I was hoping that there would be an rc8. The tree wasn't changed since last two weeks. I will try to send the pull request at rc5-rc6 now onwards. > > Please send new changes after -rc1 is out for bugfixes and for normal > new features. Just to make sure I understand this correctly, - I can send a pull request with handpicked fixes for rc1 - What about the other new features ? (I can summaries the features below) - TRBE ACPI support ( Parts of this feature went into v6.6 via Will's perf subsystem, the coresight part was dropped due to a conflict. I queued it for v6.7 - 2patches) - CoreSight TPDM support for DSB feature (~10patches) - Support for configuring cycle count threshold for ETM (3 patches) Do they need to wait for v6.8 or could some of them go in for v6.7 ? > >> Please note the changes were queued and rebased onto v6.6-rc6 (which added >> some of the fixes in the cycle). > > Why rebase? What required that? This was to be on the safer side. I don't think there was any conflict. Suzuki > > thanks, > > greg k-h

1 year, 1 month

[GIT PULL] coresight: Update for v6.7

by Suzuki K Poulose

Hi Greg Please find the updates for Linux v6.7. Kindly pull. Please note the changes were queued and rebased onto v6.6-rc6 (which added some of the fixes in the cycle). Suzuki The following changes since commit 58720809f52779dc0f08e53e54b014209d13eebb: Linux 6.6-rc6 (2023-10-15 13:34:39 -0700) are available in the Git repository at: git//git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git tags/coresight-next-v6.7 for you to fetch changes up to fa55e63584f2c3c84e0c3acdace42544e1832cc2: Documentation: coresight: fix `make refcheckdocs` warning (2023-10-25 11:21:29 +0100) ---------------------------------------------------------------- coresight: Updates for Linux v6.7 Updates for the hwtracing subsystem includes : - Support for CoreSight TPDM DSB set - Support for tuning Cycle count Threshold for CoreSight ETM via perf - Support for TRBE on ACPI based systems - Several fixes for the HiSilcon PTT tracing driver - Fix crash with CoreSight ETM mixing perf and sysfs mode - Remove Leo Yan from Reviewers Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> ---------------------------------------------------------------- Anshuman Khandual (6): coresight: trbe: Add a representative coresight_platform_data for TRBE coresight: trbe: Enable ACPI based TRBE devices coresight: etm: Override TRCIDR3.CCITMIN on errata affected cpus coresight: etm: Make cycle count threshold user configurable Documentation: coresight: Add cc_threshold tunable coresight: tmc: Make etr buffer mode user configurable from sysfs Bagas Sanjaya (1): Documentation: ABI: coresight-tpdm: Fix Bit[3] description indentation James Clark (1): coresight: Fix crash when Perf and sysfs modes are used concurrently Junhao He (1): hwtracing: hisi_ptt: Add dummy callback pmu::read() Leo Yan (1): MAINTAINERS: Remove myself as a Arm CoreSight reviewer Tao Zhang (13): coresight-tpdm: Remove the unnecessary lock dt-bindings: arm: Add support for DSB element size coresight-tpdm: Introduce TPDM subtype to TPDM driver coresight-tpda: Add DSB dataset support coresight-tpdm: Initialize DSB subunit configuration coresight-tpdm: Add reset node to TPDM node coresight-tpdm: Add nodes to set trigger timestamp and type coresight-tpdm: Add node to set dsb programming mode coresight-tpdm: Add nodes for dsb edge control coresight-tpdm: Add nodes to configure pattern match output coresight-tpdm: Add nodes for timestamp request dt-bindings: arm: Add support for DSB MSR register coresight-tpdm: Add nodes for dsb msr support Uwe Kleine-K��nig (1): coresight: etm4x: Remove bogous __exit annotation for some functions Vegard Nossum (1): Documentation: coresight: fix `make refcheckdocs` warning Yicong Yang (4): hwtracing: hisi_ptt: Disable interrupt after trace end hwtracing: hisi_ptt: Handle the interrupt in hardirq context hwtracing: hisi_ptt: Optimize the trace data committing hwtracing: hisi_ptt: Don't try to attach a task .../ABI/testing/sysfs-bus-coresight-devices-tmc | 16 + .../ABI/testing/sysfs-bus-coresight-devices-tpdm | 159 +++++ Documentation/arch/arm64/silicon-errata.rst | 10 + .../bindings/arm/qcom,coresight-tpdm.yaml | 20 + Documentation/trace/coresight/coresight.rst | 6 +- MAINTAINERS | 1 - drivers/hwtracing/coresight/coresight-core.c | 3 + drivers/hwtracing/coresight/coresight-etm-perf.c | 6 +- drivers/hwtracing/coresight/coresight-etm4x-core.c | 52 +- drivers/hwtracing/coresight/coresight-tmc-core.c | 15 +- drivers/hwtracing/coresight/coresight-tmc-etr.c | 111 +++- drivers/hwtracing/coresight/coresight-tmc.h | 3 + drivers/hwtracing/coresight/coresight-tpda.c | 126 +++- drivers/hwtracing/coresight/coresight-tpda.h | 2 + drivers/hwtracing/coresight/coresight-tpdm.c | 718 ++++++++++++++++++++- drivers/hwtracing/coresight/coresight-tpdm.h | 161 +++++ drivers/hwtracing/coresight/coresight-trbe.c | 23 +- drivers/hwtracing/coresight/coresight-trbe.h | 2 + drivers/hwtracing/ptt/hisi_ptt.c | 33 +- drivers/hwtracing/ptt/hisi_ptt.h | 1 + include/linux/coresight.h | 1 + 21 files changed, 1411 insertions(+), 58 deletions(-)

1 year, 1 month

[PATCH] perf tests: test_arm_coresight: Simplify source iteration

by James Clark

There are two reasons to do this, firstly there is a shellcheck warning in cs_etm_dev_name(), which can be completely deleted. And secondly the current iteration method doesn't support systems with both ETE and ETM because it picks one or the other. There isn't a known system with this configuration, but it could happen in the future. Iterating over all the sources for each CPU can be done by going through /sys/bus/event_source/devices/cs_etm/cpu* and following the symlink back to the Coresight device in /sys/bus/coresight/devices. This will work whether the device is ETE, ETM or any future name, and is much simpler and doesn't require any hard coded version numbers Suggested-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Signed-off-by: James Clark <james.clark(a)arm.com> --- This was discussed here previously: https://lore.kernel.org/all/20230929041133.95355-2-atrajeev@linux.vnet.ibm.… I chose not to add a fixes tag like the original because shellcheck isn't part of the build so it doesn't really fix any real issue yet and is just a refactor. tools/perf/tests/shell/test_arm_coresight.sh | 17 +++-------------- 1 file changed, 3 insertions(+), 14 deletions(-) diff --git a/tools/perf/tests/shell/test_arm_coresight.sh b/tools/perf/tests/shell/test_arm_coresight.sh index fe78c4626e45..65dd85207125 100755 --- a/tools/perf/tests/shell/test_arm_coresight.sh +++ b/tools/perf/tests/shell/test_arm_coresight.sh @@ -11,19 +11,6 @@ glb_err=0 -cs_etm_dev_name() { - cs_etm_path=$(find /sys/bus/event_source/devices/cs_etm/ -name cpu* -print -quit) - trcdevarch=$(cat ${cs_etm_path}/mgmt/trcdevarch) - archhver=$((($trcdevarch >> 12) & 0xf)) - archpart=$(($trcdevarch & 0xfff)) - - if [ $archhver -eq 5 -a "$(printf "0x%X\n" $archpart)" = "0xA13" ] ; then - echo "ete" - else - echo "etm" - fi -} - skip_if_no_cs_etm_event() { perf list | grep -q 'cs_etm//' && return 0 @@ -149,7 +136,9 @@ arm_cs_iterate_devices() { arm_cs_etm_traverse_path_test() { # Iterate for every ETM device - for dev in /sys/bus/coresight/devices/$(cs_etm_dev_name)*; do + for dev in /sys/bus/event_source/devices/cs_etm/cpu*; do + # Canonicalize the path + dev=`readlink -f $dev` # Find the ETM device belonging to which CPU cpu=`cat $dev/cpu` -- 2.34.1

1 year, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight October 2023