CoreSight

coresight@lists.linaro.org

2 participants
2384 discussions

[PATCH v12 0/9] Coresight: Add support for TPDM and TPDA

by Mao Jinlong

This series adds support for the trace performance monitoring and diagnostics hardware (TPDM and TPDA). It is composed of two major elements. a) Changes for original coresight framework to support for TPDM and TPDA. b) Add driver code for TPDM and TPDA. Introduction of changes for original coresight framework Support TPDM as new coresight source. Since only STM and ETM are supported as coresight source originally. TPDM is a newly added coresight source. We need to change the original way of saving coresight path to support more types source for coresight driver. The following patch is to add support more coresight sources. coresight: core: Use IDR for non-cpu bound sources' paths. Introduction of TPDM and TPDA TPDM - The trace performance monitoring and diagnostics monitor or TPDM in short serves as data collection component for various dataset types specified in the QPMDA(Qualcomm performance monitoring and diagnostics architecture) spec. The primary use case of the TPDM is to collect data from different data sources and send it to a TPDA for packetization, timestamping and funneling. Coresight: Add coresight TPDM source driver dt-bindings: arm: Adds CoreSight TPDM hardware definitions coresight-tpdm: Add DSB dataset support coresight-tpdm: Add integration test support docs: sysfs: coresight: Add sysfs ABI documentation for TPDM TPDA - The trace performance monitoring and diagnostics aggregator or TPDA in short serves as an arbitration and packetization engine for the performance monitoring and diagnostics network as specified in the QPMDA (Qualcomm performance monitoring and diagnostics architecture) specification. The primary use case of the TPDA is to provide packetization, funneling and timestamping of Monitor data as specified in the QPMDA specification. The following patch is to add driver for TPDA. Coresight: Add TPDA link driver dt-bindings: arm: Adds CoreSight TPDA hardware definitions The last patch of this series is a device tree modification, which add the TPDM and TPDA configuration to device tree for validating. ARM: dts: msm: Add coresight components for SM8250 ARM: dts: msm: Add tpdm mm/prng for sm8250 Once this series patches are applied properly, the tpdm and tpda nodes should be observed at the coresight path /sys/bus/coresight/devices e.g. /sys/bus/coresight/devices # ls -l | grep tpd tpda0 -> ../../../devices/platform/soc(a)0/6004000.tpda/tpda0 tpdm0 -> ../../../devices/platform/soc(a)0/6c08000.mm.tpdm/tpdm0 We can use the commands are similar to the below to validate TPDMs. Enable coresight sink first. echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink echo 1 > /sys/bus/coresight/devices/tpdm0/enable_source echo 1 > /sys/bus/coresight/devices/tpdm0/integration_test echo 2 > /sys/bus/coresight/devices/tpdm0/integration_test The test data will be collected in the coresight sink which is enabled. If rwp register of the sink is keeping updating when do integration_test (by cat tmc_etf0/mgmt/rwp), it means there is data generated from TPDM to sink. There must be a tpda between tpdm and the sink. When there are some other trace event hw components in the same HW block with tpdm, tpdm and these hw components will connect to the coresight funnel. When there is only tpdm trace hw in the HW block, tpdm will connect to tpda directly. +---------------+ +-------------+ | tpdm@6c08000 | |tpdm@684C000 | +-------|-------+ +------|------+ | | +-------|-------+ | | funnel@6c0b000| | +-------|-------+ | | | +-------|-------+ | |funnel@6c2d000 | | +-------|-------+ | | | | +---------------+ | +----- tpda@6004000 -----------+ +-------|-------+ | +-------|-------+ |funnel@6005000 | +---------------+ This patch series depends on patch series: "[v2,00/13] coresight: Add new API to allocate trace source ID values" https://patchwork.kernel.org/project/linux-arm-kernel/cover/20220704081149.… Changes from V11: 1. Clear bits for atid before setting them and relese atid when tpda remove. -- Suzuki K Poulose <suzuki.poulose(a)arm.com> Mao Jinlong (9): coresight: core: Use IDR for non-cpu bound sources' paths. Coresight: Add coresight TPDM source driver dt-bindings: arm: Adds CoreSight TPDM hardware definitions coresight-tpdm: Add DSB dataset support coresight-tpdm: Add integration test support Coresight: Add TPDA link driver dt-bindings: arm: Adds CoreSight TPDA hardware definitions arm64: dts: qcom: sm8250: Add coresight components arm64: dts: qcom: sm8250: Add tpdm mm/prng .../testing/sysfs-bus-coresight-devices-tpdm | 13 + .../bindings/arm/qcom,coresight-tpda.yaml | 111 +++ .../bindings/arm/qcom,coresight-tpdm.yaml | 93 +++ MAINTAINERS | 2 + arch/arm64/boot/dts/qcom/sm8250.dtsi | 671 ++++++++++++++++++ drivers/hwtracing/coresight/Kconfig | 23 + drivers/hwtracing/coresight/Makefile | 2 + drivers/hwtracing/coresight/coresight-core.c | 42 +- drivers/hwtracing/coresight/coresight-tpda.c | 208 ++++++ drivers/hwtracing/coresight/coresight-tpda.h | 35 + drivers/hwtracing/coresight/coresight-tpdm.c | 259 +++++++ drivers/hwtracing/coresight/coresight-tpdm.h | 62 ++ include/linux/coresight.h | 1 + 13 files changed, 1510 insertions(+), 12 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml create mode 100644 drivers/hwtracing/coresight/coresight-tpda.c create mode 100644 drivers/hwtracing/coresight/coresight-tpda.h create mode 100644 drivers/hwtracing/coresight/coresight-tpdm.c create mode 100644 drivers/hwtracing/coresight/coresight-tpdm.h -- 2.17.1

2 years, 11 months

Re: [-next] Lockdep warnings

by Leo Yan

On Tue, Jul 26, 2022 at 01:50:06PM +0100, Mark Rutland wrote: > On Tue, Jul 26, 2022 at 01:40:40PM +0100, Mark Rutland wrote: > > [Adding Peter; I suspect this is due to the cpuidle rework] > > Looking again I see the cpuidle rework isn't in next, so evidently not... > > Sorry for the noise! I'd like to loop in Mike.L and CoreSight ML for CTI PM callbacks. Please see below a comment for CTI spinlock usage. > > I'll go give next a spin in a VM, but I suspect I might need real HW to see > > this due to the way PSCI idle states work. > > > > Mark. > > > > On Tue, Jul 26, 2022 at 11:41:34AM +0100, Sudeep Holla wrote: > > > I was seeing the below lockdep warnings on my arm64 Juno development > > > platform almost 2 weeks back with -next. I wanted to check for similar > > > reports before post and forgot. > > > > > > --->8 > > > > > > DEBUG_LOCKS_WARN_ON(lockdep_hardirqs_enabled()) > > > hardirqs last enabled at (46157): cpuidle_enter_state+0x174/0x2b4 > > > WARNING: CPU: 5 PID: 0 at kernel/locking/lockdep.c:5506 check_flags+0x90/0x1e8 > > > hardirqs last disabled at (46158): el1_interrupt+0x2c/0xc8 > > > Modules linked in: > > > softirqs last enabled at (46154): __do_softirq+0x2c0/0x388 > > > softirqs last disabled at (46139): __irq_exit_rcu+0x118/0x18c > > > CPU: 5 PID: 0 Comm: swapper/5 Not tainted 5.19.0-rc6-next-20220714 #9 > > > pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > > > pc : check_flags+0x90/0x1e8 > > > lr : check_flags+0x90/0x1e8 > > > Call trace: > > > check_flags+0x90/0x1e8 > > > lock_is_held_type+0x80/0x164 > > > rcu_read_lock_sched_held+0x40/0x7c > > > trace_rcu_dyntick+0x5c/0x140 > > > ct_kernel_enter+0x78/0xd4 > > > ct_idle_exit+0x1c/0x44 > > > cpu_idle_poll+0x74/0xb8 > > > do_idle+0x90/0x2c4 > > > cpu_startup_entry+0x30/0x34 > > > secondary_start_kernel+0x130/0x144 > > > __secondary_switched+0xb0/0xb4 > > > irq event stamp: 64229 > > > hardirqs last enabled at (64229): cpu_idle_poll+0x40/0xb8 > > > hardirqs last disabled at (64228): do_idle+0xbc/0x2c4 > > > softirqs last enabled at (64190): __do_softirq+0x2c0/0x388 > > > softirqs last disabled at (64185): __irq_exit_rcu+0x118/0x18c > > > ---[ end trace 0000000000000000 ]--- > > > possible reason: unannotated irqs-off. > > > irq event stamp: 64229 > > > hardirqs last enabled at (64229): cpu_idle_poll+0x40/0xb8 > > > hardirqs last disabled at (64228): do_idle+0xbc/0x2c4 > > > softirqs last enabled at (64190): __do_softirq+0x2c0/0x388 > > > softirqs last disabled at (64185): __irq_exit_rcu+0x118/0x18c > > > > > > ---- > > > > > > However I don't see the above warning with the latest -next. When I tried > > > yesterday's -next now, I see a different warning. Not sure if they are > > > related. I haven't tried to bisect. > > > > > > --->8 > > > ============================= > > > [ BUG: Invalid wait context ] > > > 5.19.0-rc8-next-20220725 #38 Not tainted > > > ----------------------------- > > > swapper/0/0 is trying to lock: > > > (&drvdata->spinlock){....}-{3:3}, at: cti_cpu_pm_notify+0x54/0x114 > > > other info that might help us debug this: > > > context-{5:5} > > > 1 lock held by swapper/0/0: > > > #0: (cpu_pm_notifier.lock){....}-{2:2}, at: cpu_pm_enter+0x2c/0x80 > > > stack backtrace: > > > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc8-next-20220725-00004-g599e6691ed8c #38 > > > Call trace: > > > dump_backtrace+0xe8/0x108 > > > show_stack+0x18/0x4c > > > dump_stack_lvl+0x90/0xc8 > > > dump_stack+0x18/0x54 > > > __lock_acquire+0xa70/0x32d0 > > > lock_acquire+0x160/0x308 > > > _raw_spin_lock+0x60/0xa0 > > > cti_cpu_pm_notify+0x54/0x114 > > > raw_notifier_call_chain_robust+0x50/0xd4 > > > cpu_pm_enter+0x48/0x80 > > > psci_enter_idle_state+0x34/0x74 > > > cpuidle_enter_state+0x120/0x2a8 > > > cpuidle_enter+0x38/0x50 > > > do_idle+0x1e8/0x2b8 > > > cpu_startup_entry+0x24/0x28 > > > kernel_init+0x0/0x1a0 > > > start_kernel+0x0/0x470 > > > start_kernel+0x34c/0x470 > > > __primary_switched+0xbc/0xc4 If we look into for this callback, we can see the lock sequence is: cti_cpu_pm_notify() `> cpu_pm_notify_robust(): `> raw_spin_lock_irqsave(cpu_pm_notifier.lock, flag) -> a raw spinlock `> cti_cpu_pm_notify() `> spin_lock(&drvdata->spinlock) -> a normal spinlock A raw spinlock is not a sleepable lock, and normal spinlock can be a sleepable lock (e.g. it can be a mutex after enabled PREEMPT_RT). One solution is we can change to a raw spinlock in CTI driver, so this can dismiss the lockdep warning. Actually, I am a bit suspect if it's really necessary to use spinlock in CTI PM callbacks, the reason is in CPU's idle flow, it will run into idle thread context and disable the local IRQ, which means it likely has no race condition with thread context and interrupt handler, so we can remove the locking in PM callbacks. Mike, could you check for this? Thanks! Leo

2 years, 11 months

[PATCH v1 0/4] coresight: Reduce duplicated sysfs accessors

by James Clark

The intent of this change is to reduce the large number identical of functions created by macros for sysfs accessors. It's possible to re-use the same function but pass in the register to access as an argument. This reduces the size of the coresight modules folder by 244KB. The first two patches are refactors to simplify and remove some dead code, and the second two are the changes to use a shared function. Testing ======= No changes in any of the outputs: cat /sys/bus/coresight/devices/*/mgmt/* > before.txt cat /sys/bus/coresight/devices/*/mgmt/* > after.txt diff before.txt after.txt With the following modules loaded: ls /sys/bus/coresight/devices/ etm0 etm2 funnel0 funnel2 replicator0 tmc_etf0 tmc_etf2 tpiu0 etm1 etm3 funnel1 funnel3 stm0 tmc_etf1 tmc_etr0 James Clark (4): coresight: Remove unused function parameter coresight: Simplify sysfs accessors by using csdev_access abstraction coresight: Re-use same function for similar sysfs register accessors coresight: cti-sysfs: Re-use same functions for similar sysfs register accessors drivers/hwtracing/coresight/coresight-catu.c | 27 +-- drivers/hwtracing/coresight/coresight-core.c | 14 ++ .../hwtracing/coresight/coresight-cti-sysfs.c | 213 +++++++----------- drivers/hwtracing/coresight/coresight-etb10.c | 28 +-- .../coresight/coresight-etm3x-sysfs.c | 34 +-- drivers/hwtracing/coresight/coresight-priv.h | 48 ++-- .../coresight/coresight-replicator.c | 10 +- drivers/hwtracing/coresight/coresight-stm.c | 40 +--- .../hwtracing/coresight/coresight-tmc-core.c | 48 ++-- include/linux/coresight.h | 18 ++ 10 files changed, 196 insertions(+), 284 deletions(-) -- 2.28.0

2 years, 11 months

Re: [PATCH] coresight: trbe: fix Kconfig "its" grammar

by Mathieu Poirier

Hi Randy - I'll pick this up for the next cycle. Thanks, Mathieu On Thu, 14 Jul 2022 at 19:59, Randy Dunlap <rdunlap(a)infradead.org> wrote: > > Use the possessive "its" instead of the contraction "it's" > where appropriate. > > Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> > Cc: Anshuman Khandual <anshuman.khandual(a)arm.com> > Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> > Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> > Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> > Cc: coresight(a)lists.linaro.org > Cc: linux-arm-kernel(a)lists.infradead.org > --- > drivers/hwtracing/coresight/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > --- a/drivers/hwtracing/coresight/Kconfig > +++ b/drivers/hwtracing/coresight/Kconfig > @@ -193,10 +193,10 @@ config CORESIGHT_TRBE > depends on ARM64 && CORESIGHT_SOURCE_ETM4X > help > This driver provides support for percpu Trace Buffer Extension (TRBE). > - TRBE always needs to be used along with it's corresponding percpu ETE > + TRBE always needs to be used along with its corresponding percpu ETE > component. ETE generates trace data which is then captured with TRBE. > Unlike traditional sink devices, TRBE is a CPU feature accessible via > - system registers. But it's explicit dependency with trace unit (ETE) > + system registers. But its explicit dependency with trace unit (ETE) > requires it to be plugged in as a coresight sink device. > > To compile this driver as a module, choose M here: the module will be

2 years, 11 months

[GIT PULL] CoreSight changes for v5.20

by Suzuki K Poulose

Hi Greg, Please find the CoreSight updates for v5.20 below. Kindly consider pulling. Thanks Suzuki The following changes since commit a111daf0c53ae91e71fd2bfe7497862d14132e3e: Linux 5.19-rc3 (2022-06-19 15:06:47 -0500) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git tags/coresight-next-v5.20 for you to fetch changes up to 4d45bc82df667ad9e9cb8361830e54fc1264e993: coresight: etm4x: avoid build failure with unrolled loops (2022-07-11 09:22:35 +0100) ---------------------------------------------------------------- CoreSight self-hosted tracing changes for v5.20. - Fixes LOCKDEP warnings on module unload with configfs - Conversion of DT bindings to DT schema - Branch broadcast support for perf cs_etm - Etm4x driver fixes for build failures with Clang and unrolled loops Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> ---------------------------------------------------------------- Bagas Sanjaya (1): Documentation: coresight: Escape coresight bindings file wildcard James Clark (4): coresight: Add config flag to enable branch broadcast Documentation: coresight: Turn numbered subsections into real subsections Documentation: coresight: Link config options to existing documentation Documentation: coresight: Expand branch broadcast documentation Mike Leach (2): coresight: configfs: Fix unload of configurations on module exit coresight: syscfg: Update load and unload operations Nick Desaulniers (1): coresight: etm4x: avoid build failure with unrolled loops Rob Herring (3): dt-bindings: arm: Rename Coresight filenames to match compatible dt-bindings: arm: Convert CoreSight bindings to DT schema dt-bindings: arm: Convert CoreSight CPU debug to DT schema Suzuki K Poulose (1): coresight: Clear the connection field properly .../bindings/arm/arm,coresight-catu.yaml | 101 ++++++ .../bindings/arm/arm,coresight-cpu-debug.yaml | 81 +++++ .../{coresight-cti.yaml => arm,coresight-cti.yaml} | 5 +- .../bindings/arm/arm,coresight-dynamic-funnel.yaml | 126 +++++++ .../arm/arm,coresight-dynamic-replicator.yaml | 126 +++++++ .../bindings/arm/arm,coresight-etb10.yaml | 92 +++++ .../devicetree/bindings/arm/arm,coresight-etm.yaml | 156 ++++++++ .../bindings/arm/arm,coresight-static-funnel.yaml | 90 +++++ .../arm/arm,coresight-static-replicator.yaml | 91 +++++ .../devicetree/bindings/arm/arm,coresight-stm.yaml | 101 ++++++ .../devicetree/bindings/arm/arm,coresight-tmc.yaml | 131 +++++++ .../bindings/arm/arm,coresight-tpiu.yaml | 91 +++++ ...{ete.yaml => arm,embedded-trace-extension.yaml} | 3 +- .../{trbe.yaml => arm,trace-buffer-extension.yaml} | 2 +- .../bindings/arm/coresight-cpu-debug.txt | 49 --- .../devicetree/bindings/arm/coresight.txt | 402 --------------------- .../trace/coresight/coresight-etm4x-reference.rst | 17 +- Documentation/trace/coresight/coresight.rst | 58 ++- MAINTAINERS | 8 +- drivers/hwtracing/coresight/coresight-config.h | 2 + drivers/hwtracing/coresight/coresight-core.c | 1 + drivers/hwtracing/coresight/coresight-etm-perf.c | 2 + drivers/hwtracing/coresight/coresight-etm4x-core.c | 14 + drivers/hwtracing/coresight/coresight-etm4x.h | 3 +- drivers/hwtracing/coresight/coresight-syscfg.c | 299 ++++++++++++--- drivers/hwtracing/coresight/coresight-syscfg.h | 13 + include/linux/coresight-pmu.h | 2 + 27 files changed, 1542 insertions(+), 524 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/arm,coresight-catu.yaml create mode 100644 Documentation/devicetree/bindings/arm/arm,coresight-cpu-debug.yaml rename Documentation/devicetree/bindings/arm/{coresight-cti.yaml => arm,coresight-cti.yaml} (98%) create mode 100644 Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml create mode 100644 Documentation/devicetree/bindings/arm/arm,coresight-dynamic-replicator.yaml create mode 100644 Documentation/devicetree/bindings/arm/arm,coresight-etb10.yaml create mode 100644 Documentation/devicetree/bindings/arm/arm,coresight-etm.yaml create mode 100644 Documentation/devicetree/bindings/arm/arm,coresight-static-funnel.yaml create mode 100644 Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml create mode 100644 Documentation/devicetree/bindings/arm/arm,coresight-stm.yaml create mode 100644 Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml create mode 100644 Documentation/devicetree/bindings/arm/arm,coresight-tpiu.yaml rename Documentation/devicetree/bindings/arm/{ete.yaml => arm,embedded-trace-extension.yaml} (95%) rename Documentation/devicetree/bindings/arm/{trbe.yaml => arm,trace-buffer-extension.yaml} (94%) delete mode 100644 Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt delete mode 100644 Documentation/devicetree/bindings/arm/coresight.txt

2 years, 11 months

[PATCH v2] coresight: etm4x: add CPU hotplug support for probing

by Tamas Zsoldos

etm4x devices cannot be successfully probed when their CPU is offline. For example, when booting with maxcpus=n, ETM probing will fail on CPUs >n, and the probing won't be reattempted once the CPUs come online. This will leave those CPUs unable to make use of ETM. This change adds a mechanism to delay the probing if the corresponding CPU is offline, and to try it again when the CPU comes online. Signed-off-by: Tamas Zsoldos <tamas.zsoldos(a)arm.com> --- Changes from v1 (all suggested by Suzuki): 1. Expanded commit message. 2. The delayed probe now uses etm4_init_arg. 3. Reuses etm4_online_cpu() instead of installing own cpuhp callback. 4. Changed guard condition in etm4_remove_dev(). --- .../coresight/coresight-etm4x-core.c | 153 +++++++++++++----- 1 file changed, 113 insertions(+), 40 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c index 87299e99dabb..c39d9055b22c 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c @@ -66,10 +66,13 @@ static enum cpuhp_state hp_online; struct etm4_init_arg { unsigned int pid; - struct etmv4_drvdata *drvdata; + struct device *dev; struct csdev_access *csa; }; +static DEFINE_PER_CPU(struct etm4_init_arg *, delayed_probe); +static int etm4_probe_cpu(unsigned int cpu); + /* * Check if TRCSSPCICRn(i) is implemented for a given instance. * @@ -1071,7 +1074,7 @@ static void etm4_init_arch_data(void *info) struct csdev_access *csa; int i; - drvdata = init_arg->drvdata; + drvdata = dev_get_drvdata(init_arg->dev); csa = init_arg->csa; /* @@ -1514,7 +1517,7 @@ void etm4_config_trace_mode(struct etmv4_config *config) static int etm4_online_cpu(unsigned int cpu) { if (!etmdrvdata[cpu]) - return 0; + return etm4_probe_cpu(cpu); if (etmdrvdata[cpu]->boot_enable && !etmdrvdata[cpu]->sticky_enable) coresight_enable(etmdrvdata[cpu]->csdev); @@ -1890,48 +1893,20 @@ static void etm4_pm_clear(void) } } -static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid) +static int etm4_add_coresight_dev(struct etm4_init_arg *init_arg) { int ret; struct coresight_platform_data *pdata = NULL; - struct etmv4_drvdata *drvdata; + struct device *dev = init_arg->dev; + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev); struct coresight_desc desc = { 0 }; - struct etm4_init_arg init_arg = { 0 }; u8 major, minor; char *type_name; - drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL); if (!drvdata) - return -ENOMEM; - - dev_set_drvdata(dev, drvdata); - - if (pm_save_enable == PARAM_PM_SAVE_FIRMWARE) - pm_save_enable = coresight_loses_context_with_cpu(dev) ? - PARAM_PM_SAVE_SELF_HOSTED : PARAM_PM_SAVE_NEVER; - - if (pm_save_enable != PARAM_PM_SAVE_NEVER) { - drvdata->save_state = devm_kmalloc(dev, - sizeof(struct etmv4_save_state), GFP_KERNEL); - if (!drvdata->save_state) - return -ENOMEM; - } - - drvdata->base = base; - - spin_lock_init(&drvdata->spinlock); - - drvdata->cpu = coresight_get_cpu(dev); - if (drvdata->cpu < 0) - return drvdata->cpu; - - init_arg.drvdata = drvdata; - init_arg.csa = &desc.access; - init_arg.pid = etm_pid; + return -EINVAL; - if (smp_call_function_single(drvdata->cpu, - etm4_init_arch_data, &init_arg, 1)) - dev_err(dev, "ETM arch init failed\n"); + desc.access = *init_arg->csa; if (!drvdata->arch) return -EINVAL; @@ -2002,6 +1977,68 @@ static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid) return 0; } +static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid) +{ + struct etmv4_drvdata *drvdata; + struct csdev_access access = { 0 }; + struct etm4_init_arg init_arg = { 0 }; + struct etm4_init_arg *delayed; + + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL); + if (!drvdata) + return -ENOMEM; + + dev_set_drvdata(dev, drvdata); + + if (pm_save_enable == PARAM_PM_SAVE_FIRMWARE) + pm_save_enable = coresight_loses_context_with_cpu(dev) ? + PARAM_PM_SAVE_SELF_HOSTED : PARAM_PM_SAVE_NEVER; + + if (pm_save_enable != PARAM_PM_SAVE_NEVER) { + drvdata->save_state = devm_kmalloc(dev, + sizeof(struct etmv4_save_state), GFP_KERNEL); + if (!drvdata->save_state) + return -ENOMEM; + } + + drvdata->base = base; + + spin_lock_init(&drvdata->spinlock); + + drvdata->cpu = coresight_get_cpu(dev); + if (drvdata->cpu < 0) + return drvdata->cpu; + + init_arg.dev = dev; + init_arg.csa = &access; + init_arg.pid = etm_pid; + + /* + * Serialize against CPUHP callbacks to avoid race condition + * between the smp call and saving the delayed probe. + */ + cpus_read_lock(); + if (smp_call_function_single(drvdata->cpu, + etm4_init_arch_data, &init_arg, 1)) { + /* The CPU was offline, try again once it comes online. */ + delayed = devm_kmalloc(dev, sizeof(*delayed), GFP_KERNEL); + if (!delayed) { + cpus_read_unlock(); + return -ENOMEM; + } + + *delayed = init_arg; + + per_cpu(delayed_probe, drvdata->cpu) = delayed; + + cpus_read_unlock(); + return 0; + } + cpus_read_unlock(); + + return etm4_add_coresight_dev(&init_arg); +} + static int etm4_probe_amba(struct amba_device *adev, const struct amba_id *id) { void __iomem *base; @@ -2040,6 +2077,35 @@ static int etm4_probe_platform_dev(struct platform_device *pdev) return ret; } +static int etm4_probe_cpu(unsigned int cpu) +{ + int ret; + struct etm4_init_arg init_arg; + struct csdev_access access = { 0 }; + struct etm4_init_arg *iap = *this_cpu_ptr(&delayed_probe); + + if (!iap) + return 0; + + init_arg = *iap; + devm_kfree(init_arg.dev, iap); + *this_cpu_ptr(&delayed_probe) = NULL; + + ret = pm_runtime_resume_and_get(init_arg.dev); + if (ret < 0) { + dev_err(init_arg.dev, "Failed to get PM runtime!\n"); + return 0; + } + + init_arg.csa = &access; + etm4_init_arch_data(&init_arg); + + etm4_add_coresight_dev(&init_arg); + + pm_runtime_put(init_arg.dev); + return 0; +} + static struct amba_cs_uci_id uci_id_etm4[] = { { /* ETMv4 UCI data */ @@ -2054,16 +2120,20 @@ static void clear_etmdrvdata(void *info) int cpu = *(int *)info; etmdrvdata[cpu] = NULL; + per_cpu(delayed_probe, cpu) = NULL; } static int __exit etm4_remove_dev(struct etmv4_drvdata *drvdata) { - etm_perf_symlink(drvdata->csdev, false); + bool had_delayed_probe; /* * Taking hotplug lock here to avoid racing between etm4_remove_dev() * and CPU hotplug call backs. */ cpus_read_lock(); + + had_delayed_probe = per_cpu(delayed_probe, drvdata->cpu); + /* * The readers for etmdrvdata[] are CPU hotplug call backs * and PM notification call backs. Change etmdrvdata[i] on @@ -2071,12 +2141,15 @@ static int __exit etm4_remove_dev(struct etmv4_drvdata *drvdata) * inside one call back function. */ if (smp_call_function_single(drvdata->cpu, clear_etmdrvdata, &drvdata->cpu, 1)) - etmdrvdata[drvdata->cpu] = NULL; + clear_etmdrvdata(&drvdata->cpu); cpus_read_unlock(); - cscfg_unregister_csdev(drvdata->csdev); - coresight_unregister(drvdata->csdev); + if (!had_delayed_probe) { + etm_perf_symlink(drvdata->csdev, false); + cscfg_unregister_csdev(drvdata->csdev); + coresight_unregister(drvdata->csdev); + } return 0; } -- 2.17.1

2 years, 11 months

Re: [PATCH v6] coresight: etm4x: avoid build failure with unrolled loops

by Suzuki K Poulose

On 10/07/2022 20:13, Arnd Bergmann wrote: > On Sat, Jul 9, 2022 at 1:15 AM Nick Desaulniers <ndesaulniers(a)google.com> wrote: > >> ({ \ >> u64 __val; \ >> \ >> - if (__builtin_constant_p((offset))) \ >> + if (__is_constexpr((offset))) \ >> __val = read_etm4x_sysreg_const_offset((offset)); \ >> else \ >> __val = etm4x_sysreg_read((offset), true, (_64bit)); \ >> > > This is clearly better than the current version using > __builtin_constant_p(), but > I don't think it's safe in all cases, since there are expressions that > are constant > expressions to the compiler but are not valid input to the assembler. > > I would prefer to see this fixed differently, but doing this one first is also > fine with me: > > Acked-by: Arnd Bergmann <arnd(a)arndb.de> > > Arnd Thanks, I have queued this. Suzuki

2 years, 11 months

Patch series to add to and imporve tests for CoreSight

by carsten.haitzler＠foss.arm.com

This improves how perf test handles finding shell scripts to run as part of the testing allowing sub-directories, skipping files that are not intentional shell script tests and then adds a set of tests that improve what we cover for Arm CoreSight testing. The goal of these tests is to expand the scenarios and data traced and examined to track quality of trace data and improvements to that over time. Eventually it'd be neater to break up the current Arm CoreSight tests into smaller focused tests that share the same infrastructure, but this here would be a first step.

2 years, 11 months

Re: [PATCH 14/14] perf test: Add relevant documentation about CoreSight testing

by Carsten Haitzler

On 7/2/22 04:02, Bagas Sanjaya wrote: > On Fri, Jul 01, 2022 at 01:08:03PM +0100, carsten.haitzler(a)foss.arm.com wrote: >> From: "Carsten Haitzler (Rasterman)" <raster(a)rasterman.com> >> > > Hi Carsten, > > This doc patch can be improved, see below. I'll look at addressing the below - with some exceptions as they are not what you think they are. >> This adds/improves documentation helping people get started with >> CoreSight and perf as well as describing the testing and how it works. >> > > Use imperative mood instead of descriptive one for patch description. > >> Signed-off-by: Carsten Haitzler <carsten.haitzler(a)arm.com> >> --- >> .../trace/coresight/coresight-perf.rst | 160 ++++++++++++++++++ >> tools/perf/Documentation/arm-coresight.txt | 5 + >> 2 files changed, 165 insertions(+) >> create mode 100644 Documentation/trace/coresight/coresight-perf.rst >> create mode 100644 tools/perf/Documentation/arm-coresight.txt >> >> diff --git a/Documentation/trace/coresight/coresight-perf.rst b/Documentation/trace/coresight/coresight-perf.rst >> new file mode 100644 >> index 000000000000..de25082447dd >> --- /dev/null >> +++ b/Documentation/trace/coresight/coresight-perf.rst >> @@ -0,0 +1,160 @@ >> +.. SPDX-License-Identifier: GPL-2.0 >> + >> +================ >> +CoreSight - Perf >> +================ >> + >> + :Author: Carsten Haitzler <carsten.haitzler(a)arm.com> >> + :Date: June 29th, 2022 >> + >> +Perf is able to locally access CoreSight trace data and store it to the >> +output perf data files. This data can then be later decoded to give the >> +instructions that were traced for debugging or profiling purposes. You >> +can log such data with a perf record command like: >> + >> + perf record -e cs_etm//u testbinary >> + > > Use literal code block. > >> +This would run some test binary (testbinary) until it exits and record >> +a perf.data trace file. That file would have AUX sections if CoreSight >> +is working correctly. You can dump the content of this file as >> +readable text with a command like: >> + >> + perf report --stdio --dump -i perf.data >> + > > Same as above. > >> +You should find some sections of this file have AUX data blocks like: >> + >> + 0x1e78 [0x30]: PERF_RECORD_AUXTRACE size: 0x11dd0 offset: 0 ref: 0x1b614fc1061b0ad1 idx: 0 tid: 531230 cpu: -1 >> + >> + . ... CoreSight ETM Trace data: size 73168 bytes >> + Idx:0; ID:10; I_ASYNC : Alignment Synchronisation. >> + Idx:12; ID:10; I_TRACE_INFO : Trace Info.; INFO=0x0 { CC.0 } >> + Idx:17; ID:10; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0x0000000000000000; >> + Idx:26; ID:10; I_TRACE_ON : Trace On. >> + Idx:27; ID:10; I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, IS0.; Addr=0x0000FFFFB6069140; Ctxt: AArch64,EL0, NS; >> + Idx:38; ID:10; I_ATOM_F6 : Atom format 6.; EEEEEEEEEEEEEEEEEEEEEEEE >> + Idx:39; ID:10; I_ATOM_F6 : Atom format 6.; EEEEEEEEEEEEEEEEEEEEEEEE >> + Idx:40; ID:10; I_ATOM_F6 : Atom format 6.; EEEEEEEEEEEEEEEEEEEEEEEE >> + Idx:41; ID:10; I_ATOM_F6 : Atom format 6.; EEEEEEEEEEEN >> + ... >> + > > Here too. > >> +If you see these above, then your system is tracing CoreSight data >> +correctly. >> + >> +To compile perf with CoreSight support in the tools/perf directory do >> + >> + make CORESIGHT=1 >> + > > Here too again. > >> +This requires OpenCSD to build. You may install distribution packages >> +for the support such as libopencsd and libopencsd-dev or download it >> +and build yourself. Upstream OpenCSD is located at: >> + >> + https://github.com/Linaro/OpenCSD >> + >> +For complete information on building perf with CoreSight support and >> +more extensive usage look at: >> + >> + https://github.com/Linaro/OpenCSD/blob/master/HOWTO.md >> + >> + >> +Kernel CoreSight Support >> +------------------------ >> + >> +You will also want CoreSight support enabled in your kernel config. >> +Ensure it is enabled with: >> + >> + CONFIG_CORESIGHT=y >> + >> +There are various other CoreSight options you probably also want >> +enabled like: >> + >> + CONFIG_CORESIGHT_LINKS_AND_SINKS=y >> + CONFIG_CORESIGHT_LINK_AND_SINK_TMC=y >> + CONFIG_CORESIGHT_CATU=y >> + CONFIG_CORESIGHT_SINK_TPIU=y >> + CONFIG_CORESIGHT_SINK_ETBV10=y >> + CONFIG_CORESIGHT_SOURCE_ETM4X=y >> + CONFIG_CORESIGHT_STM=y >> + CONFIG_CORESIGHT_CPU_DEBUG=y >> + CONFIG_CORESIGHT_CTI=y >> + CONFIG_CORESIGHT_CTI_INTEGRATION_REGS=y >> + > > Same as above again. > >> +Please refer to the kernel configuration help for more information. >> + >> +Perf test - Verify kernel and userspace perf CoreSight work >> +----------------------------------------------------------- >> + >> +When you run perf test, it will do a lot of self tests. Some of those >> +tests will cover CoreSight (only if enabled and on ARM64). You >> +generally would run perf test from the tools/perf directory in the >> +kernel tree. Some tests will check some internal perf support like: >> + >> + Check Arm CoreSight trace data recording and synthesized samples >> + Check Arm SPE trace data recording and synthesized samples >> + > > Use bullet lists. Actually this would be a code block - it is literally the stdout from perf test (just 2 lines of it for those tests). >> +Some others will actually use perf record and some test binaries that >> +are in tests/shell/coresight and will collect traces to ensure a >> +minimum level of functionality is met. The scripts that launch these >> +tests are in the same directory. These will all look like: >> + >> + CoreSight / ASM Pure Loop >> + CoreSight / Memcpy 16k 10 Threads >> + CoreSight / Thread Loop 10 Threads - Check TID >> + ... >> + > > Same as above. This too - a code block. >> +These perf record tests will not run if the tool binaries do not exist >> +in tests/shell/coresight/*/ and will be skipped. If you do not have >> +CoreSight support in hardware then either do not build perf with >> +CoreSight support or remove these binaries in order to not have these >> +tests fail and have them skip instead. >> + >> +These tests will log historical results in the current working >> +directory (e.g. tools/perf) and will be named stats-*.csv like: >> + >> + stats-asm_pure_loop-out.csv >> + stats-memcpy_thread-16k_10.csv >> + ... >> + > > These above causes htmldocs warning (unescaped wildcard), so I have to apply > the fixup: > > ---- >8 ---- > > diff --git a/Documentation/trace/coresight/coresight-perf.rst b/Documentation/trace/coresight/coresight-perf.rst > index de25082447dd50..a25fcda5c37c55 100644 > --- a/Documentation/trace/coresight/coresight-perf.rst > +++ b/Documentation/trace/coresight/coresight-perf.rst > @@ -102,13 +102,13 @@ tests are in the same directory. These will all look like: > ... > > These perf record tests will not run if the tool binaries do not exist > -in tests/shell/coresight/*/ and will be skipped. If you do not have > +in tests/shell/coresight/\*/ and will be skipped. If you do not have > CoreSight support in hardware then either do not build perf with > CoreSight support or remove these binaries in order to not have these > tests fail and have them skip instead. > > These tests will log historical results in the current working > -directory (e.g. tools/perf) and will be named stats-*.csv like: > +directory (e.g. tools/perf) and will be named stats-\*.csv like: > > stats-asm_pure_loop-out.csv > stats-memcpy_thread-16k_10.csv > > ---- >8 ---- > > Also, the output list above could be inside code block (since these > are output). Yup. >> +These statistic files log some aspects of the AUX data sections in >> +the perf data output counting some numbers of certain encodings (a >> +good way to know that it's working in a very simple way). One problem >> +with CoreSight is that given a large enough amount of data needing to >> +be logged, some of it can be lost due to the processor not waking up >> +in time to read out all the data from buffers etc.. You will notice >> +that the amount of data collected can vary a lot per run of perf test. >> +If you wish to see how this changes over time, simply run perf test >> +multiple times and all these csv files will have more and more data >> +appended to it that you can later examine, graph and otherwise use to >> +figure out if things have become worse or better. >> + >> +This means sometimes these tests fail as they don't capture all the >> +data needed. This is about tracking quality and amount of data >> +produced over time and to see when changes to the Linux kernel improve >> +quality of traces. >> + >> +Be aware that some of these tests take quite a while to run, specifically >> +in processing the perf data file and dumping contents to then examine what >> +is inside. >> + >> +You can change where these csv logs are stored by setting the >> +PERF_TEST_CORESIGHT_STATDIR environment variable before running perf >> +test like: >> + >> + export PERF_TEST_CORESIGHT_STATDIR=/var/tmp >> + perf test >> + >> +They will also store resulting perf output data in the current >> +directory for later inspection like: >> + >> + perf-asm_pure_loop-out.data >> + perf-memcpy_thread-16k_10.data >> + ... >> + >> +You can alter where the perf data files are stored by setting the >> +PERF_TEST_CORESIGHT_DATADIR environment variable such as: >> + >> + PERF_TEST_CORESIGHT_DATADIR=/var/tmp >> + perf test >> + > > Use code block. > >> +You may wish to set these above environment variables if you whish to >> +keep the output of tests outside of the current working directory for >> +longer term storage and examination. >> diff --git a/tools/perf/Documentation/arm-coresight.txt b/tools/perf/Documentation/arm-coresight.txt >> new file mode 100644 >> index 000000000000..f94743a4d161 >> --- /dev/null >> +++ b/tools/perf/Documentation/arm-coresight.txt >> @@ -0,0 +1,5 @@ >> +Arm CoreSight Support >> +===================== >> + >> +Please see docuentation in the central CoreSight location in the >> +kernel tree under Documentation/trace/coresight > > s/ducuentation/documentation/ > > So here's the improv: > > ---- >8 ---- > > diff --git a/Documentation/trace/coresight/coresight-perf.rst b/Documentation/trace/coresight/coresight-perf.rst > index a25fcda5c37c55..0dd4689a699ecd 100644 > --- a/Documentation/trace/coresight/coresight-perf.rst > +++ b/Documentation/trace/coresight/coresight-perf.rst > @@ -10,37 +10,37 @@ CoreSight - Perf > Perf is able to locally access CoreSight trace data and store it to the > output perf data files. This data can then be later decoded to give the > instructions that were traced for debugging or profiling purposes. You > -can log such data with a perf record command like: > +can log such data with a perf record command like:: > > - perf record -e cs_etm//u testbinary > + perf record -e cs_etm//u testbinary > > This would run some test binary (testbinary) until it exits and record > a perf.data trace file. That file would have AUX sections if CoreSight > is working correctly. You can dump the content of this file as > -readable text with a command like: > +readable text with a command like:: > > - perf report --stdio --dump -i perf.data > + perf report --stdio --dump -i perf.data > > -You should find some sections of this file have AUX data blocks like: > +You should find some sections of this file have AUX data blocks like:: > > - 0x1e78 [0x30]: PERF_RECORD_AUXTRACE size: 0x11dd0 offset: 0 ref: 0x1b614fc1061b0ad1 idx: 0 tid: 531230 cpu: -1 > + 0x1e78 [0x30]: PERF_RECORD_AUXTRACE size: 0x11dd0 offset: 0 ref: 0x1b614fc1061b0ad1 idx: 0 tid: 531230 cpu: -1 > > - . ... CoreSight ETM Trace data: size 73168 bytes > - Idx:0; ID:10; I_ASYNC : Alignment Synchronisation. > - Idx:12; ID:10; I_TRACE_INFO : Trace Info.; INFO=0x0 { CC.0 } > - Idx:17; ID:10; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0x0000000000000000; > - Idx:26; ID:10; I_TRACE_ON : Trace On. > - Idx:27; ID:10; I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, IS0.; Addr=0x0000FFFFB6069140; Ctxt: AArch64,EL0, NS; > - Idx:38; ID:10; I_ATOM_F6 : Atom format 6.; EEEEEEEEEEEEEEEEEEEEEEEE > - Idx:39; ID:10; I_ATOM_F6 : Atom format 6.; EEEEEEEEEEEEEEEEEEEEEEEE > - Idx:40; ID:10; I_ATOM_F6 : Atom format 6.; EEEEEEEEEEEEEEEEEEEEEEEE > - Idx:41; ID:10; I_ATOM_F6 : Atom format 6.; EEEEEEEEEEEN > - ... > + . ... CoreSight ETM Trace data: size 73168 bytes > + Idx:0; ID:10; I_ASYNC : Alignment Synchronisation. > + Idx:12; ID:10; I_TRACE_INFO : Trace Info.; INFO=0x0 { CC.0 } > + Idx:17; ID:10; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0x0000000000000000; > + Idx:26; ID:10; I_TRACE_ON : Trace On. > + Idx:27; ID:10; I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, IS0.; Addr=0x0000FFFFB6069140; Ctxt: AArch64,EL0, NS; > + Idx:38; ID:10; I_ATOM_F6 : Atom format 6.; EEEEEEEEEEEEEEEEEEEEEEEE > + Idx:39; ID:10; I_ATOM_F6 : Atom format 6.; EEEEEEEEEEEEEEEEEEEEEEEE > + Idx:40; ID:10; I_ATOM_F6 : Atom format 6.; EEEEEEEEEEEEEEEEEEEEEEEE > + Idx:41; ID:10; I_ATOM_F6 : Atom format 6.; EEEEEEEEEEEN > + ... > > If you see these above, then your system is tracing CoreSight data > correctly. > > -To compile perf with CoreSight support in the tools/perf directory do > +To compile perf with CoreSight support in the tools/perf directory do:: > > make CORESIGHT=1 > > @@ -60,23 +60,23 @@ Kernel CoreSight Support > ------------------------ > > You will also want CoreSight support enabled in your kernel config. > -Ensure it is enabled with: > +Ensure it is enabled with:: > > - CONFIG_CORESIGHT=y > + CONFIG_CORESIGHT=y > > There are various other CoreSight options you probably also want > -enabled like: > +enabled like:: > > - CONFIG_CORESIGHT_LINKS_AND_SINKS=y > - CONFIG_CORESIGHT_LINK_AND_SINK_TMC=y > - CONFIG_CORESIGHT_CATU=y > - CONFIG_CORESIGHT_SINK_TPIU=y > - CONFIG_CORESIGHT_SINK_ETBV10=y > - CONFIG_CORESIGHT_SOURCE_ETM4X=y > - CONFIG_CORESIGHT_STM=y > - CONFIG_CORESIGHT_CPU_DEBUG=y > - CONFIG_CORESIGHT_CTI=y > - CONFIG_CORESIGHT_CTI_INTEGRATION_REGS=y > + CONFIG_CORESIGHT_LINKS_AND_SINKS=y > + CONFIG_CORESIGHT_LINK_AND_SINK_TMC=y > + CONFIG_CORESIGHT_CATU=y > + CONFIG_CORESIGHT_SINK_TPIU=y > + CONFIG_CORESIGHT_SINK_ETBV10=y > + CONFIG_CORESIGHT_SOURCE_ETM4X=y > + CONFIG_CORESIGHT_STM=y > + CONFIG_CORESIGHT_CPU_DEBUG=y > + CONFIG_CORESIGHT_CTI=y > + CONFIG_CORESIGHT_CTI_INTEGRATION_REGS=y > > Please refer to the kernel configuration help for more information. > > @@ -88,18 +88,18 @@ tests will cover CoreSight (only if enabled and on ARM64). You > generally would run perf test from the tools/perf directory in the > kernel tree. Some tests will check some internal perf support like: > > - Check Arm CoreSight trace data recording and synthesized samples > - Check Arm SPE trace data recording and synthesized samples > +* Check Arm CoreSight trace data recording and synthesized samples > +* Check Arm SPE trace data recording and synthesized samples > > Some others will actually use perf record and some test binaries that > are in tests/shell/coresight and will collect traces to ensure a > minimum level of functionality is met. The scripts that launch these > tests are in the same directory. These will all look like: > > - CoreSight / ASM Pure Loop > - CoreSight / Memcpy 16k 10 Threads > - CoreSight / Thread Loop 10 Threads - Check TID > - ... > +* CoreSight / ASM Pure Loop > +* CoreSight / Memcpy 16k 10 Threads > +* CoreSight / Thread Loop 10 Threads - Check TID > +* etc. > > These perf record tests will not run if the tool binaries do not exist > in tests/shell/coresight/\*/ and will be skipped. If you do not have > @@ -108,11 +108,11 @@ CoreSight support or remove these binaries in order to not have these > tests fail and have them skip instead. > > These tests will log historical results in the current working > -directory (e.g. tools/perf) and will be named stats-\*.csv like: > +directory (e.g. tools/perf) and will be named stats-\*.csv like:: > > - stats-asm_pure_loop-out.csv > - stats-memcpy_thread-16k_10.csv > - ... > + stats-asm_pure_loop-out.csv > + stats-memcpy_thread-16k_10.csv > + ... > > These statistic files log some aspects of the AUX data sections in > the perf data output counting some numbers of certain encodings (a > @@ -137,23 +137,23 @@ is inside. > > You can change where these csv logs are stored by setting the > PERF_TEST_CORESIGHT_STATDIR environment variable before running perf > -test like: > +test like:: > > - export PERF_TEST_CORESIGHT_STATDIR=/var/tmp > - perf test > + export PERF_TEST_CORESIGHT_STATDIR=/var/tmp > + perf test > > They will also store resulting perf output data in the current > -directory for later inspection like: > +directory for later inspection like:: > > - perf-asm_pure_loop-out.data > - perf-memcpy_thread-16k_10.data > - ... > + perf-asm_pure_loop-out.data > + perf-memcpy_thread-16k_10.data > + ... > > You can alter where the perf data files are stored by setting the > -PERF_TEST_CORESIGHT_DATADIR environment variable such as: > +PERF_TEST_CORESIGHT_DATADIR environment variable such as:: > > - PERF_TEST_CORESIGHT_DATADIR=/var/tmp > - perf test > + PERF_TEST_CORESIGHT_DATADIR=/var/tmp > + perf test > > You may wish to set these above environment variables if you whish to > keep the output of tests outside of the current working directory for > diff --git a/tools/perf/Documentation/arm-coresight.txt b/tools/perf/Documentation/arm-coresight.txt > index f94743a4d161f2..c117fc50a2a956 100644 > --- a/tools/perf/Documentation/arm-coresight.txt > +++ b/tools/perf/Documentation/arm-coresight.txt > @@ -1,5 +1,5 @@ > Arm CoreSight Support > ===================== > > -Please see docuentation in the central CoreSight location in the > -kernel tree under Documentation/trace/coresight > +For full documentation, see Documentation/trace/coresight/coresight-perf.rst > +in the kernel tree. > > ---- >8 ---- > > Note: since this is documentation patch, don't forget to Cc linux-doc list. > I add it for you. I'll split this out to a separate stand-alone patch from this series. I put docs in the place I was told to by the perf coresight maintainers, but that now complicates everyone to send the patch series to and so only the docs are relevant to the doc mailing list, so I'll split it off.

2 years, 11 months

Re: [PATCH] coresight: etm4x: add CPU hotplug support for probing

by Suzuki K Poulose

Hi Tamas Thanks for the patch. I have tested this on my Juno board and it works fine. I have some comments inline. On 16/06/2022 16:18, Tamas Zsoldos wrote: > etm4x devices cannot be successfully probed when their CPU is offline. > This adds a mechanism to delay the probing in this case and try again > once the CPU is brought online. It may be worth elaborating this a bit. e.g, "For e.g., if the system is booted with maxcpus=n, the ETM won't be probed on CPUs n+1, even when the CPUs are brought up online later" , > > Signed-off-by: Tamas Zsoldos <tamas.zsoldos(a)arm.com> > --- > .../coresight/coresight-etm4x-core.c | 195 ++++++++++++++---- > 1 file changed, 155 insertions(+), 40 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c > index 7f416a12000e..f0bff08e9de9 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > @@ -70,6 +70,14 @@ struct etm4_init_arg { > struct csdev_access *csa; > }; > > +struct etm4_delayed_probe { > + u32 etm_pid; > + struct device *dev; > +}; > + > +static DEFINE_PER_CPU(struct etm4_delayed_probe *, delayed_probe); > +static enum cpuhp_state hp_probe; I am wondering if we can reuse the existing hotplug notifier ? See more on this below. > + > /* > * Check if TRCSSPCICRn(i) is implemented for a given instance. > * > @@ -1938,48 +1946,20 @@ static void etm4_pm_clear(void) > } > } > > -static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid) > +static int etm4_add_coresight_dev(struct device *dev, > + struct csdev_access *access) Could this be : etm4_add_coresight_dev(struct etm4_init_arg *init_arg) That provides us with "access". Also if replace init_arg.drvdata field with init_arg.dev we can use that for etm4_init_arch_data() and etm4_add_coresight_dev. we can get to drvdata from the dev via, dev_get_drvdata(dev). > { > int ret; > struct coresight_platform_data *pdata = NULL; > - struct etmv4_drvdata *drvdata; > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev); > struct coresight_desc desc = { 0 }; > - struct etm4_init_arg init_arg = { 0 }; > u8 major, minor; > char *type_name; > > - drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL); > if (!drvdata) > - return -ENOMEM; > - > - dev_set_drvdata(dev, drvdata); > - > - if (pm_save_enable == PARAM_PM_SAVE_FIRMWARE) > - pm_save_enable = coresight_loses_context_with_cpu(dev) ? > - PARAM_PM_SAVE_SELF_HOSTED : PARAM_PM_SAVE_NEVER; > - > - if (pm_save_enable != PARAM_PM_SAVE_NEVER) { > - drvdata->save_state = devm_kmalloc(dev, > - sizeof(struct etmv4_save_state), GFP_KERNEL); > - if (!drvdata->save_state) > - return -ENOMEM; > - } > - > - drvdata->base = base; > - > - spin_lock_init(&drvdata->spinlock); > - > - drvdata->cpu = coresight_get_cpu(dev); > - if (drvdata->cpu < 0) > - return drvdata->cpu; > - > - init_arg.drvdata = drvdata; > - init_arg.csa = &desc.access; > - init_arg.pid = etm_pid; > + return -EINVAL; > > - if (smp_call_function_single(drvdata->cpu, > - etm4_init_arch_data, &init_arg, 1)) > - dev_err(dev, "ETM arch init failed\n"); > + desc.access = *access; > > if (!drvdata->arch) > return -EINVAL; > @@ -2050,6 +2030,69 @@ static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid) > return 0; > } > > +static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid) > +{ > + struct etmv4_drvdata *drvdata; > + struct csdev_access access = { 0 }; > + struct etm4_init_arg init_arg = { 0 }; > + struct etm4_delayed_probe *delayed; > + > + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL); > + if (!drvdata) > + return -ENOMEM; > + > + dev_set_drvdata(dev, drvdata); > + > + if (pm_save_enable == PARAM_PM_SAVE_FIRMWARE) > + pm_save_enable = coresight_loses_context_with_cpu(dev) ? > + PARAM_PM_SAVE_SELF_HOSTED : PARAM_PM_SAVE_NEVER; > + > + if (pm_save_enable != PARAM_PM_SAVE_NEVER) { > + drvdata->save_state = devm_kmalloc(dev, > + sizeof(struct etmv4_save_state), GFP_KERNEL); > + if (!drvdata->save_state) > + return -ENOMEM; > + } > + > + drvdata->base = base; > + > + spin_lock_init(&drvdata->spinlock); > + > + drvdata->cpu = coresight_get_cpu(dev); > + if (drvdata->cpu < 0) > + return drvdata->cpu; > + > + init_arg.drvdata = drvdata; > + init_arg.csa = &access; > + init_arg.pid = etm_pid; > + > + /* > + * Serialize against CPUHP callbacks to avoid race condition > + * between the smp call and saving the delayed probe. > + */ > + cpus_read_lock(); > + if (smp_call_function_single(drvdata->cpu, > + etm4_init_arch_data, &init_arg, 1)) { > + /* The CPU was offline, try again once it comes online. */ > + delayed = devm_kmalloc(dev, sizeof(*delayed), GFP_KERNEL); > + if (!delayed) { > + cpus_read_unlock(); > + return -ENOMEM; > + } > + > + delayed->etm_pid = etm_pid; > + delayed->dev = dev; > + > + per_cpu(delayed_probe, drvdata->cpu) = delayed; > + > + cpus_read_unlock(); > + return 0; > + } > + cpus_read_unlock(); > + > + return etm4_add_coresight_dev(dev, &access); > +} > + > static int etm4_probe_amba(struct amba_device *adev, const struct amba_id *id) > { > void __iomem *base; > @@ -2088,6 +2131,64 @@ static int etm4_probe_platform_dev(struct platform_device *pdev) > return ret; > } > > +static int etm4_probe_cpu(unsigned int cpu) > +{ > + int ret; > + struct etm4_delayed_probe di; > + struct csdev_access access = { 0 }; > + struct etm4_init_arg init_arg; > + struct etm4_delayed_probe *dp = *this_cpu_ptr(&delayed_probe); This could be called from the existing etm4_starting_cpu() ? static int etm4_starting_cpu(unsigned int cpu) { if (!etmdrvdata[cpu]) - return 0; + return etm4_probe_cpu(cpu); spin_lock(&etmdrvdata[cpu]->spinlock); if (!etmdrvdata[cpu]->os_unlock) etm4_os_unlock(etmdrvdata[cpu]); if (local_read(&etmdrvdata[cpu]->mode)) etm4_enable_hw(etmdrvdata[cpu]); spin_unlock(&etmdrvdata[cpu]->spinlock); } > + > + if (!dp) > + return 0; > + > + di = *dp; > + devm_kfree(di.dev, dp); > + *this_cpu_ptr(&delayed_probe) = NULL; > + > + ret = pm_runtime_resume_and_get(di.dev); > + if (ret < 0) { > + dev_err(di.dev, "Failed to get PM runtime!\n"); > + return 0; > + } > + > + init_arg.drvdata = dev_get_drvdata(di.dev); > + if (!init_arg.drvdata) > + return 0; > + > + init_arg.csa = &access; > + init_arg.pid = di.etm_pid; > + etm4_init_arch_data(&init_arg); > + > + etm4_add_coresight_dev(di.dev, &access); > + > + pm_runtime_put(di.dev); > + return 0; > +} > + > +static int etm4_setup_cpuhp_probe(void) > +{ > + int ret; > + > + ret = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN, > + "arm/coresight4:delayed_probe", > + etm4_probe_cpu, NULL); > + > + if (ret > 0) { > + hp_probe = ret; > + return 0; > + } > + return ret; > +} > + > +static void etm4_remove_cpuhp_probe(void) > +{ > + if (hp_probe) > + cpuhp_remove_state_nocalls(hp_probe); > + > + hp_probe = 0; > +} > + And we could get rid of the above ^^ > static struct amba_cs_uci_id uci_id_etm4[] = { > { > /* ETMv4 UCI data */ > @@ -2102,16 +2203,20 @@ static void clear_etmdrvdata(void *info) > int cpu = *(int *)info; > > etmdrvdata[cpu] = NULL; > + per_cpu(delayed_probe, cpu) = NULL; > } > > static int __exit etm4_remove_dev(struct etmv4_drvdata *drvdata) > { > - etm_perf_symlink(drvdata->csdev, false); > + bool had_dev; > /* > * Taking hotplug lock here to avoid racing between etm4_remove_dev() > * and CPU hotplug call backs. > */ > cpus_read_lock(); > + > + had_dev = etmdrvdata[drvdata->cpu]; > + Is this ever false ? Why do we need this change ? How does this patch affect the tear down ? Suzuki

2 years, 12 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight