CoreSight

coresight@lists.linaro.org

6 participants
2592 discussions

[PATCH AUTOSEL 5.4 219/350] perf cs-etm: Fix definition of macro TO_CS_QUEUE_NR

by Sasha Levin

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

6 years

Re: [Linaro/perf-opencsd] perf record -e cs_etm not work (#3)

by Mathieu Poirier

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…> > . >

6 years

development board recommendations

by Robin Röhrig

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

6 years

[PATCH v5 00/14] CoreSight CTI Driver

by Mike Leach

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

6 years

coresight drivers access from syscall interface

by zied guermazi

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

6 years

[PATCH v2 0/6] Describe CoreSight topology using sysfs links.

by Mike Leach

The connections between CoreSight sources, links and sinks is not obvious without documentation or access to the device tree / ACPI definitions for the platform. This patchset provides sysfs links to enable the user to follow the trace patch from source to sink. Components in the trace path are updated to have a connections sysfs group, which collates all the links for that component. The CTI components which exist aside from the main trace patch, also have an added connections directory showing connections to other CoreSight devices. This patchset applies on top of the recent CTI patchset [1]. Adaptation of an original patchset [2] from Suzuki, reusing 2 patches unchanged with update to 3rd adapt to the new common code for trace path and CTI component links & add a default connections group. Tested on Juno r1, DB410c 5.4-rc7, coresight/next branch. [1] https://lists.linaro.org/pipermail/coresight/2019-November/003414.html [2] https://lists.linaro.org/pipermail/coresight/2019-May/002803.html Changes since v1: 1) Code from original v4 CTI set moved here so that all connections related code in this set. 2) Connections directory mandatory for all CoreSight components and generated as part of the registration process. Mike Leach (3): coresight: Add generic sysfs link creation functions. coresight: cti: Add in sysfs links to other coresight devices. coresight: docs: Add information about the topology representations. Suzuki K Poulose (3): coresight: Pass coresight_device for coresight_release_platform_data coresight: add return value for fixup connections coresight: Expose device connections via sysfs .../trace/coresight/coresight-ect.rst | 5 +- Documentation/trace/coresight/coresight.rst | 85 ++++++++ drivers/hwtracing/coresight/Makefile | 3 +- drivers/hwtracing/coresight/coresight-cti.c | 44 +++- .../hwtracing/coresight/coresight-platform.c | 2 +- drivers/hwtracing/coresight/coresight-priv.h | 12 +- drivers/hwtracing/coresight/coresight-sysfs.c | 203 ++++++++++++++++++ drivers/hwtracing/coresight/coresight.c | 72 ++++--- include/linux/coresight.h | 22 ++ 9 files changed, 417 insertions(+), 31 deletions(-) create mode 100644 drivers/hwtracing/coresight/coresight-sysfs.c -- 2.20.1

6 years

OpenCSD - release 0.12.1

by Mike Leach

OpenCSD library version 0.12.1 is released. Changes:- 1) Snapshots can now have generic core type names that reflect architecture and profile. e,g, ARMv8-A. 2) Bugfix - certain classes of authenticated pointer instructions were not being recognised as P0 elements locations. 3) Bugfix - if a trace implementation represented the transition between A64 & A32 as an address packet followed by a separate context packet then decode could fail in some cases. Most implementations use a combined Address+Context packet. Mike -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

6 years

Re: [PATCH 4/5] coresight: Expose device connections via sysfs

by Mathieu Poirier

On Thu, Oct 03, 2019 at 02:07:51PM -0600, Mathieu Poirier wrote: > From: Suzuki K Poulose <suzuki.poulose(a)arm.com> > > Coresight device connections are a bit complicated and is not > exposed currently to the user. One has to look at the platform > descriptions (DT bindings or ACPI bindings) to make an understanding. > Given the new naming scheme, it will be helpful to have this information > to choose the appropriate devices for tracing. This patch exposes > the device connections via links in the sysfs directories. > > e.g, for a connection devA[OutputPort_X] -> devB[InputPort_Y] > is represented as two symlinks: > > /sys/bus/coresight/.../devA/out:X -> /sys/bus/coresight/.../devB > /sys/bus/coresight/.../devB/in:Y -> /sys/bus/coresight/.../devA > > Provides default connections group if requested for any CoreSight device > using the coresight_connections structure. > > If a connections group is present on a device then links are collated > there. > > Co-developed-by: Mike Leach <mike.leach(a)linaro.org> > Signed-off-by: Mike Leach <mike.leach(a)linaro.org> > Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> > Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> > --- > drivers/hwtracing/coresight/coresight-priv.h | 7 + > drivers/hwtracing/coresight/coresight-sysfs.c | 150 ++++++++++++++++++ > drivers/hwtracing/coresight/coresight.c | 42 +++-- > include/linux/coresight.h | 7 + > 4 files changed, 195 insertions(+), 11 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h > index fa4b02ed3900..120928db426a 100644 > --- a/drivers/hwtracing/coresight/coresight-priv.h > +++ b/drivers/hwtracing/coresight/coresight-priv.h > @@ -155,6 +155,13 @@ struct list_head *coresight_build_path(struct coresight_device *csdev, > void coresight_release_path(struct list_head *path); > int coresight_add_sysfs_link(struct coresight_sysfs_link *info); > void coresight_remove_sysfs_link(struct coresight_sysfs_link *info); > +int coresight_make_links(struct coresight_device *orig, > + struct coresight_connection *conn, > + struct coresight_device *target); > +void coresight_remove_links(struct coresight_device *orig, > + struct coresight_connection *conn); > +int coresight_create_conns_sysfs_group(struct coresight_device *csdev); > +void coresight_remove_conns_sysfs_group(struct coresight_device *csdev); > > #ifdef CONFIG_CORESIGHT_SOURCE_ETM3X > extern int etm_readl_cp14(u32 off, unsigned int *val); > diff --git a/drivers/hwtracing/coresight/coresight-sysfs.c b/drivers/hwtracing/coresight/coresight-sysfs.c > index 058a092ba75f..f2ece44e2158 100644 > --- a/drivers/hwtracing/coresight/coresight-sysfs.c > +++ b/drivers/hwtracing/coresight/coresight-sysfs.c > @@ -80,3 +80,153 @@ void coresight_remove_sysfs_link(struct coresight_sysfs_link *info) > info->target_name, > info->target->sysfs_link_grp); > } > + > +/* > + * coresight_make_links: Make a link for a connection from a @orig > + * device to @target, represented by @conn. > + * > + * e.g, for devOrig[output_X] -> devTarget[input_Y] is represented > + * as two symbolic links : > + * > + * /sys/.../devOrig/out:X -> /sys/.../devTarget/ > + * /sys/.../devTarget/in:Y -> /sys/.../devOrig/ > + * > + * The link names are allocated for a device where it appears. i.e, the > + * "out" link on the master and "in" link on the slave device. > + * The link info is stored in the connection record for avoiding > + * the reconstruction of names for removal. > + */ > +int coresight_make_links(struct coresight_device *orig, > + struct coresight_connection *conn, > + struct coresight_device *target) > +{ > + int ret = -ENOMEM; > + char *outs = NULL, *ins = NULL; > + struct coresight_sysfs_link *link = NULL; > + > + do { > + outs = devm_kasprintf(&orig->dev, GFP_KERNEL, > + "out:%d", conn->outport); > + if (!outs) > + break; > + ins = devm_kasprintf(&target->dev, GFP_KERNEL, > + "in:%d", conn->child_port); > + if (!ins) > + break; > + link = devm_kzalloc(&orig->dev, > + sizeof(struct coresight_sysfs_link), > + GFP_KERNEL); > + if (!link) > + break; > + > + link->orig = orig; > + link->target = target; > + link->orig_name = outs; > + link->target_name = ins; > + > + ret = coresight_add_sysfs_link(link); > + if (ret) > + break; > + > + conn->link = link; > + > + /* > + * Install the device connection. This also indicates that > + * the links are operational on both ends. > + */ > + conn->child_dev = target; > + return 0; > + } while (0); > + > + if (outs) > + devm_kfree(&orig->dev, outs); > + if (ins) > + devm_kfree(&target->dev, ins); > + if (link) > + devm_kfree(&orig->dev, link); We should have to worry about freeing things if making a link fails. Device probing should fair and the memory released automatically since devm_kasprintf() was used. > + return ret; > +} > + > +/* > + * coresight_remove_links: Remove the sysfs links for a given connection @conn, > + * from @orig device to @target device. See coresight_make_links() for more > + * details. > + */ > +void coresight_remove_links(struct coresight_device *orig, > + struct coresight_connection *conn) > +{ > + if (!orig || !conn->link) > + return; > + > + coresight_remove_sysfs_link(conn->link); > + > + devm_kfree(&conn->child_dev->dev, conn->link->target_name); > + devm_kfree(&orig->dev, conn->link->orig_name); > + devm_kfree(&orig->dev, conn->link); > + conn->link = NULL; > + conn->child_dev = NULL; > +} > + > +static ssize_t nr_outports_show(struct device *dev, > + struct device_attribute *attr, > + char *buf) > +{ > + struct coresight_device *csdev = to_coresight_device(dev); > + > + return scnprintf(buf, PAGE_SIZE, "%d\n", csdev->pdata->nr_outport); > +} > +static DEVICE_ATTR_RO(nr_outports); > + > +static ssize_t nr_inports_show(struct device *dev, > + struct device_attribute *attr, > + char *buf) > +{ > + struct coresight_device *csdev = to_coresight_device(dev); > + > + return scnprintf(buf, PAGE_SIZE, "%d\n", csdev->pdata->nr_inport); > +} > +static DEVICE_ATTR_RO(nr_inports); > + > +static struct attribute *coresight_conns_attrs[] = { > + &dev_attr_nr_outports.attr, > + &dev_attr_nr_inports.attr, > + NULL, > +}; > + > +static struct attribute_group coresight_conns_group = { > + .attrs = coresight_conns_attrs, > + .name = "connections", > +}; Since those are present for all CS device, I would put this in the coresight_dev_type[] for all the CS devices, except etc. By proceeding this way we don't need coresight_create_conns_sysfs_group() and coresight_remove_conns_sysfs_group(). > + > +/* > + * Create connections group for CoreSight devices on the trace path > + * which use inports and outports to represent connections. > + * This group will then be used to collate the sysfs links between > + * devices. > + */ > +int coresight_create_conns_sysfs_group(struct coresight_device *csdev) > +{ > + int ret = 0; > + > + if (!csdev) > + return -EINVAL; > + > + ret = sysfs_create_group(&csdev->dev.kobj, &coresight_conns_group); > + if (ret) > + return ret; > + > + csdev->sysfs_link_grp = coresight_conns_group.name; > + csdev->default_conns_grp = true; > + return ret; > +} > + > +void coresight_remove_conns_sysfs_group(struct coresight_device *csdev) > +{ > + if (!csdev) > + return; > + > + if (csdev->sysfs_link_grp && csdev->default_conns_grp) { > + sysfs_remove_group(&csdev->dev.kobj, &coresight_conns_group); > + csdev->sysfs_link_grp = NULL; > + } > +} > diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c > index 1e75cc7203b5..e6e1850a6e96 100644 > --- a/drivers/hwtracing/coresight/coresight.c > +++ b/drivers/hwtracing/coresight/coresight.c > @@ -1034,7 +1034,7 @@ static void coresight_device_release(struct device *dev) > > static int coresight_orphan_match(struct device *dev, void *data) > { > - int i; > + int i, ret = 0; > bool still_orphan = false; > struct coresight_device *csdev, *i_csdev; > struct coresight_connection *conn; > @@ -1059,19 +1059,23 @@ static int coresight_orphan_match(struct device *dev, void *data) > /* We have found at least one orphan connection */ > if (conn->child_dev == NULL) { > /* Does it match this newly added device? */ > - if (conn->child_fwnode == csdev->dev.fwnode) > - conn->child_dev = csdev; > - else > + if (conn->child_fwnode == csdev->dev.fwnode) { > + ret = coresight_make_links(i_csdev, > + conn, csdev); > + if (ret) > + return ret; > + } else { > /* This component still has an orphan */ > still_orphan = true; > + } > } > } > > i_csdev->orphan = still_orphan; > > /* > - * Returning '0' ensures that all known component on the > - * bus will be checked. > + * Returning '0' in case we didn't encounter any error, > + * ensures that all known component on the bus will be checked. > */ > return 0; > } > @@ -1085,7 +1089,7 @@ static int coresight_fixup_orphan_conns(struct coresight_device *csdev) > > static int coresight_fixup_device_conns(struct coresight_device *csdev) > { > - int i; > + int i, ret = 0; > > for (i = 0; i < csdev->pdata->nr_outport; i++) { > struct coresight_connection *conn = &csdev->pdata->conns[i]; > @@ -1093,9 +1097,12 @@ static int coresight_fixup_device_conns(struct coresight_device *csdev) > > dev = bus_find_device_by_fwnode(&coresight_bustype, conn->child_fwnode); > if (dev) { > - conn->child_dev = to_coresight_device(dev); > + ret = coresight_make_links(csdev, conn, > + to_coresight_device(dev)); > /* and put reference from 'bus_find_device()' */ > put_device(dev); > + if (ret) > + break; > } else { > csdev->orphan = true; > conn->child_dev = NULL; > @@ -1130,7 +1137,7 @@ static int coresight_remove_match(struct device *dev, void *data) > > if (csdev->dev.fwnode == conn->child_fwnode) { > iterator->orphan = true; > - conn->child_dev = NULL; > + coresight_remove_links(iterator, conn); > /* > * Drop the reference to the handle for the remote > * device acquired in parsing the connections from > @@ -1224,13 +1231,23 @@ void coresight_release_platform_data(struct coresight_device *csdev, > struct coresight_platform_data *pdata) > { > int i; > + struct coresight_connection *conns = pdata->conns; > > for (i = 0; i < pdata->nr_outport; i++) { > - if (pdata->conns[i].child_fwnode) { > - fwnode_handle_put(pdata->conns[i].child_fwnode); > + /* If we have made the links, remove them now */ > + if (csdev && conns[i].child_dev) > + coresight_remove_links(csdev, &conns[i]); > + /* > + * Drop the refcount and clear the handle as this device > + * is going away > + */ > + if (conns[i].child_fwnode) { > + fwnode_handle_put(conns[i].child_fwnode); > pdata->conns[i].child_fwnode = NULL; > } > } > + if (csdev) > + coresight_remove_conns_sysfs_group(csdev); > } > > struct coresight_device *coresight_register(struct coresight_desc *desc) > @@ -1312,6 +1329,9 @@ struct coresight_device *coresight_register(struct coresight_desc *desc) > > mutex_lock(&coresight_mutex); > > + if (desc->add_conns_group) > + ret = coresight_create_conns_sysfs_group(csdev); > + > ret = coresight_fixup_device_conns(csdev); > if (!ret) > ret = coresight_fixup_orphan_conns(csdev); > diff --git a/include/linux/coresight.h b/include/linux/coresight.h > index cd0d92611be6..95634d4ce7ff 100644 > --- a/include/linux/coresight.h > +++ b/include/linux/coresight.h > @@ -122,6 +122,8 @@ struct coresight_platform_data { > * @groups: operations specific to this component. These will end up > * in the component's sysfs sub-directory. > * @name: name for the coresight device, also shown under sysfs. > + * @add_conns_group: Dynamically add default connections group to the supplied > + * groups. > */ > struct coresight_desc { > enum coresight_dev_type type; > @@ -131,6 +133,7 @@ struct coresight_desc { > struct device *dev; > const struct attribute_group **groups; > const char *name; > + bool add_conns_group; I don't think we need this since displaying connection information should be mandatory. > }; > > /** > @@ -140,12 +143,14 @@ struct coresight_desc { > * @chid_fwnode: remote component's fwnode handle. > * @child_dev: a @coresight_device representation of the component > connected to @outport. > + * @link: Representation of the connection as a sysfs link. > */ > struct coresight_connection { > int outport; > int child_port; > struct fwnode_handle *child_fwnode; > struct coresight_device *child_dev; > + struct coresight_sysfs_link *link; > }; > > /** > @@ -182,6 +187,7 @@ struct coresight_sysfs_link { > * @sysfs_link_grp: Optional name for a group created to add sysfs links into > * on this device. Group must have been created on device > * registration. > + * @default_conns_grp: Added a default connections group. > */ > struct coresight_device { > struct coresight_platform_data *pdata; > @@ -198,6 +204,7 @@ struct coresight_device { > /* cross trigger handling */ > struct coresight_device *ect_dev; > const char *sysfs_link_grp; > + bool default_conns_grp; Same here. > }; > > /* > -- > 2.17.1 >

6 years, 1 month

Re: [PATCH 5/5] coresight: add default connections group in sysfs to components.

by Mathieu Poirier

On Thu, Oct 03, 2019 at 02:07:52PM -0600, Mathieu Poirier wrote: > From: Mike Leach <mike.leach(a)linaro.org> > > Add the default connections group in sysfs to etm4x, etm3x, stm, tmc, > funnel and replicator components. > > This group will be used to collate the sysfs links representing the trace > data path to and from the devices. When booting this set on my Juno R0, probing each CTI result in a bracktrace like the following: [ 5.708275] sysfs: cannot create duplicate filename '/devices/platform/22020000.cti/cti_cpu1/connections' [ 5.717760] CPU: 2 PID: 42 Comm: kworker/2:1 Not tainted 5.3.0-04961-gb632d2fadfdd #279 [ 5.725679] Hardware name: ARM Juno development board (r0) (DT) [ 5.731543] Workqueue: events amba_deferred_retry_func [ 5.736625] Call trace: [ 5.739044] dump_backtrace+0x0/0x150 [ 5.742664] show_stack+0x14/0x20 [ 5.745942] dump_stack+0xb0/0xf4 [ 5.749218] sysfs_warn_dup+0x5c/0x78 [ 5.752839] internal_create_group+0x394/0x3d8 [ 5.757232] sysfs_create_group+0x14/0x20 [ 5.761199] coresight_create_conns_sysfs_group+0x24/0x50 [ 5.766538] coresight_register+0x2d4/0x378 [ 5.770674] cti_probe+0x158/0x380 [ 5.774035] amba_probe+0xb0/0x158 [ 5.777399] really_probe+0xdc/0x358 [ 5.780933] driver_probe_device+0x58/0x100 [ 5.785069] __device_attach_driver+0x90/0xb0 [ 5.789377] bus_for_each_drv+0x64/0xc8 [ 5.793169] __device_attach+0xd8/0x138 [ 5.796960] device_initial_probe+0x10/0x18 [ 5.801096] bus_probe_device+0x90/0x98 [ 5.804887] device_add+0x3c4/0x620 [ 5.808335] amba_device_try_add+0x1c0/0x378 [ 5.812556] amba_deferred_retry_func+0x48/0xd0 [ 5.817036] process_one_work+0x1e0/0x350 [ 5.820999] worker_thread+0x40/0x480 [ 5.824619] kthread+0x124/0x128 [ 5.827809] ret_from_fork+0x10/0x18 I am done reviewing both your sets. Thanks and best, Mathieu > > Signed-off-by: Mike Leach <mike.leach(a)linaro.org> > --- > drivers/hwtracing/coresight/coresight-etm3x.c | 1 + > drivers/hwtracing/coresight/coresight-etm4x.c | 1 + > drivers/hwtracing/coresight/coresight-funnel.c | 1 + > drivers/hwtracing/coresight/coresight-replicator.c | 1 + > drivers/hwtracing/coresight/coresight-stm.c | 1 + > drivers/hwtracing/coresight/coresight-tmc.c | 1 + > 6 files changed, 6 insertions(+) > > diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c > index e2cb6873c3f2..aa017ed1e2fe 100644 > --- a/drivers/hwtracing/coresight/coresight-etm3x.c > +++ b/drivers/hwtracing/coresight/coresight-etm3x.c > @@ -864,6 +864,7 @@ static int etm_probe(struct amba_device *adev, const struct amba_id *id) > desc.pdata = pdata; > desc.dev = dev; > desc.groups = coresight_etm_groups; > + desc.add_conns_group = true; > drvdata->csdev = coresight_register(&desc); > if (IS_ERR(drvdata->csdev)) { > ret = PTR_ERR(drvdata->csdev); > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c > index a128b5063f46..7d94096191c3 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x.c > @@ -1160,6 +1160,7 @@ static int etm4_probe(struct amba_device *adev, const struct amba_id *id) > desc.pdata = pdata; > desc.dev = dev; > desc.groups = coresight_etmv4_groups; > + desc.add_conns_group = true; > drvdata->csdev = coresight_register(&desc); > if (IS_ERR(drvdata->csdev)) { > ret = PTR_ERR(drvdata->csdev); > diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c > index 05f7896c3a01..9cdbfb75a246 100644 > --- a/drivers/hwtracing/coresight/coresight-funnel.c > +++ b/drivers/hwtracing/coresight/coresight-funnel.c > @@ -238,6 +238,7 @@ static int funnel_probe(struct device *dev, struct resource *res) > desc.ops = &funnel_cs_ops; > desc.pdata = pdata; > desc.dev = dev; > + desc.add_conns_group = true; > drvdata->csdev = coresight_register(&desc); > if (IS_ERR(drvdata->csdev)) { > ret = PTR_ERR(drvdata->csdev); > diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c > index b29ba640eb25..eac2690c0fda 100644 > --- a/drivers/hwtracing/coresight/coresight-replicator.c > +++ b/drivers/hwtracing/coresight/coresight-replicator.c > @@ -230,6 +230,7 @@ static int replicator_probe(struct device *dev, struct resource *res) > desc.ops = &replicator_cs_ops; > desc.pdata = dev->platform_data; > desc.dev = dev; > + desc.add_conns_group = true; > > drvdata->csdev = coresight_register(&desc); > if (IS_ERR(drvdata->csdev)) { > diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c > index b908ca104645..5a7c7b43d48c 100644 > --- a/drivers/hwtracing/coresight/coresight-stm.c > +++ b/drivers/hwtracing/coresight/coresight-stm.c > @@ -933,6 +933,7 @@ static int stm_probe(struct amba_device *adev, const struct amba_id *id) > desc.pdata = pdata; > desc.dev = dev; > desc.groups = coresight_stm_groups; > + desc.add_conns_group = true; > drvdata->csdev = coresight_register(&desc); > if (IS_ERR(drvdata->csdev)) { > ret = PTR_ERR(drvdata->csdev); > diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c > index 1cf82fa58289..b656c1b58735 100644 > --- a/drivers/hwtracing/coresight/coresight-tmc.c > +++ b/drivers/hwtracing/coresight/coresight-tmc.c > @@ -519,6 +519,7 @@ static int tmc_probe(struct amba_device *adev, const struct amba_id *id) > } > adev->dev.platform_data = pdata; > desc.pdata = pdata; > + desc.add_conns_group = true; > > drvdata->csdev = coresight_register(&desc); > if (IS_ERR(drvdata->csdev)) { > -- > 2.17.1 >

6 years, 1 month

[RFC PATCH v4 00/15] CoreSight CTI driver

by Mike Leach

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 - 5.3-rc1 based. Changes since v3: * After discussion on CS mailing list, each CTI connection has a triggers<N> sysfs directory with name and trigger signals listed for the connection. * 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. * Power management - CPU hotplug and idle omitted from this set as ongoing developments may define required direction. Additional patch set to follow. * 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 (15): 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 coresight: Add generic sysfs link creation functions. coresight: cti: Add in sysfs links to other coresight devices. dt-bindings: qcom: Add CTI options for qcom msm8916 dt-bindings: arm: Juno platform - add CTI entries to device tree. docs: coresight: Update documentation for CoreSight to cover CTI. docs: sysfs: coresight: Add sysfs documentation for CTI .../testing/sysfs-bus-coresight-devices-cti | 231 ++++ .../bindings/arm/coresight-ect-cti.txt | 396 ++++++ .../devicetree/bindings/arm/coresight.txt | 7 + Documentation/trace/coresight-ect.txt | 164 +++ Documentation/trace/coresight.txt | 7 + MAINTAINERS | 3 + arch/arm64/boot/dts/arm/juno-base.dtsi | 149 +- 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 + arch/arm64/boot/dts/qcom/msm8916.dtsi | 85 +- drivers/hwtracing/coresight/Kconfig | 12 + drivers/hwtracing/coresight/Makefile | 4 + .../coresight/coresight-cti-platform.c | 431 ++++++ .../hwtracing/coresight/coresight-cti-sysfs.c | 1199 +++++++++++++++++ drivers/hwtracing/coresight/coresight-cti.c | 763 +++++++++++ drivers/hwtracing/coresight/coresight-cti.h | 238 ++++ .../hwtracing/coresight/coresight-platform.c | 23 + drivers/hwtracing/coresight/coresight-priv.h | 10 + drivers/hwtracing/coresight/coresight.c | 133 +- include/dt-bindings/arm/coresight-cti-dt.h | 36 + include/linux/coresight.h | 46 + 23 files changed, 4029 insertions(+), 14 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-cti create mode 100644 Documentation/devicetree/bindings/arm/coresight-ect-cti.txt create mode 100644 Documentation/trace/coresight-ect.txt 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

6 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight