The v8 architecture defines the relationship between a PE, its optional ETM
and a CTI. Unlike non-architectural CTIs which are implementation defined,
this has a fixed set of connections which can therefore be represented as a
simple tag in the device tree.
This patch defines the tags needed to create an entry for this PE/ETM/CTI
relationship, and provides functionality to implement the connection model
in the CTI driver.
Signed-off-by: Mike Leach <mike.leach(a)linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier(a)linaro.org>
---
.../coresight/coresight-cti-platform.c | 205 ++++++++++++++++++
.../hwtracing/coresight/coresight-platform.c | 20 ++
drivers/hwtracing/coresight/coresight-priv.h | 2 +
drivers/hwtracing/coresight/coresight.c | 12 +-
4 files changed, 230 insertions(+), 9 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-cti-platform.c b/drivers/hwtracing/coresight/coresight-cti-platform.c
index 665be86c585d..36a276eda50a 100644
--- a/drivers/hwtracing/coresight/coresight-cti-platform.c
+++ b/drivers/hwtracing/coresight/coresight-cti-platform.c
@@ -3,10 +3,208 @@
* Copyright (c) 2019, The Linaro Limited. All rights reserved.
*/
+#include <dt-bindings/arm/coresight-cti-dt.h>
#include <linux/of.h>
#include "coresight-cti.h"
+/* Number of CTI signals in the v8 architecturally defined connection */
+#define NR_V8PE_IN_SIGS 2
+#define NR_V8PE_OUT_SIGS 3
+#define NR_V8ETM_INOUT_SIGS 4
+
+/* CTI device tree connection property keywords */
+#define CTI_DT_V8ARCH_COMPAT "arm,coresight-cti-v8-arch"
+#define CTI_DT_CSDEV_ASSOC "arm,cs-dev-assoc"
+
+#ifdef CONFIG_OF
+/*
+ * CTI can be bound to a CPU, or a system device.
+ * CPU can be declared at the device top level or in a connections node
+ * so need to check relative to node not device.
+ */
+static int of_cti_get_cpu_at_node(const struct device_node *node)
+{
+ int cpu;
+ struct device_node *dn;
+
+ if (node == NULL)
+ return -1;
+
+ dn = of_parse_phandle(node, "cpu", 0);
+ /* CTI affinity defaults to no cpu */
+ if (!dn)
+ return -1;
+ cpu = of_cpu_node_to_id(dn);
+ of_node_put(dn);
+
+ /* No Affinity if no cpu nodes are found */
+ return (cpu < 0) ? -1 : cpu;
+}
+
+#else
+static int of_cti_get_cpu_at_node(const struct device_node *node)
+{
+ return -1;
+}
+
+#endif
+
+/*
+ * CTI can be bound to a CPU, or a system device.
+ * CPU can be declared at the device top level or in a connections node
+ * so need to check relative to node not device.
+ */
+static int cti_plat_get_cpu_at_node(struct fwnode_handle *fwnode)
+{
+ if (is_of_node(fwnode))
+ return of_cti_get_cpu_at_node(to_of_node(fwnode));
+ return -1;
+}
+
+const char *cti_plat_get_node_name(struct fwnode_handle *fwnode)
+{
+ if (is_of_node(fwnode))
+ return of_node_full_name(to_of_node(fwnode));
+ return "unknown";
+}
+
+/*
+ * Extract a name from the fwnode.
+ * If the device associated with the node is a coresight_device, then return
+ * that name and the coresight_device pointer, otherwise return the node name.
+ */
+static const char *
+cti_plat_get_csdev_or_node_name(struct fwnode_handle *fwnode,
+ struct coresight_device **csdev)
+{
+ const char *name = NULL;
+ *csdev = coresight_find_csdev_by_fwnode(fwnode);
+ if (*csdev)
+ name = dev_name(&(*csdev)->dev);
+ else
+ name = cti_plat_get_node_name(fwnode);
+ return name;
+}
+
+static int cti_plat_create_v8_etm_connection(struct device *dev,
+ struct cti_drvdata *drvdata)
+{
+ int ret = -ENOMEM, i;
+ struct fwnode_handle *root_fwnode, *cs_fwnode;
+ const char *assoc_name = NULL;
+ struct coresight_device *csdev;
+ struct cti_trig_con *tc = NULL;
+
+ root_fwnode = dev_fwnode(dev);
+ if (IS_ERR_OR_NULL(root_fwnode))
+ return -EINVAL;
+
+ /* Can optionally have an etm node - return if not */
+ cs_fwnode = fwnode_find_reference(root_fwnode, CTI_DT_CSDEV_ASSOC, 0);
+ if (IS_ERR_OR_NULL(cs_fwnode))
+ return 0;
+
+ /* allocate memory */
+ tc = cti_allocate_trig_con(dev, NR_V8ETM_INOUT_SIGS,
+ NR_V8ETM_INOUT_SIGS);
+ if (!tc)
+ goto create_v8_etm_out;
+
+ /* build connection data */
+ tc->con_in->used_mask = 0xF0; /* sigs <4,5,6,7> */
+ tc->con_out->used_mask = 0xF0; /* sigs <4,5,6,7> */
+
+ /*
+ * The EXTOUT type signals from the ETM are connected to a set of input
+ * triggers on the CTI, the EXTIN being connected to output triggers.
+ */
+ for (i = 0; i < NR_V8ETM_INOUT_SIGS; i++) {
+ tc->con_in->sig_types[i] = ETM_EXTOUT;
+ tc->con_out->sig_types[i] = ETM_EXTIN;
+ }
+
+ /*
+ * We look to see if the ETM coresight device associated with this
+ * handle has been registered with the system - i.e. probed before
+ * this CTI. If so csdev will be non NULL and we can use the device
+ * name and pass the csdev to the connection entry function where
+ * the association will be recorded.
+ * If not, then simply record the name in the connection data, the
+ * probing of the ETM will call into the CTI driver API to update the
+ * association then.
+ */
+ assoc_name = cti_plat_get_csdev_or_node_name(cs_fwnode, &csdev);
+ ret = cti_add_connection_entry(dev, drvdata, tc, csdev, assoc_name);
+
+create_v8_etm_out:
+ fwnode_handle_put(cs_fwnode);
+ return ret;
+}
+
+/*
+ * Create an architecturally defined v8 connection
+ * must have a cpu, can have an ETM.
+ */
+static int cti_plat_create_v8_connections(struct device *dev,
+ struct cti_drvdata *drvdata)
+{
+ struct cti_device *cti_dev = &drvdata->ctidev;
+ struct cti_trig_con *tc = NULL;
+ int cpuid = 0;
+ char cpu_name_str[16];
+ int ret = -ENOMEM;
+
+ /* Must have a cpu node */
+ cpuid = cti_plat_get_cpu_at_node(dev_fwnode(dev));
+ if (cpuid < 0) {
+ dev_warn(dev,
+ "ARM v8 architectural CTI connection: missing cpu\n");
+ return -EINVAL;
+ }
+ cti_dev->cpu = cpuid;
+
+ /* Allocate the v8 cpu connection memory */
+ tc = cti_allocate_trig_con(dev, NR_V8PE_IN_SIGS, NR_V8PE_OUT_SIGS);
+ if (!tc)
+ goto of_create_v8_out;
+
+ /* Set the v8 PE CTI connection data */
+ tc->con_in->used_mask = 0x3; /* sigs <0 1> */
+ tc->con_in->sig_types[0] = PE_DBGTRIGGER;
+ tc->con_in->sig_types[1] = PE_PMUIRQ;
+ tc->con_out->used_mask = 0x7; /* sigs <0 1 2 > */
+ tc->con_out->sig_types[0] = PE_EDBGREQ;
+ tc->con_out->sig_types[1] = PE_DBGRESTART;
+ tc->con_out->sig_types[2] = PE_CTIIRQ;
+ scnprintf(cpu_name_str, sizeof(cpu_name_str), "cpu%d", cpuid);
+
+ ret = cti_add_connection_entry(dev, drvdata, tc, NULL, cpu_name_str);
+ if (ret)
+ goto of_create_v8_out;
+
+ /* Create the v8 ETM associated connection */
+ ret = cti_plat_create_v8_etm_connection(dev, drvdata);
+ if (ret)
+ goto of_create_v8_out;
+
+ /* filter pe_edbgreq - PE trigout sig <0> */
+ drvdata->config.trig_out_filter |= 0x1;
+
+of_create_v8_out:
+ return ret;
+}
+
+static int cti_plat_check_v8_arch_compatible(struct device *dev)
+{
+ struct fwnode_handle *fwnode = dev_fwnode(dev);
+
+ if (is_of_node(fwnode))
+ return of_device_is_compatible(to_of_node(fwnode),
+ CTI_DT_V8ARCH_COMPAT);
+ return 0;
+}
+
/* get the hardware configuration & connection data. */
int cti_plat_get_hw_data(struct device *dev,
struct cti_drvdata *drvdata)
@@ -14,6 +212,13 @@ int cti_plat_get_hw_data(struct device *dev,
int rc = 0;
struct cti_device *cti_dev = &drvdata->ctidev;
+ /* check for a v8 architectural CTI device */
+ if (cti_plat_check_v8_arch_compatible(dev)) {
+ rc = cti_plat_create_v8_connections(dev, drvdata);
+ if (rc)
+ return rc;
+ }
+
/* if no connections, just add a single default based on max IN-OUT */
if (cti_dev->nr_trig_con == 0)
rc = cti_add_default_connection(dev, drvdata);
diff --git a/drivers/hwtracing/coresight/coresight-platform.c b/drivers/hwtracing/coresight/coresight-platform.c
index 3c5bee429105..43418a2126ff 100644
--- a/drivers/hwtracing/coresight/coresight-platform.c
+++ b/drivers/hwtracing/coresight/coresight-platform.c
@@ -57,6 +57,26 @@ coresight_find_device_by_fwnode(struct fwnode_handle *fwnode)
return bus_find_device_by_fwnode(&amba_bustype, fwnode);
}
+/*
+ * Find a registered coresight device from a device fwnode.
+ * The node info is associated with the AMBA parent, but the
+ * csdev keeps a copy so iterate round the coresight bus to
+ * find the device.
+ */
+struct coresight_device *
+coresight_find_csdev_by_fwnode(struct fwnode_handle *r_fwnode)
+{
+ struct device *dev;
+ struct coresight_device *csdev = NULL;
+
+ dev = bus_find_device_by_fwnode(&coresight_bustype, r_fwnode);
+ if (dev) {
+ csdev = to_coresight_device(dev);
+ put_device(dev);
+ }
+ return csdev;
+}
+
#ifdef CONFIG_OF
static inline bool of_coresight_legacy_ep_is_input(struct device_node *ep)
{
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index aba6b789c969..357ffef7b825 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -202,5 +202,7 @@ static inline void *coresight_get_uci_data(const struct amba_id *id)
}
void coresight_release_platform_data(struct coresight_platform_data *pdata);
+struct coresight_device *
+coresight_find_csdev_by_fwnode(struct fwnode_handle *r_fwnode);
#endif
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 1a5fdf2710ff..39a5d9f7a395 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -1030,17 +1030,11 @@ static void coresight_fixup_device_conns(struct coresight_device *csdev)
for (i = 0; i < csdev->pdata->nr_outport; i++) {
struct coresight_connection *conn = &csdev->pdata->conns[i];
- struct device *dev = NULL;
- dev = bus_find_device_by_fwnode(&coresight_bustype, conn->child_fwnode);
- if (dev) {
- conn->child_dev = to_coresight_device(dev);
- /* and put reference from 'bus_find_device()' */
- put_device(dev);
- } else {
+ conn->child_dev =
+ coresight_find_csdev_by_fwnode(conn->child_fwnode);
+ if (!conn->child_dev)
csdev->orphan = true;
- conn->child_dev = NULL;
- }
}
}
--
2.17.1
Hi Joey,
Please provide more information on the problems you are encountering
and any errors you are seeing. Without this I cannot investigate
further.
1) How are you attempting to use OpenCSD to decode this file? The
trc_pkt_lister test program will provide the same packet decode as
PTMtoHuman but does require additional context to ensure that the
decode is correct. This involves providing the raw data and certain
ETMv4 registers in a "trace snapshot" format. The library comes with
examples in this format and a specification for this format in the
documentation.
2) If you wish to go beyond packet decode then OpenCSD can do that -
but you will need to provide additional program image data - again in
the snapshot format described above.
Thanks & Regards
Mike
On Tue, 10 Dec 2019 at 07:55, Joey Jiao <joeyjiaojg(a)163.com> wrote:
>
> Hi Mike,
> I cannot attach the dump into github, so I have to ask here.
>
> OpenCSD cannot decode the etm binary attached, however an opensource ETM decoder https://github.com/hwangcc23/ptm2human can parse.
>
> Can you help understand why?
>
> And is there any bug in OpenCSD?
>
> Thanks
>
> Joey
>
>
>
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
From: Leo Yan <leo.yan(a)linaro.org>
[ Upstream commit 9d604aad4bb022e848dec80d6fe5f73fe87061a2 ]
Macro TO_CS_QUEUE_NR definition has a typo, which uses 'trace_id_chan'
as its parameter, this doesn't match with its definition body which uses
'trace_chan_id'. So renames the parameter to 'trace_chan_id'.
It's luck to have a local variable 'trace_chan_id' in the function
cs_etm__setup_queue(), even we wrongly define the macro TO_CS_QUEUE_NR,
the local variable 'trace_chan_id' is used rather than the macro's
parameter 'trace_id_chan'; so the compiler doesn't complain for this
before.
After renaming the parameter, it leads to a compiling error due
cs_etm__setup_queue() has no variable 'trace_id_chan'. This patch uses
the variable 'trace_chan_id' for the macro so that fixes the compiling
error.
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: Mark Rutland <mark.rutland(a)arm.com>
Cc: Namhyung Kim <namhyung(a)kernel.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Suzuki Poulouse <suzuki.poulose(a)arm.com>
Cc: coresight ml <coresight(a)lists.linaro.org>
Cc: linux-arm-kernel(a)lists.infradead.org
Link: http://lore.kernel.org/lkml/20191021074808.25795-1-leo.yan@linaro.org
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 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 4ba0f871f086d..f5f855fff412e 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -110,7 +110,7 @@ static int cs_etm__decode_data_block(struct cs_etm_queue *etmq);
* encode the etm queue number as the upper 16 bit and the channel as
* the lower 16 bit.
*/
-#define TO_CS_QUEUE_NR(queue_nr, trace_id_chan) \
+#define TO_CS_QUEUE_NR(queue_nr, trace_chan_id) \
(queue_nr << 16 | trace_chan_id)
#define TO_QUEUE_NR(cs_queue_nr) (cs_queue_nr >> 16)
#define TO_TRACE_CHAN_ID(cs_queue_nr) (cs_queue_nr & 0x0000ffff)
@@ -819,7 +819,7 @@ static int cs_etm__setup_queue(struct cs_etm_auxtrace *etm,
* Note that packets decoded above are still in the traceID's packet
* queue and will be processed in cs_etm__process_queues().
*/
- cs_queue_nr = TO_CS_QUEUE_NR(queue_nr, trace_id_chan);
+ cs_queue_nr = TO_CS_QUEUE_NR(queue_nr, trace_chan_id);
ret = auxtrace_heap__add(&etm->heap, cs_queue_nr, timestamp);
out:
return ret;
--
2.20.1
Good day Joey,
I can spot several problems with your manipulations - please see below. I
also suggest to CC the coresight mailing list when looking for support.
On Tue, 10 Dec 2019 at 00:44, Joey Jiao <notifications(a)github.com> wrote:
> Hi,
> I have a arm64 device,
> perf list pmu
>
> List of pre-defined events (to be used in -e):
> cs_etm// [Kernel PMU event]
>
> However I cannot run perf record -e cs_etm successfully.
>
> can you help?
> ls /sys/bus/coresight/devices/|grep coresight-etm
>
> coresight-etm0
> coresight-etm1
> coresight-etm2
> coresight-etm3
> coresight-etm4
> coresight-etm5
> coresight-etm6
> coresight-etm7
>
We will need a full list of all the CS devices on your system. Just
listing the ETMs is not sufficient.
> #2 <https://github.com/Linaro/perf-opencsd/issues/2> ls -l
> /sys/bus/coresight/devices/coresight-etm0
> lrwxrwxrwx. 1 root root 0 Dec 7 16:58
> /sys/bus/coresight/devices/coresight-etm0 ->
> ../../../devices/platform/soc/7040000.etm/coresight-etm0
> perf record -e cs_etm ls
>
> event syntax error: 'cs_etm'
> ___ parser error
> Run 'perf list' for a list of valid events
>
> Usage: perf record [] []
> or: perf record [] -- []
>
> -e, --event <event> event selector. use 'perf list' to list available events
>
>
Yes, that is the expected behavior. On systems with a 1:N topology a sink
needs to be specified. System with 1:1 topologies aren't supported, hence
the request to see all the CS devices on your system (above).
> perf record -e cs_etm/7040000.etm/ ls
>
> event syntax error: 'cs_etm/7040000.etm/'
> ___ parser error
> Run 'perf list' for a list of valid events
>
> Usage: perf record [] []
> or: perf record [] -- []
>
> -e, --event <event> event selector. use 'perf list' to list available events
>
>
Also incorrect. First the sink needs to be preceded by '@' and actually be
a sink - here you have specified a source. Before going further I advise
you to spend some time in the documentation [1].
Thanks,
Mathieu
[1].
https://elixir.bootlin.com/linux/v5.5-rc1/source/Documentation/trace/coresi…
> perf record -e cs_etm/(a)7040000.etm/ ls
>
> failed to set config "7040000.etm" on event cs_etm/(a)7040000.etm/ with 2
> (No such file or directory)
>
I can cat /dev/coresight-tmc-etr > dump.bin after enabled ETM, but perf
> doesn't work as above stated.
>
> Thanks
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/Linaro/perf-opencsd/issues/3?email_source=notifications&…>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAELPW5NE5EXRUA7F3274G3QX…>
> .
>
Hi everyone,
since it seems very hard to get valuable information from vendors about
the CoreSight capabilities of their SoC's, I was wondering if anyone has
recommendations for development boards.
I started with the dragonboard 410c which I can definitely recommend for
learning and first SW projects with CS due to the low price and
well-working Debian support (and it actually had vendor documentation on
CS).
But the board and CoreSight features (especially ETMv4 capabilities) are
somewhat limited. I am especially missing the conditional non-branch
tracing.
Also, I would be very interested in testing the "new" SoC-600
features/improvements.
After some research on higher-end development-boards, the only
informative resource I found are the device tree source files in the
linux and android kernels, which at least give an overview of the
components implemented for several SoCs.
Currently, I was looking at the Open-Q 820 or Open-Q 845 so I would be
happy to hear any experiences with CoreSight on these boards
(SoC-400/600? ETMv4 capabilities? SW Support?).
Other suggestions/recommendations are also very welcomed!
Thank you in advance!
Robin Röhrig
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.
The driver accesses these in a platform agnostic manner, so ACPI bindings
can be added later, once they have been agreed and defined for the CTI device.
Documentation has been updated to describe both the CTI hardware, its use and
programming in sysfs, and the new dts bindings required.
Tested on DB410 board.
Applies on coresight/next tree after following dependent set applied for
documentation directory changes [1]. Kernel version 5.4-rc7.
[1] https://www.spinics.net/lists/linux-doc/msg71062.html
Changes since v4:
Multiple changes following feedback from Mathieu, Leo and Suzuki.
1) Dropped RFC tag - wider distribution
2) CTI bindings definition now presented as a .yaml file - tested with
with 'dt-doc-validate' from devicetree.org/dt-schema project and in kernel
build tree with 'make dtbs_check' per kernel docs.
3) Sysfs links to other CoreSight devices moved out of this set into
a following set that deals with all CoreSight devices & sysfs links.
4) Documentation in .rst format and new directory following patchset in [1].
Extended example provided in docs.
5) Rationalised devicetree of_ specifics to use generic fwnode functions
where possible to enable easier addition of ACPI support later.
6) Other minor changes as requested in feedback from last patchset.
Changes since v3:
1) After discussion on CS mailing list, each CTI connection has a triggers<N>
sysfs directory with name and trigger signals listed for the connection.
2) Initial code for creating sysfs links between CoreSight components is
introduced and implementation for CTI provided. This allows exploration
of the CoreSight topology within the sysfs infrastructure. Patches for
links between other CoreSight components to follow.
3) Power management - CPU hotplug and idle omitted from this set as ongoing
developments may define required direction. Additional patch set to follow.
4) Multiple fixes applied as requested by reviewers esp. Matthieu, Suzuki
and Leo.
Changes since v2:
Updates to allow for new features on coresight/next and feedback from
Mathieu and Leo.
1) Rebase and restructuring to apply on top of ACPI support patch set,
currently on coresight/next. of_coresight_cti has been renamed to
coresight-cti-platform and device tree bindings added to this but accessed
in a platform agnostic manner using fwnode for later ACPI support
to be added.
2) Split the sysfs patch info a series of functional patches.
3) Revised the refcount and enabling support.
4) Adopted the generic naming protocol - CTIs are either cti_cpuN or
cti_sysM
5) Various minor presentation /checkpatch issues highlighted in feedback.
6) revised CPU hotplug to cover missing cases needed by ETM.
Changes since v1:
1) Significant restructuring of the source code. Adds cti-sysfs file and
cti device tree file. Patches add per feature rather than per source
file.
2) CPU type power event handling for hotplug moved to CoreSight core,
with generic registration interface provided for all CPU bound CS devices
to use.
3) CTI signal interconnection details in sysfs now generated dynamically
from connection lists in driver. This to fix issue with multi-line sysfs
output in previous version.
4) Full device tree bindings for DB410 and Juno provided (to the extent
that CTI information is available).
5) AMBA driver update for UCI IDs are now upstream so no longer included
in this set.
Mike Leach (14):
coresight: cti: Initial CoreSight CTI Driver
coresight: cti: Add sysfs coresight mgmt reg access.
coresight: cti: Add sysfs access to program function regs
coresight: cti: Add sysfs trigger / channel programming API
dt-bindings: arm: Adds CoreSight CTI hardware definitions.
coresight: cti: Add device tree support for v8 arch CTI
coresight: cti: Add device tree support for custom CTI.
coresight: cti: Enable CTI associated with devices.
coresight: cti: Add connection information to sysfs
dt-bindings: qcom: Add CTI options for qcom msm8916
dt-bindings: arm: Juno platform - add CTI entries to device tree.
dt-bindings: hisilicon: Add CTI bindings for hi-6220
docs: coresight: Update documentation for CoreSight to cover CTI.
docs: sysfs: coresight: Add sysfs ABI documentation for CTI
.../testing/sysfs-bus-coresight-devices-cti | 221 +++
.../bindings/arm/coresight-cti.yaml | 303 ++++
.../devicetree/bindings/arm/coresight.txt | 7 +
.../trace/coresight/coresight-ect.rst | 200 +++
Documentation/trace/coresight/coresight.rst | 13 +
MAINTAINERS | 2 +
arch/arm64/boot/dts/arm/juno-base.dtsi | 150 +-
arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 31 +-
arch/arm64/boot/dts/arm/juno-r1.dts | 25 +
arch/arm64/boot/dts/arm/juno-r2.dts | 25 +
arch/arm64/boot/dts/arm/juno.dts | 25 +
.../boot/dts/hisilicon/hi6220-coresight.dtsi | 130 +-
arch/arm64/boot/dts/qcom/msm8916.dtsi | 85 +-
drivers/hwtracing/coresight/Kconfig | 12 +
drivers/hwtracing/coresight/Makefile | 3 +
.../coresight/coresight-cti-platform.c | 500 +++++++
.../hwtracing/coresight/coresight-cti-sysfs.c | 1219 +++++++++++++++++
drivers/hwtracing/coresight/coresight-cti.c | 712 ++++++++++
drivers/hwtracing/coresight/coresight-cti.h | 232 ++++
.../hwtracing/coresight/coresight-platform.c | 23 +
drivers/hwtracing/coresight/coresight-priv.h | 7 +
drivers/hwtracing/coresight/coresight.c | 61 +-
include/dt-bindings/arm/coresight-cti-dt.h | 37 +
include/linux/coresight.h | 28 +
24 files changed, 4028 insertions(+), 23 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-cti
create mode 100644 Documentation/devicetree/bindings/arm/coresight-cti.yaml
create mode 100644 Documentation/trace/coresight/coresight-ect.rst
create mode 100644 drivers/hwtracing/coresight/coresight-cti-platform.c
create mode 100644 drivers/hwtracing/coresight/coresight-cti-sysfs.c
create mode 100644 drivers/hwtracing/coresight/coresight-cti.c
create mode 100644 drivers/hwtracing/coresight/coresight-cti.h
create mode 100644 include/dt-bindings/arm/coresight-cti-dt.h
--
2.17.1
hi,I started implementing GDB process record and replay with ARM CoreSight as described in the rfc published early this year. Current implementation of coresight tracing in Perf is based on the sysfs interface, by accessing /sys/bus/event_source/devices/cs_etm ... file. GDB implementation of bts and ipt is based on the syscall "sys_perf_event_open".it would be nice to use the similar mechanism for realizing similar functionalities. therefore I would like to know if linux kernel (with coresight deivers) is exposing coresight drivers through the syscall sys_perf_event_open and if this is the case how shall I configure the perf_event_attr to use it.
thanks Zied Guermazi