CoreSight March 2024

coresight@lists.linaro.org

8 participants
13 discussions

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

by Linu Cherian

This patch series is rebased on v6.8-rc4 from coresisght tree,[1], since latest changes are dependent on coresight_get/set_mode APIs. 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. v6 is posted here: https://www.spinics.net/lists/kernel/msg5055812.html 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 Future Improvements ------------------- * Explore changing CTI sysfs script to system configuration manager profile * Explore Perf based trace capture and decode Links: 1. https://kernel.googlesource.com/pub/scm/linux/kernel/git/coresight/linux.gi… 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 | 248 +++++++++++++- .../hwtracing/coresight/coresight-tmc-etf.c | 161 ++++++++- .../hwtracing/coresight/coresight-tmc-etr.c | 322 +++++++++++++++++- drivers/hwtracing/coresight/coresight-tmc.h | 83 +++++ include/linux/coresight.h | 25 ++ 12 files changed, 972 insertions(+), 20 deletions(-) create mode 100644 drivers/hwtracing/coresight/coresight-cfg-pstop.c -- 2.34.1

2 days

[PATCH V7 00/11] 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. This series has been built, and boot tested on a DT based (RB5) and ACPI supported coresight platform (N1SDP). https://git.gitlab.arm.com/linux-arm/linux-anshuman.git (amba_other_acpi_migration_v7) 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 V7: - Dropped reduntant 'drvdata' check in following functions replicator_platform_remove() funnel_platform_remove() tpiu_platform_remove() tmc_platform_remove() catu_platform_remove() catu_platform_probe() debug_platform_remove() debug_platform_probe() - Dropped struct resource check before devm_ioremap_resource() - Sorted the headers in alphabetic order Changes in V6: https://lore.kernel.org/all/20240312102318.2285165-1-anshuman.khandual@arm.… - Dropped Jame's RB tag from [PATCH 3/11] - Added clk_disable_unprepare() for pclk in replicator_probe() error path - Added clk_disable_unprepare() for pclk in funnel_probe() error path - Added clk_put() for pclk in catu_platform_probe() error path - Added clk_put() for pclk in debug_platform_probe() error path - Added WARN_ON(!drvdata) check in replicator_platform_remove() - Added WARN_ON(!drvdata) check in funnel_platform_remove() - Added WARN_ON(!drvdata) check in catu_platform_remove() - Added WARN_ON(!drvdata) check in tpiu_platform_remove() - Added WARN_ON(!drvdata) check in tmc_platform_remove() - Added WARN_ON(!drvdata) check in stm_platform_remove() - Added WARN_ON(!drvdata) check in debug_platform_remove() - Added additional elements for all acpi_device_id[] updates Changes in V5: https://lore.kernel.org/all/20240222082142.3663983-1-anshuman.khandual@arm.… - Used table->mask to filter out bits from pid in coresight_get_uci_data_from_amba() - Dropped custom masks such as STM_AMBA_MASK and TMC_AMBA_MASK - Modified tmc_etr_setup_caps() to accept struct csdev_access argument - Reverted back tmc_etr_setup_caps() call site position in tmc_probe() - Changed replicator and funnel devices to use the new helpers earlier in series - Updated the commit messages regarding xxx_probe() refactoring and renaming Changes in V4: https://lore.kernel.org/all/20240123054608.1790189-1-anshuman.khandual@arm.… - Fixed PM imbalance in etm4_probe() error path with pm_runtime_disable() - Restored back the pm_runtime_disable() on platform probe error paths in replicator, funnel, catu, tpiu, tmc and stm devices - Dropped dev_caps argument from __tmc_probe() - Changed xxxx_platform_remove() for platform_driver->remove_new() callback Changes in V3: https://lore.kernel.org/all/20231208053939.42901-1-anshuman.khandual@arm.co… - Split coresight_init_driver/remove_driver() helpers into a separate patch - Added 'drvdata->pclk' comments in replicator, funnel, tpiu, tmc, and stm devices - Updated funnel, and replicator drivers to use these new helpers - Check for drvdata instead of drvdata->pclk in suspend and resume paths in catu, tmc and debug devices - Added patch to extract device name from AMBA pid based table lookup for stm - Added patch to extract device properties from AMBA pid based table look for tmc - Dropped pm_runtime_put() from common __probe() functions - Handled pm_runtime_put() in AMBA driver in success path - Handled pm_runtime_put() in platform driver in both success and error paths Changes in V2: https://lore.kernel.org/all/20231201062053.1268492-1-anshuman.khandual@arm.… - Dropped redundant devm_ioremap_resource() hunk from tmc_platform_probe() - Defined coresight_[init|remove]_driver() for both AMBA/platform drivers - Changed catu, tmc, tpiu, stm and debug coresight drivers to use the new helpers avoiding build issues arising from module_amba_driver(), and module_platform_driver() being on the same file Changes in V1: https://lore.kernel.org/all/20231027072943.3418997-1-anshuman.khandual@arm.… - 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 (11): coresight: etm4x: Fix unbalanced pm_runtime_enable() coresight: stm: Extract device name from AMBA pid based table lookup coresight: tmc: Extract device properties from AMBA pid based table lookup coresight: Add helpers registering/removing both AMBA and platform drivers 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 | 138 +++++++++++++--- drivers/hwtracing/coresight/coresight-catu.h | 1 + drivers/hwtracing/coresight/coresight-core.c | 29 ++++ .../hwtracing/coresight/coresight-cpu-debug.c | 138 ++++++++++++++-- .../coresight/coresight-etm4x-core.c | 3 + .../hwtracing/coresight/coresight-funnel.c | 87 +++++----- drivers/hwtracing/coresight/coresight-priv.h | 10 ++ .../coresight/coresight-replicator.c | 82 +++++----- drivers/hwtracing/coresight/coresight-stm.c | 116 +++++++++++-- .../hwtracing/coresight/coresight-tmc-core.c | 154 +++++++++++++++--- drivers/hwtracing/coresight/coresight-tmc.h | 2 + drivers/hwtracing/coresight/coresight-tpiu.c | 117 +++++++++++-- include/linux/coresight.h | 7 + 14 files changed, 726 insertions(+), 166 deletions(-) -- 2.25.1

5 days

[PATCH 0/4] Add support for multi-port output on the funnel

by Tao Zhang

Funnel can support multi-port output in our hardware design. Since original funnels only support a single output connection, the code needs to be modified to support this new feature. The following is a typical topology diagram of multi-port output of the funnels. |---------| |---------| |---------| |---------| |---------| | TPDM0 | | TPDM1 | | TPDM2 | | TPDM3 | | TPDM4 | |---------| |---------| |---------| |---------| |---------| | | | | | | | | | | | | | | | |-----| |-----| |-----| |-----| | | | | | | | | | | | [0]| |[1] [0]| |[1] | \-------------/ \-------------/ \-------------/ \ FUNNEL0 / \ FUNNEL1 / \ FUNNEL2 / ----------- ----------- ----------- [0]| |[1] [0]| |[1] | | |---------- | | | | | | | | |-------| | |------- | | |--------- | | | | | | | | | | | [0]| |[1] |[2] |[3] |[4] \ ---------------------------------------------------/ \ TPDA0 / \ / ------------------------------------------------ For example, TPDM0 and TPDM1 are connected to the [0] and [1] input ports of the funnel respectively, and output from the [0] and [1] output ports. In this way, when data is output from the Funnel's output port, it needs to know the source component corresponding to this output port. Our solution is to add a property named "label" in the devicetree to mark the source corresponding to the output port. After introducing this new feature, another new problem also needs to be solved. For example, TPDA driver will search for all the TPDMs on a input port. In the topology diagram above, when TPDA searches for TPDM from the input port[0], it will find TPDM0 and TPDM1. Our solution is to add a new property named "qcom,tpda-input-port" to mark the input port number of the TPDA in the devicetree. Tao Zhang (4): dt-bindings: arm: qcom,coresight-funnel: Add label for multi-ouput coresight: Add support for multiple output ports on the funnel dt-bindings: arm: qcom,coresight-tpdm: Mark tpda input port number coresight-tpda: Add support multi-port input on TPDA .../arm/arm,coresight-dynamic-funnel.yaml | 34 +++++++- .../bindings/arm/qcom,coresight-tpdm.yaml | 8 ++ drivers/hwtracing/coresight/coresight-core.c | 81 ++++++++++++++++--- .../hwtracing/coresight/coresight-platform.c | 5 ++ drivers/hwtracing/coresight/coresight-tpda.c | 27 ++++++- include/linux/coresight.h | 2 + 6 files changed, 139 insertions(+), 18 deletions(-) -- 2.17.1

1 week, 1 day

[PATCH] perf test: Increase buffer size for Coresight basic tests

by James Clark

These tests record in a mode that includes kernel trace but look for samples of a userspace process. This makes them sensitive to any kernel compilation options that increase the amount of time spent in the kernel. If the trace buffer is completely filled before userspace is reached then the test will fail. Double the buffer size to fix this. The other tests in the same file aren't sensitive to this for various reasons, for example the iterate devices test filters by userspace trace only. But in order to keep coverage of all the modes, increase the buffer size rather than filtering by userspace for the basic tests. Fixes: d1efa4a0a696 ("perf cs-etm: Add separate decode paths for timeless and per-thread modes") Signed-off-by: James Clark <james.clark(a)arm.com> --- tools/perf/tests/shell/test_arm_coresight.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/tests/shell/test_arm_coresight.sh b/tools/perf/tests/shell/test_arm_coresight.sh index 65dd85207125..3302ea0b9672 100755 --- a/tools/perf/tests/shell/test_arm_coresight.sh +++ b/tools/perf/tests/shell/test_arm_coresight.sh @@ -188,7 +188,7 @@ arm_cs_etm_snapshot_test() { arm_cs_etm_basic_test() { echo "Recording trace with '$*'" - perf record -o ${perfdata} "$@" -- ls > /dev/null 2>&1 + perf record -o ${perfdata} "$@" -m,8M -- ls > /dev/null 2>&1 perf_script_branch_samples ls && perf_report_branch_samples ls && -- 2.34.1

1 week, 2 days

Lockdep splat in TMC ETR

by Denis Nikitin

Hello CoreSight friends, There is a bug recently reported on ChromeOS (with the linux kernel 6.6), https://issuetracker.google.com/329285580. Lockdep detected a deadlock in TMC ETR in a debug kernel build. [12453.456471] WARNING: possible circular locking dependency detected [12453.456518] 6.6.21-lockdep-01250-gbecf1787b73c #1 Not tainted [12453.456575] ------------------------------------------------------ [12453.456618] perf/12414 is trying to acquire lock: [12453.456671] ffffffc084bc0990 (&dma_entry_hash[i].lock){-.-.}-{2:2}, at: check_sync+0x84/0x11a0 [12453.456896] but task is already holding lock: [12453.456938] ffffff80cdb940f8 (&drvdata->spinlock){....}-{2:2}, at: tmc_update_etr_buffer+0xbc/0x898 [coresight_tmc] [12453.457332] which lock already depends on the new lock. Could you please take a look? Thanks, Denis Nikitin

2 weeks, 1 day

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

by Suzuki K Poulose

On 27/03/2024 05:57, Krzysztof Kozlowski wrote: > On 27/03/2024 00:24, Suzuki K Poulose wrote: >> Hi Krzysztof >> >> On 26/03/2024 20:23, Krzysztof Kozlowski wrote: >>> Merging >>> ======= >>> All further patches depend on the first amba patch, therefore please ack >>> and this should go via one tree. >> >> Are you able to provide a stable branch with these patches once you pull > > I doubt I will be merging this. I think amba code goes through Russell. > >> them in to "one tree" here ? We have changes coming up in the coresight >> tree, which would conflict with the changes here (horribly). >> > > You mean conflict with coresight conversion to platform driver? Worst Yes. > case it is solveable: just drop .owner. Or, we could merge the CoreSight changes (as they are really not affected by the problem this series is trying to address) after the base changes land in AMBA, via the CoreSight tree. Suzuki > > Best regards, > Krzysztof >

1 month

Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()

by Suzuki K Poulose

Hi Krzysztof On 26/03/2024 20:23, Krzysztof Kozlowski wrote: > Merging > ======= > All further patches depend on the first amba patch, therefore please ack > and this should go via one tree. Are you able to provide a stable branch with these patches once you pull them in to "one tree" here ? We have changes coming up in the coresight tree, which would conflict with the changes here (horribly). FWIW, For patches 1 to 13 : Acked-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Suzuki

1 month

Re: [PATCH RESEND 1/2] dt-bindings: arm: qcom,coresight-tpda: drop redundant type from ports

by Suzuki K Poulose

Hi Krzysztof On 25/03/2024 10:40, Krzysztof Kozlowski wrote: > "in-ports" and "out-ports" are defined by graph schema, so defining its > type is redundant. > > Acked-by: Rob Herring <robh(a)kernel.org> > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Both patches look good to me. How would you like to pull this ? I could queue them for v6.10 via coresight tree. If you would like to take them, Acked-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Suzuki > > --- > > No changes, but patches were split from previous set. First patch in > previouis series was being discussed, so let's just make these accepted. > > v1: https://lore.kernel.org/all/20231206115332.22712-1-krzysztof.kozlowski@lina… > --- > Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml > index ea3c5db6b52d..7fbd855a66a0 100644 > --- a/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml > +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml > @@ -66,13 +66,11 @@ properties: > - const: apb_pclk > > in-ports: > - type: object > description: | > Input connections from TPDM to TPDA > $ref: /schemas/graph.yaml#/properties/ports > > out-ports: > - type: object > description: | > Output connections from the TPDA to legacy CoreSight trace bus. > $ref: /schemas/graph.yaml#/properties/ports

1 month

Re: [PATCH 1/4] dt-bindings: arm: qcom,coresight-funnel: Add label for multi-ouput

by Tingwei Zhang

On 3/21/2024 10:42 PM, Rob Herring wrote: > On Thu, Mar 21, 2024 at 04:32:04PM +0800, Tao Zhang wrote: >> Add new property "label" to label the source corresponding to the >> output connection. When the funnel supports multi-output, this >> property needs to be introduced to mark which source component a >> certain output connection corresponds to. >> >> Signed-off-by: Tao Zhang <quic_taozha(a)quicinc.com> >> --- >> .../arm/arm,coresight-dynamic-funnel.yaml | 34 ++++++++++++++++--- >> 1 file changed, 30 insertions(+), 4 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml >> index 44a1041cb0fc..cde62c286d29 100644 >> --- a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml >> +++ b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml >> @@ -66,13 +66,39 @@ properties: >> $ref: /schemas/graph.yaml#/properties/port >> >> out-ports: >> - $ref: /schemas/graph.yaml#/properties/ports >> - additionalProperties: false >> - >> + type: object >> properties: >> + "#address-cells": >> + const: 1 >> + >> + "#size-cells": >> + const: 0 >> + >> port: >> + type: object >> + >> + patternProperties: >> + '^port(@[0-7])?$': >> + type: object >> description: Output connection to CoreSight Trace bus >> - $ref: /schemas/graph.yaml#/properties/port > > Nope, now you have no constraints on port node properties. Please look > at how other bindings are done to add properties on endpoint node. > Thanks for pointing this out, Rob. Shall we ref port-base and endpoint-base then add new properties on endpoint? In this way, the redundant code from port schema is not required. >> + >> + patternProperties: >> + "^endpoint(@[0-9a-f]+)?$": >> + type: object >> + properties: >> + remote-endpoint: >> + description: | >> + phandle to an 'endpoint' subnode of a remote device node. >> + $ref: /schemas/types.yaml#/definitions/phandle > > Don't need this. > >> + label: >> + description: Label the source corresponding to the output connection >> + $ref: /schemas/types.yaml#/definitions/string > > label already has a type. > > As this node is an output, aren't you labeling what the destination is, > not the "source"? > > Why can't you look at the remote connection to identify what it is? > This funnel can route data stream from different trace source to different output ports. This lable property is added to describe which source is routed to this output port. For example, the graph is as below. Funnel3 routes trace data from TPDM0 to output[0] and output[0] of funnel3 is connected to input[0] of TPDA0. While Funnels routes trace data from TPDM1 to output[1] which connects to input[1] of TPDA0. Hope that clarifies this a little bit. |---------| |---------| |---------| |---------| |---------| | TPDM0 | | TPDM1 | | TPDM2 | | TPDM3 | | TPDM4 | |---------| |---------| |---------| |---------| |---------| | | | | | | | | | | | | | | | |-----| |-----| |-----| |-----| | | | | | | | | | | | [0]| |[1] [0]| |[1] | \-------------/ \-------------/ \------------/ \ FUNNEL0 / \ FUNNEL1 / \ FUNNEL2 / ----------- ----------- ----------- | | | \-------------/ \-------------/ | \ FUNNEL3 / \ FUNNEL4 / | ----------- ----------- | | | | | [0]| |[1] [0]| |[1] | | |---------- | | | | | | | | |-------| | |------- | | |--------- | | | | | | | | | | | [0]| |[1] |[2] |[3] |[4] \ ---------------------------------------------------/ \ TPDA0 / \ / ------------------------------------------------ > >> + oneOf: >> + - required: >> + - port >> + - required: >> + - "#address-cells" >> + - "#size-cells" > > The common schema that you removed handles this. > > Rob -- Thanks, Tingwei

1 month

Re: [PATCH 1/4] dt-bindings: arm: qcom,coresight-funnel: Add label for multi-ouput

by Suzuki K Poulose

On 21/03/2024 14:42, Rob Herring wrote: > On Thu, Mar 21, 2024 at 04:32:04PM +0800, Tao Zhang wrote: >> Add new property "label" to label the source corresponding to the >> output connection. When the funnel supports multi-output, this >> property needs to be introduced to mark which source component a >> certain output connection corresponds to. >> >> Signed-off-by: Tao Zhang <quic_taozha(a)quicinc.com> >> --- >> .../arm/arm,coresight-dynamic-funnel.yaml | 34 ++++++++++++++++--- >> 1 file changed, 30 insertions(+), 4 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml >> index 44a1041cb0fc..cde62c286d29 100644 >> --- a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml >> +++ b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml >> @@ -66,13 +66,39 @@ properties: >> $ref: /schemas/graph.yaml#/properties/port >> >> out-ports: >> - $ref: /schemas/graph.yaml#/properties/ports >> - additionalProperties: false >> - >> + type: object >> properties: >> + "#address-cells": >> + const: 1 >> + >> + "#size-cells": >> + const: 0 >> + >> port: >> + type: object >> + >> + patternProperties: >> + '^port(@[0-7])?$': >> + type: object >> description: Output connection to CoreSight Trace bus >> - $ref: /schemas/graph.yaml#/properties/port > > Nope, now you have no constraints on port node properties. Please look > at how other bindings are done to add properties on endpoint node. > >> + >> + patternProperties: >> + "^endpoint(@[0-9a-f]+)?$": >> + type: object >> + properties: >> + remote-endpoint: >> + description: | >> + phandle to an 'endpoint' subnode of a remote device node. >> + $ref: /schemas/types.yaml#/definitions/phandle > > Don't need this. > >> + label: >> + description: Label the source corresponding to the output connection >> + $ref: /schemas/types.yaml#/definitions/string > > label already has a type. > > As this node is an output, aren't you labeling what the destination is, > not the "source"? > > Why can't you look at the remote connection to identify what it is? +1 Suzuki > > >> + oneOf: >> + - required: >> + - port >> + - required: >> + - "#address-cells" >> + - "#size-cells" > > The common schema that you removed handles this. > > Rob

1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight March 2024