CoreSight July 2018

coresight@lists.linaro.org

8 participants
9 discussions

by Ajith Kurian Issac

Hi, We are trying to us the Open CSD for decoding a onchip trace in our ETB. The trace was enabled and is captured in the ETB. We read the trace back and dumped it into a text file. I am attaching it. How can I use the CSD tool to decode it? Thanks Ajith

5 years, 10 months

[PATCH v3 0/9] 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 V2: - Clean of_coresight_parse_endpoint() to return 1 to indicate a connection record was updated. - Drop documentation for old bindings 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 (9): 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: Cleanup coresight DT bindings dts: juno: Update coresight bindings .../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 | 269 ++++++++++++++------- include/linux/coresight.h | 9 +- 7 files changed, 359 insertions(+), 275 deletions(-) -- 2.7.4

6 years

[PATCH v3 00/13] coresight: perf: Support for TMC ETR backend

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 v2: - Split hotplug lock cleanup from per-cpu path management - Add support for tracing on hotplugged CPUs (based on patch by Mathieu) - Fix handling of perf mode in etb10 driver - Fix CS_UNLOCK() typo in ETR perf driver - Rename call backs from tmc_etr_<op>_perf_buffer => tmc_<op>_etr_buffer to be consistent with ETF driver - Modify the commit description for removing set_buffer call back. 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 (13): coresight: Fix handling of sinks coresight: etb10: Fix handling of perf mode coresight: perf: Fix per cpu path management coresight: perf: Avoid unncessary CPU hotplug read lock coresight: perf: Allow tracing on hotplugged CPUs 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 | 100 +++---- drivers/hwtracing/coresight/coresight-etm-perf.c | 134 +++++---- 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, 517 insertions(+), 247 deletions(-) -- 2.7.4

6 years, 1 month

New Version of OpenCSD Library 0.9.1

by Mike Leach

New version of the library has been released. Fixes issue raised where a segfault can occur in the memory caching code if the first memory location the decoder attempts to access does not have an associated memory image registered with the library -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

6 years, 1 month

[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, 1 month

[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, 1 month

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

by Suzuki K Poulose

6 years, 1 month

[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, 2 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, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight July 2018