CoreSight January 2019

coresight@lists.linaro.org

10 participants
13 discussions

[PATCH v7 0/8] perf cs-etm: Add support for sample flags

by Leo Yan

This patch seris adds support for sample flags so can facilitate perf to print sample flags for branch instruction. Patch 0001 is used to save last branch information in packet structure, this includes instruction type, subtype and condition flag to help making decision for which branch instruction it is. It passes related information from decoder layer to cs-etm.c, so we use cs-etm.c as a central place to set sample flags. Patch 0002 is used to set sample flags for instruction range packet. Patch 0003 is used to set sample flags for trace discontinuity packet. Patches 0004/0005/0006 are preparation for exception packet handling: Patch 0004 addes exception number in packet; pacth 0005/0006 is to use traceID/metadata tuple to access metadata pointer based on traceID, this can help decide if the CPU is connected with ETMv3 or ETMv4, ETMv3 and ETMv4 have totally different definition for exception numbers. Patch 0007 sets sample flags for exception packet; patch 0008 support sample flags for exception return packet. This patch set is applied on the acme's perf core branch with the latest commit bdec77cfe58d ("Merge remote-tracking branch 'tip/perf/urgent' into perf/core"). This patch set has been verified for x86 and arm64 perf building and also is verified with below command: Before: # perf script -F,-time,+flags -k vmlinux [...] main 6650 [001] 1 branches: f7b08490 lib_loop_test+0xc (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: f7b084a2 lib_loop_test+0x1e (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: f7b084a2 lib_loop_test+0x1e (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: f7b084a2 lib_loop_test+0x1e (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: f7b084a2 lib_loop_test+0x1e (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: f7b084a2 lib_loop_test+0x1e (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: f7b084b0 lib_loop_test+0x2c (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: 6b65a8 main+0x1c (/root/coresight_test/main) main 6650 [001] 1 branches: 6b6448 printf@plt+0x8 (/root/coresight_test/main) main 6650 [001] 1 branches: 6b642c _init+0x18 (/root/coresight_test/main) main 6650 [001] 1 branches: f7b2d23c [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: f7b2906e [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: f7b2559a [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: f7b2559a [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: f7b2559a [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: f7b2559a [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: f7b2559a [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: f7b255ee [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: f7b25634 [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) [...] After: # perf script -F,-time,+flags -k vmlinux [...] main 6650 [001] 1 branches: jmp f7b08490 lib_loop_test+0xc (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: jcc f7b084a2 lib_loop_test+0x1e (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: jcc f7b084a2 lib_loop_test+0x1e (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: jcc f7b084a2 lib_loop_test+0x1e (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: jcc f7b084a2 lib_loop_test+0x1e (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: jcc f7b084a2 lib_loop_test+0x1e (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: return f7b084b0 lib_loop_test+0x2c (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: call 6b65a8 main+0x1c (/root/coresight_test/main) main 6650 [001] 1 branches: return 6b6448 printf@plt+0x8 (/root/coresight_test/main) main 6650 [001] 1 branches: return 6b642c _init+0x18 (/root/coresight_test/main) main 6650 [001] 1 branches: call f7b2d23c [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: call f7b2906e [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: jcc f7b2559a [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: jcc f7b2559a [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: jcc f7b2559a [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: jcc f7b2559a [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: jcc f7b2559a [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: jmp f7b255ee [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: call f7b25634 [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) [...] Changes from v6: * Addressed Mathieu's suggestion for patch 0005, refined its commit log and comment and fixed cs_etm__get_cpu() definitions in header file; also tested with perf for Arm and x86 buildings. * Added Mathieu's review tags. Changes from v5: * Addressed Rob's suggestion to add specification info for exception number encoding; * Added Rob's review tag in patch 0007. Changes from v4: * Fixed typos in comments, and removed redundant info from commit log; * Addressed Mathieu's suggestion to add helper functions for metadata fields (CS_ETM_CPU and CS_ETM_MAGIC) accessing; * Addressed Mathieu's suggestion to include headers with alphabetical order. Changes from v3: * Fixed typos in commit logs; * Rearranged fields in cs_etm_packet by grouping with same variable types; * Fixed ETMv4 exception number which pointed by Mike; * Fixed ETMv4 SVC / SMC / HVC in the same CALL, by checking svc instruction to distinguish them; * Refine ETMv4 return exception packet handling. Changes from v2: * Addressed Mathieu's suggestion to split one big patch to 3 small patches for setting sample flags, one is for instruction range packet, one is for discontinuity packet and one is for exception packet. * Added supporting for ETMv3 exception packet. * Followed Mathieu's suggestion to move all sample flags handling from decoder layer to cs-etm.c, thus it has enough info to set flags based on trace context in single place. Changes from v1: * Moved exception packets handling patches into patch series 'perf cs-etm: Correct packets handling'. * Added sample flags fixing up for TRACE_OFF packet. * Created a new function which is used to maintain flags fixing up. Leo Yan (8): perf cs-etm: Add last instruction information in packet perf cs-etm: Set sample flags for instruction range packet perf cs-etm: Set sample flags for trace discontinuity perf cs-etm: Add exception number in exception packet perf cs-etm: Change tuple from traceID-CPU# to traceID-metadata perf cs-etm: Add traceID in packet perf cs-etm: Set sample flags for exception packet perf cs-etm: Set sample flags for exception return packet .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 41 +- .../perf/util/cs-etm-decoder/cs-etm-decoder.h | 6 + tools/perf/util/cs-etm.c | 394 +++++++++++++++++- tools/perf/util/cs-etm.h | 53 ++- 4 files changed, 476 insertions(+), 18 deletions(-) -- 2.17.1

6 years

[PATCH v4 0/3] Update AMBA driver for enhanced component ID spec.

by Mike Leach

The latest ARM CoreSight specification updates the component identification requirements for all components attached to an AMBA bus. (ARM IHI 0029E) This specification defines bits 15:12 in the ComponentID (CID) value as the device class. Identification requirements now depend on this class. Class 0xF: Traditional components identified by Peripheral ID (PID) only. Class 0x9: CoreSight components may be identified by a Universal Component Identifier (UCI) consisting of the PID plus CoreSight DevType and DevArch values. Current and future ARM CoreSight IP will now use the same PID for components on the same function - e.g. the ETM, CTI, PMU and Debug elements associated with a core. The first core to use this UCI method is the A35, which currently has binding entries in the ETMv4 driver. This patchset prepares for the addition of the upcoming CTI driver, which will need to correctly bind with A35, and reported new devices that share PID for multiple components, while overcoming the limitation of binding by PID alone, which cannot now work. Patch 0001: Adds new UCI data structure and uses it with existing drivers that use private data field in amba_id. This fixes issue from prior set. Patch 0002: Implements the UCI matching code in the AMBA core code. Patch 0003: Update ETMv4 driver to use UCI as appropriate. Thanks Mike Tested on DB410, Juno; kernel 5.0-rc4 Changes since v3: Fix UCI structure to allow CoreSight drivers to set private data. This fixes bug where none-UCI private data would cause a driver binding mismatch. (e.g. STM). Add CS_AMBA macros to simplify building AMBA ID tables, with and without UCI settings. Changes since v2: Simplification of amba_cs_uci_id_match(). Fix CID class bitfield comments. Dropped RFC tag on patchset. Mike Leach (3): drivers: amba: Updates to component identification for driver matching. drivers: amba: Update component matching to use the CoreSight UCI values. coresight: etmv4: Update ID register table to add UCI support drivers/amba/bus.c | 45 +++++++++++++++---- drivers/hwtracing/coresight/coresight-etm3x.c | 44 ++++++------------ drivers/hwtracing/coresight/coresight-etm4x.c | 21 +++++---- drivers/hwtracing/coresight/coresight-priv.h | 40 +++++++++++++++++ drivers/hwtracing/coresight/coresight-stm.c | 14 ++---- drivers/hwtracing/coresight/coresight-tmc.c | 30 ++++--------- include/linux/amba/bus.h | 39 ++++++++++++++++ 7 files changed, 153 insertions(+), 80 deletions(-) -- 2.19.1

6 years

[RESEND PATCH v3 0/2] Update AMBA driver for enhanced component ID spec.

by Mike Leach

The latest ARM CoreSight specification updates the component identification requirements for all components attached to an AMBA bus. (ARM IHI 0029E) This specification defines bits 15:12 in the ComponentID (CID) value as the device class. Identification requirements now depend on this class. Class 0xF: Traditional components identified by Peripheral ID (PID) only. Class 0x9: CoreSight components may be identified by a Universal Component Identifier (UCI) consisting of the PID plus CoreSight DevType and DevArch values. Current and future ARM CoreSight IP will now use the same PID for components on the same function - e.g. the ETM, CTI, PMU and Debug elements associated with a core. The first core to use this UCI method is the A35, which currently has binding entries in the ETMv4 driver. This patchset prepares for the addition of the upcoming CTI driver, which will need to correctly bind with A35 and future hardware, while overcoming the limitation of binding by PID alone, which cannot now work. The patchset updates the current AMBA Identification mechanism, which was already differentiating between 0xF and 0x9 CIDs, to add additional UCI compliant tests for the for the 0x9 device class. Additional UCI structures are provided and added to the ETMv4 driver as appropriate. Russell: Do you want me to add these 2 patches to your patch tracking system? Thanks Mike Changes since v2: Simplification of amba_cs_uci_id_match(). Fix CID class bitfield comments. Dropped RFC tag on patchset. Mike Leach (2): drivers: amba: Updates to component identification for driver matching. coresight: etmv4: Update ID register table to add UCI support drivers/amba/bus.c | 45 +++++++++++++++---- drivers/hwtracing/coresight/coresight-etm4x.c | 18 +++++++- include/linux/amba/bus.h | 32 +++++++++++++ 3 files changed, 86 insertions(+), 9 deletions(-) -- 2.19.1

6 years

[PATCH 4.20 097/127] perf cs-etm: Correct packets swapping in cs_etm__flush()

by Greg Kroah-Hartman

4.20-stable review patch. If anyone has any objections, please let me know. ------------------ [ Upstream commit 43fd56669c28cd354e9228bdb58e4bca1c1a8b66 ] The structure cs_etm_queue uses 'prev_packet' to point to previous packet, this can be used to combine with new coming packet to generate samples. In function cs_etm__flush() it swaps packets only when the flag 'etm->synth_opts.last_branch' is true, this means that it will not swap packets if without option '--itrace=il' to generate last branch entries; thus for this case the 'prev_packet' doesn't point to the correct previous packet and the stale packet still will be used to generate sequential sample. Thus if dump trace with 'perf script' command we can see the incorrect flow with the stale packet's address info. This patch corrects packets swapping in cs_etm__flush(); except using the flag 'etm->synth_opts.last_branch' it also checks the another flag 'etm->sample_branches', if any flag is true then it swaps packets so can save correct content to 'prev_packet'. Finally this can fix the wrong program flow dumping issue. The patch has a minor refactoring to use 'etm->synth_opts.last_branch' instead of 'etmq->etm->synth_opts.last_branch' for condition checking, this is consistent with that is done in cs_etm__sample(). Signed-off-by: Leo Yan <leo.yan(a)linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Mike Leach <mike.leach(a)linaro.org> Cc: Namhyung Kim <namhyung(a)kernel.org> Cc: Robert Walker <robert.walker(a)arm.com> Cc: coresight(a)lists.linaro.org Cc: linux-arm-kernel(a)lists.infradead.org Link: http://lkml.kernel.org/r/1544513908-16805-2-git-send-email-leo.yan@linaro.o… Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/perf/util/cs-etm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c index 73430b73570d..c2f0c92623f0 100644 --- a/tools/perf/util/cs-etm.c +++ b/tools/perf/util/cs-etm.c @@ -1005,7 +1005,7 @@ static int cs_etm__flush(struct cs_etm_queue *etmq) } swap_packet: - if (etmq->etm->synth_opts.last_branch) { + if (etm->sample_branches || etm->synth_opts.last_branch) { /* * Swap PACKET with PREV_PACKET: PACKET becomes PREV_PACKET for * the next incoming packet. -- 2.19.1

6 years

[PATCH 4.19 079/106] perf cs-etm: Correct packets swapping in cs_etm__flush()

by Greg Kroah-Hartman

4.19-stable review patch. If anyone has any objections, please let me know. ------------------ [ Upstream commit 43fd56669c28cd354e9228bdb58e4bca1c1a8b66 ] The structure cs_etm_queue uses 'prev_packet' to point to previous packet, this can be used to combine with new coming packet to generate samples. In function cs_etm__flush() it swaps packets only when the flag 'etm->synth_opts.last_branch' is true, this means that it will not swap packets if without option '--itrace=il' to generate last branch entries; thus for this case the 'prev_packet' doesn't point to the correct previous packet and the stale packet still will be used to generate sequential sample. Thus if dump trace with 'perf script' command we can see the incorrect flow with the stale packet's address info. This patch corrects packets swapping in cs_etm__flush(); except using the flag 'etm->synth_opts.last_branch' it also checks the another flag 'etm->sample_branches', if any flag is true then it swaps packets so can save correct content to 'prev_packet'. Finally this can fix the wrong program flow dumping issue. The patch has a minor refactoring to use 'etm->synth_opts.last_branch' instead of 'etmq->etm->synth_opts.last_branch' for condition checking, this is consistent with that is done in cs_etm__sample(). Signed-off-by: Leo Yan <leo.yan(a)linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Mike Leach <mike.leach(a)linaro.org> Cc: Namhyung Kim <namhyung(a)kernel.org> Cc: Robert Walker <robert.walker(a)arm.com> Cc: coresight(a)lists.linaro.org Cc: linux-arm-kernel(a)lists.infradead.org Link: http://lkml.kernel.org/r/1544513908-16805-2-git-send-email-leo.yan@linaro.o… Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/perf/util/cs-etm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c index ca577658e890..7b5e15cc6b71 100644 --- a/tools/perf/util/cs-etm.c +++ b/tools/perf/util/cs-etm.c @@ -1005,7 +1005,7 @@ static int cs_etm__flush(struct cs_etm_queue *etmq) } swap_packet: - if (etmq->etm->synth_opts.last_branch) { + if (etm->sample_branches || etm->synth_opts.last_branch) { /* * Swap PACKET with PREV_PACKET: PACKET becomes PREV_PACKET for * the next incoming packet. -- 2.19.1

6 years

[PATCH v6 0/8] perf cs-etm: Add support for sample flags

by Leo Yan

6 years

[RFC PATCH 00/10] CoreSight CTI Driver

by Mike Leach

This patchset adds the first version of the CoreSight CTI hardware driver. CTIs are defined in the device tree and associated with other CoreSight devices. The core CoreSight code has been modified to enable the registration of the CTI devices on the same bus as the other CoreSight components, but as these are not actually trace generation / capture devices, they are not part of the Coresight path when generating trace. However, the definition of the standard CoreSight device has been extended to include a reference to an associated CTI device, and the enable / disable trace path operations will auto enable/disable any associated CTI devices at the same time. Programming is at present via sysfs - a full API is provided to utilise the hardware capabilities. As CTI devices are unprogrammed by default, the auto enable describe above will have no effect until explicit programming takes place. A set of device tree bindings specific to the CTI topology has been defined. Documentation has been updated to describe both the CTI hardware, its use and programming in sysfs, and the new dts bindings required. This patchset is fully functional - but comes with the following caveats:- 1) device tree bindings are incomplete - and in some cases not representative of the final definitions - alternative descriptions are in place to test the differing binding properties. The QCom DB410 has been used as the principle test platform. 2) the main driver file is rather large. It may benefit from having the sysfs specific code split off into a separate file as the etm drivers have done. 3) there is a sig_names field in the CTI connection structure. This is intended to potentially contain the names of the interconnecting triggers, read from the device tree - (e.g. dbgreq, restart, tmcfull) to enable users to determine the purpose of the signals attached to the CTI. This is not yet implemented and comments on the value of implementing this are welcome. 4) there is some debug logging still present. This will be removed. 5) the updates to the AMBA drivers for UCI component ID are included in the set at present for ease of use, but are not intended to be in the final set. (patches 0001 and 0002) 6) tested on a 4.20-rc1 based tree, but applies cleanly to 5.0-rc1 All comments on structure and functionality welcome. Mike Leach (10): drivers: amba: Updates to component identification for driver matching. coresight: etmv4: Update ID register table to add UCI support drivers: coresight: Add ECT definitions to main CS header. drivers: coresight: Update to Coresight core headers for CTI. drivers: coresight: Updates to CoreSight core for CTI implementation. coresight: of: Update Coresight device tree parser code for CTI. coresight: cti: New CTI driver code. coresight: build: Add in Coresight config to build files coresight: cti: Add in device tree definitions for CTI.dts coresight: docs: Add documentation for CTI component and bindings. .../testing/sysfs-bus-coresight-devices-cti | 178 ++ .../devicetree/bindings/arm/coresight.txt | 173 ++ Documentation/trace/coresight.txt | 125 +- arch/arm64/boot/dts/arm/juno-base.dtsi | 76 + arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 9 + arch/arm64/boot/dts/qcom/msm8916.dtsi | 101 +- drivers/amba/bus.c | 45 +- drivers/hwtracing/coresight/Kconfig | 12 + drivers/hwtracing/coresight/Makefile | 1 + drivers/hwtracing/coresight/coresight-cti.c | 2025 +++++++++++++++++ drivers/hwtracing/coresight/coresight-cti.h | 195 ++ drivers/hwtracing/coresight/coresight-etm4x.c | 18 +- drivers/hwtracing/coresight/coresight-priv.h | 10 + drivers/hwtracing/coresight/coresight.c | 51 +- drivers/hwtracing/coresight/of_coresight.c | 65 + include/linux/amba/bus.h | 32 + include/linux/coresight.h | 42 + 17 files changed, 3144 insertions(+), 14 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-cti create mode 100644 drivers/hwtracing/coresight/coresight-cti.c create mode 100644 drivers/hwtracing/coresight/coresight-cti.h -- 2.19.1

6 years

Online Marketing

by Mattie Riddick

Hi, We are Digital Marketing solutions provider and I Just wanted to check if you would be interested in our below-mentioned services to grow your online presence in the market and can also drive huge traffic to your business along with quality Inbound Leads. Strategy Branding & Design Web Design Digital Marketing E-Commerce Strategy Building Strategic Planning Responsive Design Keyword Analysis Strategic Planning Market Trend Research Logo Creation Unique UX Social Media Marketing Store Set-up Competitor Analysis Customer Profiling Engaging UI SEO Customized Solutions Client Review Buyer Journeys Brand Exposure Blogging Order Management Quality Check & Testing Promotion Programs Creative Content Email Marketing Product Inventory Enhancing Experiences Video Creation Digital Advertising Payment Gateways Landing Page Pay Per Click Ads Branding & Promotion Please let me know if you're looking for any of the above services so that I can get back to you with more details and a demo for what we would like to accomplish. Await your response, Regards, Mattie Riddick Senior Marketing Consultant Email: mattie.riddick(a)expodatapro.com Address: Santa Clara |USA If you are not the right person, feel free to forward this email to the right person in your organization. To opt out, please reply with Leave Out in the Subject Line.

6 years

RFC: power saving

by Al Grant

Hi, One of the top questions that comes up on CoreSight is how it interacts with CPU power saving, and I'd like to get a handle on where we are with this. This will help us understand if any more work needs to be done. I'd suggest three levels of support: - transparent: use of CoreSight has no effect on CPU power saving - if an idle CPU would have been powered down it's still powered down. Any increased power draw from CoreSight comes from debug/trace blocks being powered up as necessary, not from keeping entire CPUs powered up. - automatic wakelock: use of CoreSight has the effect of disabling powering off of idle CPUs, so there may be a significant increase in power consumption, but it's done automatically and works out of the box. CoreSight itself is fully functional irrespective of how the system is configured. - invasive: power saving must be disabled manually - i.e. you have to get a manual (and possibly device-specific) recipe from somewhere. If you don't then things will break (loss of trace at best, crash at worst). I would hope that perf (all modes) is transparent, and direct use of sysfs is at worst a wakelock... but where are we now? Are there still boards that need manual recipes with the current kernel - either with perf or with sysfs? Thanks, Al

6 years

[PATCH v5 0/8] perf cs-etm: Add support for sample flags

by Leo Yan

6 years

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight January 2019