CoreSight

coresight@lists.linaro.org

6 participants
2389 discussions

Re: [PATCH v2 2/4] dt-bindings: arm: Add binding document for Coresight Control Unit device.

by Suzuki K Poulose

On 11/07/2024 09:36, JieGan wrote: > On Tue, Jul 09, 2024 at 02:00:25PM +0800, JieGan wrote: >> On Mon, Jul 08, 2024 at 01:50:11PM +0100, Suzuki K Poulose wrote: >>> On 08/07/2024 11:25, JieGan wrote: >>>> On Mon, Jul 08, 2024 at 06:10:28PM +0800, JieGan wrote: >>>>> On Mon, Jul 08, 2024 at 10:41:55AM +0100, Suzuki K Poulose wrote: >>>>>> On 05/07/2024 10:00, Jie Gan wrote: >>>>>>> Add binding document for Coresight Control Unit device. >>>>>> >>>>>> nit: This is again too generic ? corsight-tmc-control-unit ? After all >>>>>> thats what it is and not a *generic* coresight control unit ? >>>>>> >>>>> coresight-tmc-control-unit is much better. We will check it. >>>>>>> >>>>>>> Signed-off-by: Jie Gan <quic_jiegan(a)quicinc.com> >>>>>>> --- >>>>>>> .../bindings/arm/qcom,coresight-ccu.yaml | 87 +++++++++++++++++++ >>>>>>> 1 file changed, 87 insertions(+) >>>>>>> create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-ccu.yaml >>>>>>> >>>>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-ccu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-ccu.yaml >>>>>>> new file mode 100644 >>>>>>> index 000000000000..9bb8ced393a7 >>>>>>> --- /dev/null >>>>>>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-ccu.yaml >>>>>>> @@ -0,0 +1,87 @@ >>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>>>>> +%YAML 1.2 >>>>>>> +--- >>>>>>> +$id: http://devicetree.org/schemas/arm/qcom,coresight-ccu.yaml# >>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>>>>> + >>>>>>> +title: CoreSight Control Unit >>>>>>> + >>>>>>> +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 Control unit controls various Coresight behaviors. >>>>>>> + Used to enable/disable ETR’s data filter function based on trace ID. >>>>>>> + >>>>>>> +properties: >>>>>>> + compatible: >>>>>>> + const: qcom,coresight-ccu >>>>>>> + >>>>>>> + reg: >>>>>>> + maxItems: 1 >>>>>>> + >>>>>>> + clocks: >>>>>>> + maxItems: 1 >>>>>>> + >>>>>>> + clock-names: >>>>>>> + items: >>>>>>> + - const: apb_pclk >>>>>>> + >>>>>>> + reg-names: >>>>>>> + items: >>>>>>> + - const: ccu-base >>>>>>> + >>>>>>> + in-ports: >>>>>>> + $ref: /schemas/graph.yaml#/properties/ports >>>>>>> + >>>>>>> + unevaluatedProperties: >>>>>>> + patternProperties: >>>>>>> + '^port(@[0-7])?$': >>>>>>> + description: Input connections from CoreSight Trace bus >>>>>>> + $ref: /schemas/graph.yaml#/properties/port >>>>>>> + >>>>>>> + properties: >>>>>>> + qcom,ccu-atid-offset: >>>>>> >>>>>> Why do we need this atid offset ? Couldn't this be mapped to the "port" >>>>>> number ? >>>>>> >>>>>> e.g, input-port 0 on CCU => Offset x >>>>>> input-port 1 on CCU => (Offset x + Size of 1 region) >>>>> If the first ATID offset remains constant, it appears to be feasible. >>>>> We will consider the possibility of this solution. >>>> We just checked the ATID offset varies across different hardware platforms. >>>> It defined as 0xf4 on some platforms, and some others defined as 0xf8. >>> >>> What do you mean ? The offset where you apply the filter changes across >>> different platforms ? or different "tmc-control-unit" implementations ? >>> Is this discoverable from the device ? We could use different >>> compatibles for different "types" of the "devices". Simply adding >>> something in the DT is not the right way. >> >> I got your point here. I believe we should consult our hardware engineers first to check it. >> We need to figure out the design of ATID offset from hardware perspective. Then we can >> propose an alternative approach, such as associating the offset with a compitable value, >> to resolve this issue. >> >>> >>>> >>>> So I think it should be better to define it in device tree node. >>> >>> No. See above. > > > Hi Suzuki > > There is a new solution for CCU device. We would like to separate one CCU device into several helper > devices, each responsible for one feature of the CCU device. > > For the data filter feature, we will define the address of the AITD Register that included by CCU in DT > as base address of the helper node. So the driver code can easily program the register field with the base address. > With this solution, we may need define several helper nodes in DT file to support different features for CCU and each > helper device needs a driver to support its behavior. > > for example, ATID register for ETR0 with base address 0x10000f8: (tmp name used, TDFU for tmc data filter unit) That looks like a hack to me and don't prefer that and there would be multiple mappings for a single device and that could complicate device resource accounting. > > TDFU@10000f8 { > ... > } > > ATID register for ETR1 with base address 0x1000108: > TDFU@1000108 { > ... > } > > The CCU device supports various features and the data filter feature for ETR is one of those features. How to support > those features with one helper_enable function is a serious challenge. That's why we would like to separate it. > Meanwhile, This solution can also resolve the offset issue. > > We are looking forward your opinions with this proposal. We need to know what other functionalities are supported and how that will be used ? In the worst case, you could define register bases for each port in the CCU device node. TDFU@.. { reg = <base-address 4K> <I don't know the standard property name for> = List of { <port number>, <Offset from base>, } } Suzuki

12 months

[PATCH v1 0/3] Add source filtering for multi-port output

by Tao Zhang

In our hardware design, by combining a funnel and a replicator, it implement a hardware device with one-to-one correspondence between output ports and input ports. The programming usage on this device is the same as funnel. The software uses a funnel and a static replicator to implement the driver of this device. Since original funnels only support a single output connection and original replicator only support a single input connection, the code needs to be modified to support this new feature. The following is a typical topology diagram of multi-port output mechanism. |----------| |---------| |----------| |---------| | TPDM 0 | | Source0 | | Source 1 | | TPDM 1 | |----------| |---------| |----------| |---------| | | | | | | | | | --------- | | | | | | | | | | | | | | | \-------------/ ---------------------- | \ Funnel 0 / | | ----------- | ------------------------------ | | | | | | \------------------/ \ Funnel 1 / ----| \--------------/ | | |----> Combine a funnel and a | | static replicator /-----------------\ | / replicator 0 \ ----| /---------------------\ | | | | | |-----------| | |---------| | | |TPDM0 |TPDM1 | \-----------------/ | \ TPDA 0 / | \-------------/ | | | | |Source0/1 | \-------------------------------/ \ Funnel 2 / \---------------------------/ Changes in V1: 1. Add a static replicator connect to a funnel to implement the correspondence between the output ports and the input ports on funnels. -- Suzuki K Poulose 2. Add filter_src_dev and filter_src_dev phandle to "coresight_connection" struct, and populate them if there is one. -- Suzuki K Poulose 3. To look at the phandle and then fixup/remove the filter_src device in fixup/remove connections. -- Suzuki K Poulose 4. When TPDA reads DSB/CMB element size, it is implemented by looking up filter src device in the connections. -- Suzuki K Poulose Tao Zhang (3): dt-bindings: arm: qcom,coresight-static-replicator: Add property for source filtering coresight: Add source filtering for multi-port output coresight-tpda: Optimize the function of reading element size .../arm/arm,coresight-static-replicator.yaml | 18 +++- drivers/hwtracing/coresight/coresight-core.c | 89 ++++++++++++++++--- .../hwtracing/coresight/coresight-platform.c | 13 +++ drivers/hwtracing/coresight/coresight-tpda.c | 6 +- include/linux/coresight.h | 5 ++ 5 files changed, 115 insertions(+), 16 deletions(-) -- 2.17.1

12 months

[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

12 months

Re: [PATCH v1 1/3] dt-bindings: arm: qcom,coresight-static-replicator: Add property for source filtering

by Suzuki K Poulose

minor nit: Subject: s/qcom,coresight-static-replicator/arm,coresight-static-replicator ? There is no "qcom,coresight-static-replicator" compatible. On 05/07/2024 10:02, Krzysztof Kozlowski wrote: > On 05/07/2024 10:51, Tao Zhang wrote: >> Add a new property "filter_src" to label the source corresponding >> to the output connection for a static replicator. By combining >> a funnel and a static replicator in devicetree, a new device that >> supports multi-port input and multi-port output is implemented. >> In order to match the output port with the input port and >> successfully build the trace path, add this new property to >> indicate the data source corresponding to this output port. >> >> Signed-off-by: Tao Zhang <quic_taozha(a)quicinc.com> >> --- >> .../arm/arm,coresight-static-replicator.yaml | 18 +++++++++++++++++- >> 1 file changed, 17 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml >> index 1892a091ac35..d9538563f9c6 100644 >> --- a/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml >> +++ b/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml >> @@ -45,7 +45,21 @@ properties: >> patternProperties: >> '^port@[01]$': >> description: Output connections to CoreSight Trace bus >> - $ref: /schemas/graph.yaml#/properties/port >> + $ref: /schemas/graph.yaml#/$defs/port-base >> + >> + properties: >> + endpoint: >> + $ref: /schemas/media/video-interfaces.yaml# > > Ehm? How is this video interface? > >> + >> + properties: >> + filter_src: > > There are no properties with underscores... > >> + $ref: /schemas/types.yaml#/definitions/phandle >> + description: >> + defines a phandle reference to an associated CoreSight trace device. >> + When the associated trace device is enabled, then the respective >> + trace path will be built and enabled. > > How does it differ from remote endpoint? What is "respective trace path"? Apparently, there is some "magic" hard coded filtering in the replicators, which only passes through trace from a particular "source" device. The documentation above doesn't explain this clearly. it could be: "phandle to the coresight trace source device matching the hard coded filtering for this port" This could be different from the "remote endpoint" as there could be intermediate components between the phandle "source" and the port. Suzuki > > <form letter> > Please use scripts/get_maintainers.pl to get a list of necessary people > and lists to CC (and consider --no-git-fallback argument). It might > happen, that command when run on an older kernel, gives you outdated > entries. Therefore please be sure you base your patches on recent Linux > kernel. > > Tools like b4 or scripts/get_maintainer.pl provide you proper list of > people, so fix your workflow. Tools might also fail if you work on some > ancient tree (don't, instead use mainline) or work on fork of kernel > (don't, instead use mainline). Just use b4 and everything should be > fine, although remember about `b4 prep --auto-to-cc` if you added new > patches to the patchset. > </form letter> > > > Best regards, > Krzysztof >

12 months

[PATCH 0/2] MAINTAINERS: mailmap: Update James Clark's email address

by James Clark

I moved to Linaro so update my email in a few places. James Clark (2): MAINTAINERS: mailmap: Update James Clark's email address dt-bindings: arm: Update James Clark's email address .mailmap | 1 + .../devicetree/bindings/arm/arm,coresight-dummy-sink.yaml | 2 +- .../devicetree/bindings/arm/arm,coresight-dummy-source.yaml | 2 +- MAINTAINERS | 4 ++-- 4 files changed, 5 insertions(+), 4 deletions(-) -- 2.34.1

12 months

Re: [PATCH v2 2/4] dt-bindings: arm: Add binding document for Coresight Control Unit device.

by Suzuki K Poulose

On 08/07/2024 11:25, JieGan wrote: > On Mon, Jul 08, 2024 at 06:10:28PM +0800, JieGan wrote: >> On Mon, Jul 08, 2024 at 10:41:55AM +0100, Suzuki K Poulose wrote: >>> On 05/07/2024 10:00, Jie Gan wrote: >>>> Add binding document for Coresight Control Unit device. >>> >>> nit: This is again too generic ? corsight-tmc-control-unit ? After all >>> thats what it is and not a *generic* coresight control unit ? >>> >> coresight-tmc-control-unit is much better. We will check it. >> >>>> >>>> Signed-off-by: Jie Gan <quic_jiegan(a)quicinc.com> >>>> --- >>>> .../bindings/arm/qcom,coresight-ccu.yaml | 87 +++++++++++++++++++ >>>> 1 file changed, 87 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-ccu.yaml >>>> >>>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-ccu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-ccu.yaml >>>> new file mode 100644 >>>> index 000000000000..9bb8ced393a7 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-ccu.yaml >>>> @@ -0,0 +1,87 @@ >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>> +%YAML 1.2 >>>> +--- >>>> +$id: http://devicetree.org/schemas/arm/qcom,coresight-ccu.yaml# >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>> + >>>> +title: CoreSight Control Unit >>>> + >>>> +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 Control unit controls various Coresight behaviors. >>>> + Used to enable/disable ETR’s data filter function based on trace ID. >>>> + >>>> +properties: >>>> + compatible: >>>> + const: qcom,coresight-ccu >>>> + >>>> + reg: >>>> + maxItems: 1 >>>> + >>>> + clocks: >>>> + maxItems: 1 >>>> + >>>> + clock-names: >>>> + items: >>>> + - const: apb_pclk >>>> + >>>> + reg-names: >>>> + items: >>>> + - const: ccu-base >>>> + >>>> + in-ports: >>>> + $ref: /schemas/graph.yaml#/properties/ports >>>> + >>>> + unevaluatedProperties: >>>> + patternProperties: >>>> + '^port(@[0-7])?$': >>>> + description: Input connections from CoreSight Trace bus >>>> + $ref: /schemas/graph.yaml#/properties/port >>>> + >>>> + properties: >>>> + qcom,ccu-atid-offset: >>> >>> Why do we need this atid offset ? Couldn't this be mapped to the "port" >>> number ? >>> >>> e.g, input-port 0 on CCU => Offset x >>> input-port 1 on CCU => (Offset x + Size of 1 region) >> If the first ATID offset remains constant, it appears to be feasible. >> We will consider the possibility of this solution. > We just checked the ATID offset varies across different hardware platforms. > It defined as 0xf4 on some platforms, and some others defined as 0xf8. What do you mean ? The offset where you apply the filter changes across different platforms ? or different "tmc-control-unit" implementations ? Is this discoverable from the device ? We could use different compatibles for different "types" of the "devices". Simply adding something in the DT is not the right way. > > So I think it should be better to define it in device tree node. No. See above. Suzuki > >> >>> >>> I believe I mentioned this in the previous posting too ? >> Yes, you mentioned before. I moved it from TMC filed to CCU filed. >> >>> >>> Suzuki >>> >>

1 year

Re: [PATCH v2 2/4] dt-bindings: arm: Add binding document for Coresight Control Unit device.

by Suzuki K Poulose

On 05/07/2024 10:00, Jie Gan wrote: > Add binding document for Coresight Control Unit device. nit: This is again too generic ? corsight-tmc-control-unit ? After all thats what it is and not a *generic* coresight control unit ? > > Signed-off-by: Jie Gan <quic_jiegan(a)quicinc.com> > --- > .../bindings/arm/qcom,coresight-ccu.yaml | 87 +++++++++++++++++++ > 1 file changed, 87 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-ccu.yaml > > diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-ccu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-ccu.yaml > new file mode 100644 > index 000000000000..9bb8ced393a7 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-ccu.yaml > @@ -0,0 +1,87 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/qcom,coresight-ccu.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: CoreSight Control Unit > + > +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 Control unit controls various Coresight behaviors. > + Used to enable/disable ETR’s data filter function based on trace ID. > + > +properties: > + compatible: > + const: qcom,coresight-ccu > + > + reg: > + maxItems: 1 > + > + clocks: > + maxItems: 1 > + > + clock-names: > + items: > + - const: apb_pclk > + > + reg-names: > + items: > + - const: ccu-base > + > + in-ports: > + $ref: /schemas/graph.yaml#/properties/ports > + > + unevaluatedProperties: > + patternProperties: > + '^port(@[0-7])?$': > + description: Input connections from CoreSight Trace bus > + $ref: /schemas/graph.yaml#/properties/port > + > + properties: > + qcom,ccu-atid-offset: Why do we need this atid offset ? Couldn't this be mapped to the "port" number ? e.g, input-port 0 on CCU => Offset x input-port 1 on CCU => (Offset x + Size of 1 region) I believe I mentioned this in the previous posting too ? Suzuki

1 year

Re: [PATCH v1 1/3] dt-bindings: arm: qcom,coresight-static-replicator: Add property for source filtering

by Tao Zhang

On 7/5/2024 6:38 PM, Rob Herring (Arm) wrote: > On Fri, 05 Jul 2024 16:51:50 +0800, Tao Zhang wrote: >> Add a new property "filter_src" to label the source corresponding >> to the output connection for a static replicator. By combining >> a funnel and a static replicator in devicetree, a new device that >> supports multi-port input and multi-port output is implemented. >> In order to match the output port with the input port and >> successfully build the trace path, add this new property to >> indicate the data source corresponding to this output port. >> >> Signed-off-by: Tao Zhang <quic_taozha(a)quicinc.com> >> --- >> .../arm/arm,coresight-static-replicator.yaml | 18 +++++++++++++++++- >> 1 file changed, 17 insertions(+), 1 deletion(-) >> > My bot found errors running 'make dt_binding_check' on your patch: > > yamllint warnings/errors: > > dtschema/dtc warnings/errors: > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml: ^port@[01]$: Missing additionalProperties/unevaluatedProperties constraint > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml: endpoint: Missing additionalProperties/unevaluatedProperties constraint > > doc reference errors (make refcheckdocs): > > See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/202407050851… > > The base for the series is generally the latest rc1. A different dependency > should be noted in *this* patch. > > If you already ran 'make dt_binding_check' and didn't see the above > error(s), then make sure 'yamllint' is installed and dt-schema is up to > date: > > pip3 install dtschema --upgrade Yes, I didn't see this errors in running 'make dt_binding_check', I will re-run this check according to your suggestion. Best, Tao > > Please check and re-submit after running the above command yourself. Note > that DT_SCHEMA_FILES can be set to your schema file to speed up checking > your schema. However, it must be unset to test all examples with your schema. >

1 year

Re: [PATCH v1 1/3] dt-bindings: arm: qcom,coresight-static-replicator: Add property for source filtering

by Tao Zhang

On 7/5/2024 5:02 PM, Krzysztof Kozlowski wrote: > On 05/07/2024 10:51, Tao Zhang wrote: >> Add a new property "filter_src" to label the source corresponding >> to the output connection for a static replicator. By combining >> a funnel and a static replicator in devicetree, a new device that >> supports multi-port input and multi-port output is implemented. >> In order to match the output port with the input port and >> successfully build the trace path, add this new property to >> indicate the data source corresponding to this output port. >> >> Signed-off-by: Tao Zhang<quic_taozha(a)quicinc.com> >> --- >> .../arm/arm,coresight-static-replicator.yaml | 18 +++++++++++++++++- >> 1 file changed, 17 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml >> index 1892a091ac35..d9538563f9c6 100644 >> --- a/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml >> +++ b/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml >> @@ -45,7 +45,21 @@ properties: >> patternProperties: >> '^port@[01]$': >> description: Output connections to CoreSight Trace bus >> - $ref: /schemas/graph.yaml#/properties/port >> + $ref: /schemas/graph.yaml#/$defs/port-base >> + >> + properties: >> + endpoint: >> + $ref: /schemas/media/video-interfaces.yaml# > Ehm? How is this video interface? I referred to other bindings which are done to add properties on endpoint node. How should I add "$ref" here if this video interface is incorrect? > >> + >> + properties: >> + filter_src: > There are no properties with underscores... Sure, I will change it to "filter-src" > >> + $ref: /schemas/types.yaml#/definitions/phandle >> + description: >> + defines a phandle reference to an associated CoreSight trace device. >> + When the associated trace device is enabled, then the respective >> + trace path will be built and enabled. > How does it differ from remote endpoint? What is "respective trace path"? "filter-src" is not the remote endpoint which connect to the current device. It indicate the source device reference of the trace path. Since our new funnel device fixes the correspondence between the output port and the input port by connecting a static replicator. Adding this property allows the driver to find the correct path for the output port in building the path. Best, Tao > > <form letter> > Please use scripts/get_maintainers.pl to get a list of necessary people > and lists to CC (and consider --no-git-fallback argument). It might > happen, that command when run on an older kernel, gives you outdated > entries. Therefore please be sure you base your patches on recent Linux > kernel. > > Tools like b4 or scripts/get_maintainer.pl provide you proper list of > people, so fix your workflow. Tools might also fail if you work on some > ancient tree (don't, instead use mainline) or work on fork of kernel > (don't, instead use mainline). Just use b4 and everything should be > fine, although remember about `b4 prep --auto-to-cc` if you added new > patches to the patchset. > </form letter> > > > Best regards, > Krzysztof >

1 year

[GIT PULL] coresight: Updates for v6.11

by Suzuki K Poulose

Hi Greg, Please find the updates for coresight/hwtracing subsystem targeting v6.11. This is relatively smaller set of cleanups and a fix this time. Kindly pull Suzuki The following changes since commit c3f38fa61af77b49866b006939479069cd451173: Linux 6.10-rc2 (2024-06-02 15:44:56 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git tags/coresight-next-v6.11 for you to fetch changes up to 2e5657aa59669698f0f3bf7742d83577a18eb830: hwtracing: use for_each_endpoint_of_node() (2024-07-01 10:12:35 +0100) ---------------------------------------------------------------- coresight: Updates for v6.11 Coresight/hwtracing subsystem updates targeting v6.11 includes a few minor fixes and cleanups Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> ---------------------------------------------------------------- James Clark (1): coresight: Fix ref leak when of_coresight_parse_endpoint() fails Kuninori Morimoto (1): hwtracing: use for_each_endpoint_of_node() Ricardo B. Marliere (1): coresight: constify the struct device_type usage Yang Li (1): coresight: tmc: Remove duplicated include in coresight-tmc-core.c drivers/hwtracing/coresight/coresight-platform.c | 8 +++++--- drivers/hwtracing/coresight/coresight-priv.h | 2 +- drivers/hwtracing/coresight/coresight-sysfs.c | 2 +- drivers/hwtracing/coresight/coresight-tmc-core.c | 1 - 4 files changed, 7 insertions(+), 6 deletions(-)

1 year

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight