CoreSight

coresight@lists.linaro.org

1 participants
1971 discussions

[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

7 months, 3 weeks

Re: [PATCH 1/8] coresight: ultrasoc-smb: Fix resource leak in .remove()

by hejunhao

On 2023/11/8 4:28, Uwe Kleine-König wrote: > If smb_config_inport() fails it's still necessary to unregister all > resources. As smb_config_inport() already emits an error message on > failure, there is no need to add another one. By not returning the error > code, a second error message (about the return value being ignored) is > suppressed. > > Fixes: 06f5c2926aaa ("drivers/coresight: Add UltraSoc System Memory Buffer driver") > Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Hi, thanks, for the report. Can you try this patch and help review it? https://lore.kernel.org/linux-arm-kernel/20231021083822.18239-3-hejunhao3@h… This patch should have fixed this issue. Best regards, Junhao. > --- > drivers/hwtracing/coresight/ultrasoc-smb.c | 5 +---- > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/hwtracing/coresight/ultrasoc-smb.c b/drivers/hwtracing/coresight/ultrasoc-smb.c > index e9a32a97fbee..10e7d4852112 100644 > --- a/drivers/hwtracing/coresight/ultrasoc-smb.c > +++ b/drivers/hwtracing/coresight/ultrasoc-smb.c > @@ -613,11 +613,8 @@ static int smb_probe(struct platform_device *pdev) > static int smb_remove(struct platform_device *pdev) > { > struct smb_drv_data *drvdata = platform_get_drvdata(pdev); > - int ret; > > - ret = smb_config_inport(&pdev->dev, false); > - if (ret) > - return ret; > + smb_config_inport(&pdev->dev, false); > > smb_unregister_sink(drvdata); >

7 months, 3 weeks

[PATCH v1 0/2] coresight: Add remote etm support

by Mao Jinlong

The system on chip (SoC) consists of main APSS(Applications processor subsytem) and additional processors like modem, lpass. There is coresight-etm driver for etm trace of APSS. Coresight remote etm driver is for enabling and disabling the etm trace of remote processors. It uses QMI interface to communicate with remote processors' software and uses coresight framework to configure the connection from remote etm source to TMC sinks. Example to capture the remote etm trace: Enable source: echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink echo 1 > /sys/bus/coresight/devices/remote_etm0/enable_source Capture the trace: cat /dev/tmc_etf0 > /data/remote_etm.bin Disable source: echo 0 > /sys/bus/coresight/devices/remote_etm0/enable_source Mao Jinlong (2): coresight: Add remote etm support dt-bindings: arm: Add remote etm driver .../arm/qcom,coresight-remote-etm.yaml | 59 ++++ drivers/hwtracing/coresight/Kconfig | 9 + drivers/hwtracing/coresight/Makefile | 1 + drivers/hwtracing/coresight/coresight-core.c | 3 + drivers/hwtracing/coresight/coresight-qmi.h | 109 ++++++ .../coresight/coresight-remote-etm.c | 325 ++++++++++++++++++ include/linux/coresight.h | 1 + 7 files changed, 507 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml create mode 100644 drivers/hwtracing/coresight/coresight-qmi.h create mode 100644 drivers/hwtracing/coresight/coresight-remote-etm.c -- 2.41.0

7 months, 3 weeks

Re: [PATCH v1 1/2] coresight: Add remote etm support

by Jinlong Mao

On 11/7/2023 11:26 PM, Krzysztof Kozlowski wrote: > On 07/11/2023 07:09, Mao Jinlong wrote: >> Add support for ETM trace collection on remote processor using >> coreSight framework. >> >> Signed-off-by: Mao Jinlong <quic_jinlmao(a)quicinc.com> >> --- >> drivers/hwtracing/coresight/Kconfig | 9 + >> drivers/hwtracing/coresight/Makefile | 1 + >> drivers/hwtracing/coresight/coresight-core.c | 3 + >> drivers/hwtracing/coresight/coresight-qmi.h | 109 ++++++ >> .../coresight/coresight-remote-etm.c | 325 ++++++++++++++++++ >> include/linux/coresight.h | 1 + >> 6 files changed, 448 insertions(+) >> create mode 100644 drivers/hwtracing/coresight/coresight-qmi.h >> create mode 100644 drivers/hwtracing/coresight/coresight-remote-etm.c >> >> diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig >> index 06f0a7594169..425886ab7401 100644 >> --- a/drivers/hwtracing/coresight/Kconfig >> +++ b/drivers/hwtracing/coresight/Kconfig >> @@ -247,4 +247,13 @@ config CORESIGHT_DUMMY >> >> To compile this driver as a module, choose M here: the module will be >> called coresight-dummy. >> + >> +config CORESIGHT_REMOTE_ETM >> + tristate "Remote processor ETM trace support" >> + select QCOM_QMI_HELPERS >> + help >> + Enables support for ETM trace collection on remote processor using >> + CoreSight framework. Enabling this will allow turning on ETM >> + tracing on remote processor via sysfs by configuring the required >> + CoreSight components. >> endif ..... >> +} >> + >> +static const struct of_device_id remote_etm_match[] = { >> + {.compatible = "qcom,coresight-remote-etm"}, > Please order your patches correctly, so binding is documented before the > users. > >> + {} >> +}; >> + >> +static struct platform_driver remote_etm_driver = { >> + .probe = remote_etm_probe, >> + .remove = remote_etm_remove, >> + .driver = { >> + .name = "coresight-remote-etm", >> + .of_match_table = remote_etm_match, >> + }, >> +}; >> + >> +int __init remote_etm_init(void) >> +{ >> + return platform_driver_register(&remote_etm_driver); >> +} >> +module_init(remote_etm_init); >> + >> +void __exit remote_etm_exit(void) >> +{ >> + platform_driver_unregister(&remote_etm_driver); >> +} >> +module_exit(remote_etm_exit); > Why aren't you using module platform driver? > > Best regards, > Krzysztof Thanks for the review. I will check and address your comments. Thanks Jinlong Mao >

7 months, 3 weeks

Re: [PATCH 1/3] perf tests test_arm_coresight: Fix the shellcheck warning in latest test_arm_coresight.sh

by Arnaldo Carvalho de Melo

Em Tue, Nov 07, 2023 at 12:08:25PM +0530, Athira Rajeev escreveu: > > On 07-Nov-2023, at 3:14 AM, Arnaldo Carvalho de Melo <acme(a)kernel.org> wrote: > >>> Reviewed-by: James Clark <james.clark(a)arm.com> > > Some are not applying, even after b4 picking up v2 > > Total patches: 3 > > Cover: ./v2_20231013_atrajeev_fix_for_shellcheck_issues_with_latest_scripts_in_tests_shell.cover > > Link: https://lore.kernel.org/r/20231013073021.99794-1-atrajeev@linux.vnet.ibm.com > > Base: not specified > > git am ./v2_20231013_atrajeev_fix_for_shellcheck_issues_with_latest_scripts_in_tests_shell.mbx > > ⬢[acme@toolbox perf-tools-next]$ git am ./v2_20231013_atrajeev_fix_for_shellcheck_issues_with_latest_scripts_in_tests_shell.mbx > > Applying: tools/perf/tests Ignore the shellcheck SC2046 warning in lock_contention > > error: patch failed: tools/perf/tests/shell/lock_contention.sh:33 > > error: tools/perf/tests/shell/lock_contention.sh: patch does not apply > > Patch failed at 0001 tools/perf/tests Ignore the shellcheck SC2046 warning in lock_contention > > hint: Use 'git am --show-current-patch=diff' to see the failed patch > > When you have resolved this problem, run "git am --continue". > > If you prefer to skip this patch, run "git am --skip" instead. > > To restore the original branch and stop patching, run "git am --abort". > > ⬢[acme@toolbox perf-tools-next]$ git am --abort > > ⬢[acme@toolbox perf-tools-next]$ > The patch is picked up : https://lore.kernel.org/all/169757198796.167943.10552920255799914362.b4-ty@… . > Thanks for looking into. Thanks for checking, my mistake then, - Arnaldo

7 months, 3 weeks

Re: [PATCH v2 1/8] dt-bindings: arm: Add support for CMB element size

by Tao Zhang

On 10/27/2023 5:25 AM, Rob Herring wrote: > On Wed, Oct 25, 2023 at 10:53:21AM +0800, Tao Zhang wrote: >> Add property "qcom,cmb-elem-size" to support CMB(Continuous >> Multi-Bit) element for TPDM. The associated aggregator will read >> this size before it is enabled. CMB element size currently only >> supports 32-bit and 64-bit. >> >> Signed-off-by: Tao Zhang <quic_taozha(a)quicinc.com> >> Signed-off-by: Mao Jinlong <quic_jinlmao(a)quicinc.com> >> --- >> .../bindings/arm/qcom,coresight-tpdm.yaml | 27 ++++++++++++++++++++++ >> 1 file changed, 27 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml >> index 61ddc3b..f9a2025 100644 >> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml >> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml >> @@ -52,6 +52,14 @@ properties: >> $ref: /schemas/types.yaml#/definitions/uint8 >> enum: [32, 64] >> >> + qcom,cmb-element-size: > What are the units? Use '-bits' suffix. Yes, its unit should be bit. Do you mean that you prefer to use "qcom, cmb-element-size-bits"? Do I also need to replace "qcom, dsb-element-size" with "qcom, dsb-element-size-bits". > >> + description: >> + Specifies the CMB(Continuous Multi-Bit) element size supported by >> + the monitor. The associated aggregator will read this size before it >> + is enabled. CMB element size currently only supports 32-bit and 64-bit. > The enum says 8-bit is supported. Yes, 8-bit is supported. I will update the description in the next patch series. Best, Tao > >> + $ref: /schemas/types.yaml#/definitions/uint8 >> + enum: [8, 32, 64] >> + >> qcom,dsb-msrs-num: >> description: >> Specifies the number of DSB(Discrete Single Bit) MSR(mux select register) >> @@ -110,4 +118,23 @@ examples: >> }; >> }; >> >> + tpdm@6c29000 { >> + compatible = "qcom,coresight-tpdm", "arm,primecell"; >> + reg = <0x06c29000 0x1000>; >> + reg-names = "tpdm-base"; >> + >> + qcom,cmb-element-size = /bits/ 8 <64>; >> + >> + clocks = <&aoss_qmp>; >> + clock-names = "apb_pclk"; >> + >> + out-ports { >> + port { >> + tpdm_ipcc_out_funnel_center: endpoint { >> + remote-endpoint = >> + <&funnel_center_in_tpdm_ipcc>; >> + }; >> + }; >> + }; >> + }; >> ... >> -- >> 2.7.4 >>

7 months, 3 weeks

Re: [PATCH v1 1/2] perf auxtrace: Add 'T' itrace option for timestamp trace

by Leo Yan

Hi Adrian, On Tue, Nov 07, 2023 at 09:19:10AM +0200, Adrian Hunter wrote: > On 6/11/23 23:52, Arnaldo Carvalho de Melo wrote: > > Em Thu, Oct 19, 2023 at 01:47:15PM +0300, Adrian Hunter escreveu: > >> On 14/10/23 10:45, Leo Yan wrote: > >>> An AUX trace can contain timestamp, but in some situations, the hardware > >>> trace module (e.g. Arm CoreSight) cannot decide the traced timestamp is > >>> the same source with CPU's time, thus the decoder can not use the > >>> timestamp trace for samples. > >>> > >>> This patch introduces 'T' itrace option. If users know the platforms > >> > >> "If users know" <- how would users know? Could the kernel > >> or tools also figure it out? > > > > Adrian, I'm trying to go all the outstanding patches, do you still have > > any issues with this series? > > No, although the question wasn't actually answered. I presume users > just have to try the 'T' option and see if it helps. Sometimes, users are software developers in SoC companies, they can know well for the hardware design but are confused why current implementation cannot use timestamp trace. This is the main reason I sent this patch set. An example hardware platform is DB410c [1], we know its CoreSight can support timestamp trace, but if without this adding option 'T', we have no chance to use it due to it its CPU arch is prior to Armv8.4. @Arnaldo, since James gave comments in his replying, I will respin new patch set and send out. Thanks for popping up this patch set! Leo [1] https://developer.qualcomm.com/hardware/dragonboard-410c

7 months, 3 weeks

Re: [PATCH v1 1/2] perf auxtrace: Add 'T' itrace option for timestamp trace

by James Clark

On 07/11/2023 07:19, Adrian Hunter wrote: > On 6/11/23 23:52, Arnaldo Carvalho de Melo wrote: >> Em Thu, Oct 19, 2023 at 01:47:15PM +0300, Adrian Hunter escreveu: >>> On 14/10/23 10:45, Leo Yan wrote: >>>> An AUX trace can contain timestamp, but in some situations, the hardware >>>> trace module (e.g. Arm CoreSight) cannot decide the traced timestamp is >>>> the same source with CPU's time, thus the decoder can not use the >>>> timestamp trace for samples. >>>> >>>> This patch introduces 'T' itrace option. If users know the platforms >>> >>> "If users know" <- how would users know? Could the kernel >>> or tools also figure it out? >> >> Adrian, I'm trying to go all the outstanding patches, do you still have >> any issues with this series? > > No, although the question wasn't actually answered. I presume users > just have to try the 'T' option and see if it helps. > I suppose my previous answer about discoverability was more general. To answer the specific question "how would users know?", it would have to be mentioned in the reference manual of their device that this is how the timers are set up. But I don't see this being a common use case, as I mentioned before, in newer arm platforms this is discoverable and just works.

7 months, 3 weeks

Re: [PATCH v1 1/2] perf auxtrace: Add 'T' itrace option for timestamp trace

by Arnaldo Carvalho de Melo

Em Thu, Oct 19, 2023 at 01:47:15PM +0300, Adrian Hunter escreveu: > On 14/10/23 10:45, Leo Yan wrote: > > An AUX trace can contain timestamp, but in some situations, the hardware > > trace module (e.g. Arm CoreSight) cannot decide the traced timestamp is > > the same source with CPU's time, thus the decoder can not use the > > timestamp trace for samples. > > > > This patch introduces 'T' itrace option. If users know the platforms > > "If users know" <- how would users know? Could the kernel > or tools also figure it out? Adrian, I'm trying to go all the outstanding patches, do you still have any issues with this series? - Arnaldo > > they are working on have the same time counter with CPUs, users can > > use this new option to tell a decoder for using timestamp trace as > > kernel time. > > > > Signed-off-by: Leo Yan <leo.yan(a)linaro.org> > > --- > > tools/perf/Documentation/itrace.txt | 1 + > > tools/perf/util/auxtrace.c | 3 +++ > > tools/perf/util/auxtrace.h | 3 +++ > > 3 files changed, 7 insertions(+) > > > > diff --git a/tools/perf/Documentation/itrace.txt b/tools/perf/Documentation/itrace.txt > > index a97f95825b14..19cc179be9a7 100644 > > --- a/tools/perf/Documentation/itrace.txt > > +++ b/tools/perf/Documentation/itrace.txt > > @@ -25,6 +25,7 @@ > > q quicker (less detailed) decoding > > A approximate IPC > > Z prefer to ignore timestamps (so-called "timeless" decoding) > > + T use the timestamp trace as kernel time > > > > The default is all events i.e. the same as --itrace=iybxwpe, > > except for perf script where it is --itrace=ce > > diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c > > index a0368202a746..f528c4364d23 100644 > > --- a/tools/perf/util/auxtrace.c > > +++ b/tools/perf/util/auxtrace.c > > @@ -1638,6 +1638,9 @@ int itrace_do_parse_synth_opts(struct itrace_synth_opts *synth_opts, > > case 'Z': > > synth_opts->timeless_decoding = true; > > break; > > + case 'T': > > + synth_opts->use_timestamp = true; > > + break; > > case ' ': > > case ',': > > break; > > diff --git a/tools/perf/util/auxtrace.h b/tools/perf/util/auxtrace.h > > index 29eb82dff574..55702215a82d 100644 > > --- a/tools/perf/util/auxtrace.h > > +++ b/tools/perf/util/auxtrace.h > > @@ -99,6 +99,7 @@ enum itrace_period_type { > > * @remote_access: whether to synthesize remote access events > > * @mem: whether to synthesize memory events > > * @timeless_decoding: prefer "timeless" decoding i.e. ignore timestamps > > + * @use_timestamp: use the timestamp trace as kernel time > > * @vm_time_correlation: perform VM Time Correlation > > * @vm_tm_corr_dry_run: VM Time Correlation dry-run > > * @vm_tm_corr_args: VM Time Correlation implementation-specific arguments > > @@ -146,6 +147,7 @@ struct itrace_synth_opts { > > bool remote_access; > > bool mem; > > bool timeless_decoding; > > + bool use_timestamp; > > bool vm_time_correlation; > > bool vm_tm_corr_dry_run; > > char *vm_tm_corr_args; > > @@ -678,6 +680,7 @@ bool auxtrace__evsel_is_auxtrace(struct perf_session *session, > > " q: quicker (less detailed) decoding\n" \ > > " A: approximate IPC\n" \ > > " Z: prefer to ignore timestamps (so-called \"timeless\" decoding)\n" \ > > +" T: use the timestamp trace as kernel time\n" \ > > " PERIOD[ns|us|ms|i|t]: specify period to sample stream\n" \ > > " concatenate multiple options. Default is iybxwpe or cewp\n" > > > -- - Arnaldo

7 months, 3 weeks

Re: [PATCH 1/3] perf tests test_arm_coresight: Fix the shellcheck warning in latest test_arm_coresight.sh

by Arnaldo Carvalho de Melo

Em Thu, Oct 05, 2023 at 02:24:15PM +0530, Athira Rajeev escreveu: > > On 05-Oct-2023, at 1:50 PM, James Clark <james.clark(a)arm.com> wrote: > > On 29/09/2023 05:11, Athira Rajeev wrote: > >> Running shellcheck on tests/shell/test_arm_coresight.sh > >> throws below warnings: > >> > >> In tests/shell/test_arm_coresight.sh line 15: > >> cs_etm_path=$(find /sys/bus/event_source/devices/cs_etm/ -name cpu* -print -quit) > >> ^--^ SC2061: Quote the parameter to -name so the shell won't interpret it. > >> > >> In tests/shell/test_arm_coresight.sh line 20: > >> if [ $archhver -eq 5 -a "$(printf "0x%X\n" $archpart)" = "0xA13" ] ; then > >> ^-- SC2166: Prefer [ p ] && [ q ] as [ p -a q ] is not well defined > >> > >> This warning is observed after commit: > >> "commit bb350847965d ("perf test: Update cs_etm testcase for Arm ETE")" > >> > >> Fixed this issue by using quoting 'cpu*' for SC2061 and > >> using "&&" in line number 20 for SC2166 warning > >> > >> Fixes: bb350847965d ("perf test: Update cs_etm testcase for Arm ETE") > >> Signed-off-by: Athira Rajeev <atrajeev(a)linux.vnet.ibm.com> > >> --- > >> tools/perf/tests/shell/test_arm_coresight.sh | 4 ++-- > >> 1 file changed, 2 insertions(+), 2 deletions(-) > >> > >> diff --git a/tools/perf/tests/shell/test_arm_coresight.sh b/tools/perf/tests/shell/test_arm_coresight.sh > >> index fe78c4626e45..f2115dfa24a5 100755 > >> --- a/tools/perf/tests/shell/test_arm_coresight.sh > >> +++ b/tools/perf/tests/shell/test_arm_coresight.sh > >> @@ -12,12 +12,12 @@ > >> glb_err=0 > >> > >> cs_etm_dev_name() { > >> - cs_etm_path=$(find /sys/bus/event_source/devices/cs_etm/ -name cpu* -print -quit) > >> + 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 > >> + if [ $archhver -eq 5 ] && [ "$(printf "0x%X\n" $archpart)" = "0xA13" ] ; then > >> echo "ete" > >> else > >> echo "etm" > > > > > > Reviewed-by: James Clark <james.clark(a)arm.com> Some are not applying, even after b4 picking up v2 Total patches: 3 --- Cover: ./v2_20231013_atrajeev_fix_for_shellcheck_issues_with_latest_scripts_in_tests_shell.cover Link: https://lore.kernel.org/r/20231013073021.99794-1-atrajeev@linux.vnet.ibm.com Base: not specified git am ./v2_20231013_atrajeev_fix_for_shellcheck_issues_with_latest_scripts_in_tests_shell.mbx ⬢[acme@toolbox perf-tools-next]$ git am ./v2_20231013_atrajeev_fix_for_shellcheck_issues_with_latest_scripts_in_tests_shell.mbx Applying: tools/perf/tests Ignore the shellcheck SC2046 warning in lock_contention error: patch failed: tools/perf/tests/shell/lock_contention.sh:33 error: tools/perf/tests/shell/lock_contention.sh: patch does not apply Patch failed at 0001 tools/perf/tests Ignore the shellcheck SC2046 warning in lock_contention hint: Use 'git am --show-current-patch=diff' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ⬢[acme@toolbox perf-tools-next]$ git am --abort ⬢[acme@toolbox perf-tools-next]$

7 months, 3 weeks

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight