CoreSight

coresight@lists.linaro.org

6 participants
2343 discussions

[PATCH v2 00/10] coresight: Update device tree bindings

by Suzuki K Poulose

Coresight uses DT graph bindings to describe the connections of the components. However we have some undocumented usage of the bindings to describe some of the properties of the connections. The coresight driver needs to know the hardware ports invovled in the connection and the direction of data flow to effectively manage the trace sessions. So far we have relied on the "port" address (as described by the generic graph bindings) to represent the hardware port of the component for a connection. The hardware uses separate numbering scheme for input and output ports, which implies, we could have two different (input and output) ports with the same port number. This could create problems in the graph bindings where the label of the port wouldn't match the address. e.g, with the existing bindings we get : port@0{ // Output port 0 reg = <0>; ... }; port@1{ reg = <0>; // Input port 0 endpoint { slave-mode; ... }; }; With the new enforcement in the DT rules, mismatches in label and address are not allowed (as see in the case for port@1). So, we need a new mechanism to describe the hardware port number reliably. Also, we relied on an undocumented "slave-mode" property (see the above example) to indicate if the port is an input port. Let us formalise and switch to a new property to describe the direction of data flow. There were three options considered for the hardware port number scheme: 1) Use natural ordering in the DT to infer the hardware port number. i.e, Mandate that the all ports are listed in the DT and in the ascending order for each class (input and output respectively). Pros : - We don't need new properties and if the existing DTS list them in order (which most of them do), they work out of the box. Cons : - We must list all the ports even if the system cannot/shouldn't use it. - It is prone to human errors (if the order is not kept). 2) Use an explicit property to list both the direction and the hw port number and direction. Define "coresight,hwid" as 2 member array of u32, where the members are port number and the direction respectively. e.g port@0{ reg = <0>; endpoint { coresight,hwid = <0 1>; // Port # 0, Output } }; port@1{ reg = <1>; endpoint { coresight,hwid = <0 0>; // Port # 0, Input }; }; Pros: - The bindings are formal but not so reader friendly and could potentially lead to human errors. Cons: - Backward compatiblity is lost. 3) Use explicit properties (implemented in the series) for the hardware port id and direction. We define a new property "coresight,hwid" for each endpoint in coresight devices to specify the hardware port number explicitly. Also use a separate property "direction" to specify the direction of the data flow. e.g, port@0{ reg = <0>; endpoint { direction = <1>; // Output coresight,hwid = <0>; // Port # 0 } }; port@1{ reg = <1>; endpoint { direction = <0>; // Input coresight,hwid = <0>; // Port # 0 }; }; Pros: - The bindings are formal and reader friendly, and less prone to errors. Cons: - Backward compatibility is lost. After a round of discussions [1], the following option (4) is adopted : 4) Group ports based on the directions under a dedicated node. This has been checked with the upstream DTC tool to resolve the "address mismatch" issue. e.g, out-ports { // Output ports for this component port@0 { // Outport 0 reg = 0; endpoint { ... }; }; port@1 { // Outport 1 reg = 1; endpoint { ... }; }; }; in-ports { // Input ports for this component port@0 { // Inport 0 reg = 0; endpoint { ... }; }; port@1 { // Inport 1 reg = 1; endpoint { ... }; }; }; This series implements Option (4) listed above and falls back to the old bindings if the new bindings are not available. This allows the systems with old bindings work with the new driver. The driver now issues a warning (once) when it encounters the old bindings. The series contains DT update for Juno platform. The remaining in-kernel sources could be updated once we are fine with the proposal. It also cleans up the platform parsing code to reduce the memory usage by reusing the platform description. Applies on coresight/next Changes since V1: - Implement the proposal by Rob. - Drop the DTS updates for all platforms except Juno - Drop the incorrect fix in coresight_register. Instead document the code to prevent people trying to un-fix it again. - Add a patch to drop remote device references in DT graph parsing - Split of_node refcount fixing patch, fix a typo in the comment. - Add Reviewed-by tags from Mathieu. - Drop patches picked up for 4.18-rc series Changes since RFC: - Fixed style issues - Fix an existing memory leak coresight_register (Found in code update) - Fix missing of_node_put() in the existing driver (Reported-by Mathieu) - Update the existing dts in kernel tree. Suzuki K Poulose (10): coresight: Document error handling in coresight_register coresight: platform: Refactor graph endpoint parsing coresight: platform: Fix refcounting for graph nodes coresight: platform: Fix leaking device reference coresight: Fix remote endpoint parsing coresight: Add helper to check if the endpoint is input coresight: platform: Cleanup coresight connection handling coresight: dts: Document usage of graph bindings coresight: Cleanup coresight DT bindings dts: juno: Update coresight bindings for hw port .../devicetree/bindings/arm/coresight.txt | 95 ++++---- arch/arm64/boot/dts/arm/juno-base.dtsi | 161 ++++++------- arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 52 ++-- arch/arm64/boot/dts/arm/juno.dts | 13 +- drivers/hwtracing/coresight/coresight.c | 35 +-- drivers/hwtracing/coresight/of_coresight.c | 262 ++++++++++++++------- include/linux/coresight.h | 9 +- 7 files changed, 353 insertions(+), 274 deletions(-) -- 2.7.4

6 years, 9 months

[PATCH v2 00/10] coresight: perf: Support for tmc-etr backed buffers

by Suzuki K Poulose

This series adds the support for using the tmc-etr in perf mode for storing the trace to system RAM. The ETR uses a separate buffer (double buffering) for storing the trace. This is copied back to the ring buffer when the event is stopped. We try to match the ETR buffer to the larger of perf ring buffer or the size configured for the ETR via sysfs. This allows tuning the buffer size to prevent overflows and loosing trace data, as we don't have overflow interrupt support (yet). Applies on coresight/next Changes since v1 : - Fix path for each CPU where the event might be recorded. - Handle errors in enabling source - Remove set_buffer callback to avoid complicating the error handling. - Fix a bug in handling sysfs mode specific buffers Changes since [0] : - Drop buffer rotation logic for etr-buf - Do not use perf ring buffer. (Add support later) - Fix handling of sink, preventing mixed modes of operation. [0] - TMC ETR perf support - http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/574875.html Suzuki K Poulose (10): coresight: Fix handling of sinks coresight: perf: Fix per cpu path management coresight: perf: Disable trace path upon source error coresight: tmc-etr: Handle driver mode specific ETR buffers coresight: tmc-etr: Relax collection of trace from sysfs mode coresight: Convert driver messages to dev_dbg coresight: perf: Remove reset_buffer call back for sinks coresight: perf: Add helper to retrieve sink configuration coresight: perf: Remove set_buffer call back coresight: etm-perf: Add support for ETR backend .../coresight/coresight-dynamic-replicator.c | 4 +- drivers/hwtracing/coresight/coresight-etb10.c | 84 ++---- drivers/hwtracing/coresight/coresight-etm-perf.c | 91 +++--- drivers/hwtracing/coresight/coresight-etm-perf.h | 26 ++ drivers/hwtracing/coresight/coresight-etm3x.c | 4 +- drivers/hwtracing/coresight/coresight-etm4x.c | 4 +- drivers/hwtracing/coresight/coresight-funnel.c | 4 +- drivers/hwtracing/coresight/coresight-priv.h | 2 +- drivers/hwtracing/coresight/coresight-replicator.c | 4 +- drivers/hwtracing/coresight/coresight-stm.c | 4 +- drivers/hwtracing/coresight/coresight-tmc-etf.c | 94 +++--- drivers/hwtracing/coresight/coresight-tmc-etr.c | 327 ++++++++++++++++++--- drivers/hwtracing/coresight/coresight-tmc.c | 4 +- drivers/hwtracing/coresight/coresight-tmc.h | 4 + drivers/hwtracing/coresight/coresight-tpiu.c | 6 +- drivers/hwtracing/coresight/coresight.c | 31 +- include/linux/coresight.h | 12 +- 17 files changed, 473 insertions(+), 232 deletions(-) -- 2.7.4

6 years, 9 months

[PATCH 0/6] coresight: perf: Support for tmc-etr backed buffers

by Suzuki K Poulose

This series adds the support for using the tmc-etr in perf mode for storing the trace to system RAM. The ETR uses a separate buffer (double buffering) for storing the trace. This is copied back to the ring buffer when the event is stopped. We try to match the ETR buffer to the larger of perf ring buffer or the size configured for the ETR via sysfs. This allows tuning the buffer size to prevent overflows and loosing trace data, as we don't have overflow interrupt support (yet). Applies on coresight/next Changes since [0] : - Drop buffer rotation logic for etr-buf - Do not use perf ring buffer. (Add support later) - Fix handling of sink, preventing mixed modes of operation. [0] - TMC ETR perf support - http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/574875.html Suzuki K Poulose (6): coresight: Fix handling of sinks coresight: tmc-etr: Handle driver mode specific ETR buffers coresight: tmc-etr: Relax collection of trace from sysfs mode coresight: Convert driver messages to dev_dbg coresight: perf: Remove reset_buffer call back for sinks coresight: etm-perf: Add support for ETR backend .../coresight/coresight-dynamic-replicator.c | 4 +- drivers/hwtracing/coresight/coresight-etb10.c | 62 +--- drivers/hwtracing/coresight/coresight-etm-perf.c | 9 +- drivers/hwtracing/coresight/coresight-etm3x.c | 4 +- drivers/hwtracing/coresight/coresight-etm4x.c | 4 +- drivers/hwtracing/coresight/coresight-funnel.c | 4 +- drivers/hwtracing/coresight/coresight-replicator.c | 4 +- drivers/hwtracing/coresight/coresight-stm.c | 4 +- drivers/hwtracing/coresight/coresight-tmc-etf.c | 66 +--- drivers/hwtracing/coresight/coresight-tmc-etr.c | 337 +++++++++++++++++++-- drivers/hwtracing/coresight/coresight-tmc.c | 4 +- drivers/hwtracing/coresight/coresight-tmc.h | 4 + drivers/hwtracing/coresight/coresight-tpiu.c | 4 +- drivers/hwtracing/coresight/coresight.c | 22 +- include/linux/coresight.h | 5 +- 15 files changed, 375 insertions(+), 162 deletions(-) -- 2.7.4

6 years, 9 months

[RFC PATCH 0/8] coresight: Update device tree bindings

by Suzuki K Poulose

Coresight uses DT graph bindings to describe the connections of the components. However we have some undocumented usage of the bindings to describe some of the properties of the connections. The coresight driver needs to know the hardware ports invovled in the connection and the direction of data flow to effectively manage the trace sessions. So far we have relied on the "port" address (as described by the generic graph bindings) to represent the hardware port of the component for a connection. The hardware uses separate numbering scheme for input and output ports, which implies, we could have two different (input and output) ports with the same port number. This could create problems in the graph bindings where the label of the port wouldn't match the address. e.g, with the existing bindings we get : port@0{ // Output port 0 reg = <0>; ... }; port@1{ reg = <0>; // Input port 0 endpoint { slave-mode; ... }; }; With the new enforcement in the DT rules, mismatches in label and address are not allowed (as see in the case for port@1). So, we need a new mechanism to describe the hardware port number reliably. Also, we relied on an undocumented "slave-mode" property (see the above example) to indicate if the port is an input port. Let us formalise and switch to a new property to describe the direction of data flow. There were three options considered for the hardware port number scheme: 1) Use natural ordering in the DT to infer the hardware port number. i.e, Mandate that the all ports are listed in the DT and in the ascending order for each class (input and output respectively). Pros : - We don't need new properties and if the existing DTS list them in order (which most of them do), they work out of the box. Cons : - We must list all the ports even if the system cannot/shouldn't use it. - It is prone to human errors (if the order is not kept). 2) Use an explicit property to list both the direction and the hw port number and direction. Define "coresight,hwid" as 2 member array of u32, where the members are port number and the direction respectively. e.g port@0{ reg = <0>; endpoint { coresight,hwid = <0 1>; // Port # 0, Output } }; port@1{ reg = <1>; endpoint { coresight,hwid = <0 0>; // Port # 0, Input }; }; Pros: - The bindings are formal but not so reader friendly and could potentially lead to human errors. Cons: - Backward compatiblity is lost. 3) Use explicit properties (implemented in the series) for the hardware port id and direction. We define a new property "coresight,hwid" for each endpoint in coresight devices to specify the hardware port number explicitly. Also use a separate property "direction" to specify the direction of the data flow. e.g, port@0{ reg = <0>; endpoint { direction = <1>; // Output coresight,hwid = <0>; // Port # 0 } }; port@1{ reg = <1>; endpoint { direction = <0>; // Input coresight,hwid = <0>; // Port # 0 }; }; Pros: - The bindings are formal and reader friendly, and less prone to errors. Cons: - Backward compatibility is lost. This series achieves implements Option (3) listed above while still retaining the backward compatibility. The driver now issues a warning (once) when it encounters the old bindings. It also cleans up the platform parsing code to reduce the memory usage by reusing the platform description. The series also includes the changes for Juno platform as an example. If there are no objections to the approach, I could post the series, converting all the in-kernel DTS to the new binding. Suzuki K Poulose (8): dts: binding: coresight: Document graph bindings coresight: Fix remote endpoint parsing coresight: Cleanup platform description data coresight: platform: Cleanup coresight connection handling coresight: Handle errors in finding input/output ports dts: coresight: Clean up the device tree graph bindings dts: coresight: Define new bindings for direction of data flow dts: juno: Update coresight bindings for hw port .../devicetree/bindings/arm/coresight.txt | 52 ++++++++-- arch/arm64/boot/dts/arm/juno-base.dtsi | 82 +++++++++++---- arch/arm64/boot/dts/arm/juno.dts | 5 +- drivers/hwtracing/coresight/coresight.c | 28 ++---- drivers/hwtracing/coresight/of_coresight.c | 111 ++++++++++++--------- include/linux/coresight.h | 11 +- 6 files changed, 181 insertions(+), 108 deletions(-) -- 2.7.4

6 years, 10 months

[PATCH 00/20] coresight: Update device tree bindings

by Suzuki K Poulose

Coresight uses DT graph bindings to describe the connections of the components. However we have some undocumented usage of the bindings to describe some of the properties of the connections. The coresight driver needs to know the hardware ports invovled in the connection and the direction of data flow to effectively manage the trace sessions. So far we have relied on the "port" address (as described by the generic graph bindings) to represent the hardware port of the component for a connection. The hardware uses separate numbering scheme for input and output ports, which implies, we could have two different (input and output) ports with the same port number. This could create problems in the graph bindings where the label of the port wouldn't match the address. e.g, with the existing bindings we get : port@0{ // Output port 0 reg = <0>; ... }; port@1{ reg = <0>; // Input port 0 endpoint { slave-mode; ... }; }; With the new enforcement in the DT rules, mismatches in label and address are not allowed (as see in the case for port@1). So, we need a new mechanism to describe the hardware port number reliably. Also, we relied on an undocumented "slave-mode" property (see the above example) to indicate if the port is an input port. Let us formalise and switch to a new property to describe the direction of data flow. There were three options considered for the hardware port number scheme: 1) Use natural ordering in the DT to infer the hardware port number. i.e, Mandate that the all ports are listed in the DT and in the ascending order for each class (input and output respectively). Pros : - We don't need new properties and if the existing DTS list them in order (which most of them do), they work out of the box. Cons : - We must list all the ports even if the system cannot/shouldn't use it. - It is prone to human errors (if the order is not kept). 2) Use an explicit property to list both the direction and the hw port number and direction. Define "coresight,hwid" as 2 member array of u32, where the members are port number and the direction respectively. e.g port@0{ reg = <0>; endpoint { coresight,hwid = <0 1>; // Port # 0, Output } }; port@1{ reg = <1>; endpoint { coresight,hwid = <0 0>; // Port # 0, Input }; }; Pros: - The bindings are formal but not so reader friendly and could potentially lead to human errors. Cons: - Backward compatiblity is lost. 3) Use explicit properties (implemented in the series) for the hardware port id and direction. We define a new property "coresight,hwid" for each endpoint in coresight devices to specify the hardware port number explicitly. Also use a separate property "direction" to specify the direction of the data flow. e.g, port@0{ reg = <0>; endpoint { direction = <1>; // Output coresight,hwid = <0>; // Port # 0 } }; port@1{ reg = <1>; endpoint { direction = <0>; // Input coresight,hwid = <0>; // Port # 0 }; }; Pros: - The bindings are formal and reader friendly, and less prone to errors. Cons: - Backward compatibility is lost. This series implements Option (3) listed above and falls back to the old bindings if the new bindings are not available. This allows the systems with old bindings work with the new driver. The driver now issues a warning (once) when it encounters the old bindings. It also cleans up the platform parsing code to reduce the memory usage by reusing the platform description. I am not sure what is the best route to push these DTS changes. Thoughts ? Changes since RFC [0] : - Fixed style issues - Fix an existing memory leak coresight_register (Found in code update) - Fix missing of_node_put() in the existing driver (Reported-by Mathieu) - Update the existing dts in kernel tree. - Rename new helper functions for consistency Suzuki K Poulose (20): coresight: Fix memory leak in coresight_register coresight: of: Fix refcounting for graph nodes coresight: Fix remote endpoint parsing coresight: Cleanup platform description data coresight: platform: Cleanup coresight connection handling coresight: Handle errors in finding input/output ports coresight: dts: Document usage of graph bindings coresight: dts: Cleanup device tree graph bindings coresight: dts: Define new bindings for direction of data flow dts: juno: Update coresight bindings for hw port dts: hisilicon: Update coresight bindings for hw ports dts: spreadtrum: Update coresight bindings for hw ports dts: qcom: Update coresight bindings for hw ports dts: arm: hisilicon: Update coresight bindings for hardware port dts: arm: imx7{d,s}: Update coresight binding for hardware ports dts: arm: omap: Update coresight bindings for hardware ports dts: arm: qcom: Update coresight bindings for hardware ports dts: sama5d2: Update coresight bindings for hardware ports dts: ste-dbx5x0: Update coresight bindings for hardware port dts: tc2: Update coresight bindings for hardware ports .../devicetree/bindings/arm/coresight.txt | 76 +++++-- arch/arm/boot/dts/hip04.dtsi | 195 +++++++++++++----- arch/arm/boot/dts/imx7d.dtsi | 5 +- arch/arm/boot/dts/imx7s.dtsi | 41 ++-- arch/arm/boot/dts/omap3-beagle-xm.dts | 5 +- arch/arm/boot/dts/omap3-beagle.dts | 5 +- arch/arm/boot/dts/qcom-apq8064.dtsi | 37 +++- arch/arm/boot/dts/qcom-msm8974.dtsi | 60 ++++-- arch/arm/boot/dts/sama5d2.dtsi | 5 +- arch/arm/boot/dts/ste-dbx5x0.dtsi | 31 ++- arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 48 +++-- arch/arm64/boot/dts/arm/juno-base.dtsi | 82 +++++--- arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 26 ++- arch/arm64/boot/dts/arm/juno.dts | 5 +- .../arm64/boot/dts/hisilicon/hi6220-coresight.dtsi | 89 ++++++--- arch/arm64/boot/dts/qcom/msm8916.dtsi | 55 ++++-- arch/arm64/boot/dts/sprd/sc9836.dtsi | 40 ++-- arch/arm64/boot/dts/sprd/sc9860.dtsi | 101 +++++++--- drivers/hwtracing/coresight/coresight.c | 30 +-- drivers/hwtracing/coresight/of_coresight.c | 219 +++++++++++++-------- include/linux/coresight.h | 11 +- 21 files changed, 818 insertions(+), 348 deletions(-) -- 2.7.4

6 years, 10 months

Managed Service Providers (MSPs) and Managed Security Service Providers (MSSPs)?

by rebecca.sanchez＠ceritica.com

Hi, I just wanted to check if you would be interested in a list of Managed Service Providers (MSPs) and Managed Security Service Providers (MSSPs)? • Managed Service Providers (MSP’s) – 25,000 unique companies • Managed Security Service Providers (MSSP’s) – 7,520 unique companies IT Decision Makers – 6million Business Decision Makers – 10 million Kindly review and let me know if I can share more information on this. I look forward to hearing from you. Regards, Rebecca MSP List Specialist For Opt-Out reply with “Not Interested”.

6 years, 10 months

[PATCH 0/9] perf tools: Cleanup for CoreSight trace decoding code

by Mathieu Poirier

This set serves no other purpose than doing preparatory work before support for CPU-wide trace scenarios is introduced. It cleans up a lot of code and reorganise things so that what is currently being used for per-thread decoding can be used as well for CPU-wide sessions. It is based on Leo's latest submission to the CS mailing list. I am sending this here to circumvent the constraints imposed by the merge window and will go public next week when the first release candidate for the 4.18 cycle has been minted. Leo and Rob, you guys are now familiar with the perf tools code and as such would appreciate your thougths on this. The code has been uploaded here[1]. Regards, Mathieu [1]. https://git.linaro.org/people/mathieu.poirier/coresight.git perf-opencsd-master-cpu-wide-support Mathieu Poirier (9): perf tools: Remove unused structure field "state" perf tools: Introducing cs_etm_decoder__init_dparams() perf tools: Introducing function cs_etm__init_trace_params() perf tools: Cleaning up function cs_etm__alloc_queue() perf tools: Rethink kernel address initialisation perf tools: Make cs_etm__run_decoder() queue independent perf tools: Modularize main decoder function perf tools: Modularize main packet processing loop perf tools: Modularize auxtrace_buffer fetch function tools/perf/util/cs-etm-decoder/cs-etm-decoder.h | 13 +- tools/perf/util/cs-etm.c | 339 ++++++++++++++---------- 2 files changed, 210 insertions(+), 142 deletions(-) -- 2.7.4

6 years, 10 months

OpenCSD ITM support

by Athalye, Ashwini

The OpenCSD README says that ITM software trace will be added in the future. Two questions regarding this: 1. When is the support expected to be available? 2. Will the support include ITM software message decode and DWT hardware event decode as well or just the former? Thanks, Ashwini

6 years, 10 months

Re: Regression of 'perf record' on Hikey620

by Mathieu Poirier

On Tue, 19 Jun 2018 at 07:37, Leo Yan <leo.yan(a)linaro.org> wrote: > > Hi Mathieu, > > On Mon, Jun 18, 2018 at 07:26:20PM -0600, Mathieu Poirier wrote: > > On Mon, 18 Jun 2018 at 18:59, Leo Yan <leo.yan(a)linaro.org> wrote: > > > > > > Hi all, > > > > > > Just in case you have the same issue, when I use acme's branch perf/core > > > with latest commit e238cf2e3d2e ("perf intel-pt: Fix packet decoding of > > > CYC packets"), I can easily reproduce below failure with 'perf record' > > > command. > > > > > > If you have fixing for this, please let me know. Otherwise I will dig a > > > bit for this issue (probably relying on 'git bisect'). > > > > Haven't see this, though my tree is based on mainline 4.18-rc1. Let > > me know what bisect gives you. > > Finally I found this issue is caused by I removed 'nohlt' in kernel > command line, so CPU Idle states are enabled. > > After CPU Idle states are enabled, we cannot access the register > /sys/bus/coresight/devices/f659c000.etm/mgmt/trcauthstatus when the > CPU stays in the low power states. Interesting. > > So following this issue, I have two questions (sorry if you guys have > discussed these questions before): > > - The first one question is should we support Runtime PM (Or GenPD) in > Coresight? So when we access some component (e.g. the register > trcauthstatus) we need to ensure the corresponding power domain is > powered on properly before we access it. We rely heavily on runtime PM everywhere [1] in the code to make sure devices are accessed only when they're powered up. TRCAUTHSTATUS is a "management" register [2] and as such should not need to have the core powered up [3], which is why it is accessed with macro coresight_etm4x_reg() rather than coresight_etm4x_cross_read(). That being said implementation can differ from the guidelines. First thing to do is to try going from coresight_etm4x_reg() to coresight_etm4x_cross_read() here [4] and see if there is any changes. If that doesn't work you need to ask HiSilicon what power domain the register is in. From there get back to me and we'll talk things over. [1]. https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/arm/juno… [2]. See "ARM Embedded Trace Macrocell Architecture Specifiation" (ID032614), table 7-1 on page 7-311 for details. [3]. Same document as above, table 7-4 on page 7-314 [4]. https://elixir.bootlin.com/linux/latest/source/drivers/hwtracing/coresight/… > > - The second one question is another side topic: if we support CPU > wide tracing, should we support suspend/resume flow for Coresight > ETM? So we can save and restore context for CPU respectively. When using Perf suspend/resume is already supported - tracers won't be kept on whey there is no more processes executing on a CPU (just before going to idle). Tracers will also be switched back on once the CPU has resumed, just before processes start being executed on it. Configuration of the trace unit is kept in memory. In sysFS mode I expected users to disable CPUidle, but that can be change if you have a use case. Thanks, Mathieu > > Thanks, > Leo Yan > > > > ---8<--- > > > > > > # ./perf record -e cs_etm/(a)f6402000.etf/ --per-thread uname > > > [ 240.623458] Internal error: synchronous external abort: 96000210 [#10] PREEMPT SMP > > > [ 240.631055] Modules linked in: > > > [ 240.634117] CPU: 1 PID: 2793 Comm: perf Tainted: G D 4.17.0-08502-ge238cf2 #26 > > > [ 240.642648] Hardware name: HiKey Development Board (DT) > > > [ 240.647876] pstate: 40000005 (nZcv daif -PAN -UAO) > > > [ 240.652677] pc : trcauthstatus_show+0x3c/0x78 > > > [ 240.657035] lr : trcauthstatus_show+0x34/0x78 > > > [ 240.661391] sp : ffff00000dcfbbc0 > > > [ 240.664703] x29: ffff00000dcfbbc0 x28: 0000000000000001 > > > [ 240.670019] x27: 00000000007000c0 x26: ffff800036fa4048 > > > [ 240.675335] x25: 0000000000001000 x24: ffff000008d95330 > > > [ 240.680651] x23: ffff8000372ad880 x22: ffff80003b346cb8 > > > [ 240.685966] x21: ffff800036fa8080 x20: ffff80003b346ca8 > > > [ 240.691281] x19: ffff0000099d5fb8 x18: 0000000000000000 > > > [ 240.696597] x17: 0000ffffbb44bb68 x16: ffff0000082a3908 > > > [ 240.701911] x15: 0000000000000000 x14: 0000000000000016 > > > [ 240.707227] x13: 7375746174736874 x12: 75616372742f746d > > > [ 240.712542] x11: 0000000000000020 x10: 0000000080070007 > > > [ 240.717857] x9 : 0000000000000000 x8 : ffff800036fa9080 > > > [ 240.723173] x7 : 0000000000000000 x6 : 000000000000003f > > > [ 240.728488] x5 : 0000000000000040 x4 : 0000000000000000 > > > [ 240.733803] x3 : 0000000000000000 x2 : 4d223a68697bbd00 > > > [ 240.739118] x1 : ffff80001fc30f80 x0 : 0000000000000001 > > > [ 240.744435] Process perf (pid: 2793, stack limit = 0x0000000051ca53e7) > > > [ 240.750965] Call trace: > > > [ 240.753411] trcauthstatus_show+0x3c/0x78 > > > [ 240.757423] dev_attr_show+0x3c/0x80 > > > [ 240.761002] sysfs_kf_seq_show+0xc0/0x158 > > > [ 240.765012] kernfs_seq_show+0x44/0x50 > > > [ 240.768764] seq_read+0x1cc/0x4b8 > > > [ 240.772078] kernfs_fop_read+0x13c/0x1e0 > > > [ 240.776002] __vfs_read+0x60/0x170 > > > [ 240.779403] vfs_read+0x94/0x150 > > > [ 240.782630] ksys_read+0x6c/0xd8 > > > [ 240.785856] sys_read+0x34/0x48 > > > [ 240.788998] el0_svc_naked+0x30/0x34 > > > [ 240.792575] Code: f9404c53 97f2054e f9400273 913ee273 (b9400273) > > > [ 240.798673] ---[ end trace 838ff5bf36115622 ]--- > > > > > > Message from syslogd@linaro-developer at May 23 09:50:03 ... > > > kernel:[ 240.623458] Internal error: synchronous external abort: 96000210 [#10] PREEMPT SMP > > > > > > Message from syslogd@linaro-developer at May 23 09:50:03 ... > > > kernel:[ 240.744435] Process perf (pid: 2793, stack limit = 0x0000000051ca53e7) > > > > > > Message from syslogd@linaro-developer at May 23 09:50:03 ... > > > kernel:[ 240.792575] Code: f9404c53 97f2054e f9400273 913ee273 (b9400273) > > > Segmentation fault > > > root@linaro-developer:~# > > >

6 years, 10 months

Debian packaging - patches

by Wookey

I've been packaging libopenCSD for debian. That has resulted in various changes, largely to the makefiles. Most of those changes should go upstream, rather than exist only in the debian version. I'll post my issues/changes here for discussion so we can decide what is upstreamable. In the meantime anyone interested can try the debian packages here: http://wookware.org/software/repo/ either manually from: http://wookware.org/software/repo/pool/main/libo/libopencsd/ or with deb [ trusted=yes ] http://wookware.org/software/repo unstable main apt update; apt install libopencsd0 (and/or libopencsd-dev libopencsd-doc libopencsd-dbgsym) (for debian unstable, amd64 only) (package is signed, but repo isn't. Sorry) Or get the source and rebuild for a different debian-based distro/release. I've not separated all my changes into proper standalone patches yet, but some are so let's start with those. 1) The doxygen doc build doesn't find all the components because they moved. This fixes that: Index: libopencsd-0.8.0/decoder/docs/doxygen_config.dox =================================================================== --- libopencsd-0.8.0.orig/decoder/docs/doxygen_config.dox +++ libopencsd-0.8.0/decoder/docs/doxygen_config.dox @@ -765,11 +765,11 @@ WARN_LOGFILE = INPUT = ../include \ ../include/interfaces \ - ../include/etmv3 \ - ../include/etmv4 \ - ../include/ptm \ - ../include/c_api \ - ../include/stm \ + ../include/opencsd/etmv3 \ + ../include/opencsd/etmv4 \ + ../include/opencsd/ptm \ + ../include/opencsd/c_api \ + ../include/opencsd/stm \ ../include/mem_acc \ ../../README.md \ . \ 2) The makefile provides no doc-build. The patch below adds that. I didn't include an install-docs target, although if you added one with a variable to set the target dir then I'd use it. Index: libopencsd-0.8.0/decoder/build/linux/makefile =================================================================== --- libopencsd-0.8.0.orig/decoder/build/linux/makefile +++ libopencsd-0.8.0/decoder/build/linux/makefile @@ -155,6 +155,13 @@ tests: libs cd $(OCSD_ROOT)/tests/build/linux/trc_pkt_lister && make cd $(OCSD_ROOT)/tests/build/linux/c_api_pkt_print_test && make +# +# build docs +.PHONY: docs +docs: + (cd $(OCSD_ROOT/docs); doxygen doxygen_config.dox) + + ############################################################# # clean targets # @@ -176,3 +183,4 @@ clean_install: rm -f $(INSTALL_LIB_DIR)/lib$(LIB_BASE_NAME).so rm -f $(INSTALL_LIB_DIR)/lib$(LIB_CAPI_NAME).so rm -rf $(INSTALL_INCLUDE_DIR)/$(LIB_UAPI_INC_DIR) + rm -rf $(OCSD_ROOT)/docs/html 3) The static libraries are built but not installed. Now static libraries aren't much use to anyone these days, but if you build them then you might as well install them. This patch does that: Index: libopencsd-0.8.0/decoder/build/linux/makefile =================================================================== --- libopencsd-0.8.0.orig/decoder/build/linux/makefile +++ libopencsd-0.8.0/decoder/build/linux/makefile @@ -136,6 +136,8 @@ mkdir -p $(INSTALL_LIB_DIR) $(INSTALL_INCLUDE_DIR) $(INSTALL) --mode=644 $(LIB_TARGET_DIR)/lib$(LIB_BASE_NAME).so $(INSTALL_LIB_DIR)/ $(INSTALL) --mode=644 $(LIB_TARGET_DIR)/lib$(LIB_CAPI_NAME).so $(INSTALL_LIB_DIR)/ + $(INSTALL) --mode=644 $(LIB_TARGET_DIR)/lib$(LIB_BASE_NAME).a $(INSTALL_LIB_DIR)/ + $(INSTALL) --mode=644 $(LIB_TARGET_DIR)/lib$(LIB_CAPI_NAME).a $(INSTALL_LIB_DIR)/ cd $(OCSD_ROOT)/build/linux/rctdl_c_api_lib && make install_inc ################################ @@ -192,6 +194,6 @@ cd $(OCSD_ROOT)/tests/build/linux/c_api_pkt_print_test && make clean clean_install: - rm -f $(INSTALL_LIB_DIR)/lib$(LIB_BASE_NAME).so - rm -f $(INSTALL_LIB_DIR)/lib$(LIB_CAPI_NAME).so + rm -f $(INSTALL_LIB_DIR)/lib$(LIB_BASE_NAME).{so,a} + rm -f $(INSTALL_LIB_DIR)/lib$(LIB_CAPI_NAME).{so,a} rm -rf $(INSTALL_INCLUDE_DIR)/$(LIB_UAPI_INC_DIR) 4) The makefile arbitrarily restricts the build to arm and x86 architectures. The only reason for this is in order to build into a particular named directory, and to set -m32/-m64 flags for x86 which should be defaulted correctly on any sensible toolchain or cross-toolchain anyway. This code can build, and be used, on any arch and the makefile should allow that, so this should be fixed. I don't see the need to build into a host-arch named PLAT_DIR directory. Is there one? It only does one build at a time, whether crossing or not, so I see no reason not to use a fixed name for this dir, such as 'builddir'. This has no effect on the ability to cross or not. If you really want to change the name of PLAT_DIR then find out the HOST triplet and use that. On debian this is dpkg-architecture -q DEB_HOST_GNU_TYPE, (which is also the same prefix as would be used to specify the toolchain prefix for crossing). But like I say, I think a fixed builddir is actually all you need unless I'm missing something. So this patch lets the build work on any arch: Index: libopencsd-0.8.0/decoder/build/linux/makefile =================================================================== --- libopencsd-0.8.0.orig/decoder/build/linux/makefile +++ libopencsd-0.8.0/decoder/build/linux/makefile @@ -92,27 +92,6 @@ BUILD_VARIANT=rel endif -# platform bit size variant -ifeq ($(ARCH),x86) - MFLAG:="-m32" - BIT_VARIANT=32 -else ifeq ($(ARCH),x86_64) - MFLAG:="-m64" - BIT_VARIANT=64 -else ifeq ($(ARCH),arm) - BIT_VARIANT=-arm -else ifeq ($(ARCH),arm64) - BIT_VARIANT=-arm64 -else ifeq ($(ARCH),aarch64) - BIT_VARIANT=-arm64 -else ifeq ($(ARCH),aarch32) - BIT_VARIANT=-arm -endif - -MASTER_CC_FLAGS += $(MFLAG) -MASTER_CPP_FLAGS += $(MFLAG) -MASTER_LINKER_FLAGS += $(MFLAG) - # export build flags export MASTER_CC_FLAGS export MASTER_CPP_FLAGS @@ -120,7 +99,7 @@ export MASTER_LINKER_FLAGS export MASTER_LIB_FLAGS # target directories -export PLAT_DIR=linux$(BIT_VARIANT)/$(BUILD_VARIANT) +export PLAT_DIR=builddir export LIB_TARGET_DIR=$(OCSD_LIB_ROOT)/$(PLAT_DIR) export LIB_TEST_TARGET_DIR=$(OCSD_TESTS)/lib/$(PLAT_DIR) export BIN_TEST_TARGET_DIR=$(OCSD_TESTS)/bin/$(PLAT_DIR) All these patches included as files too. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/

6 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight