CoreSight

coresight@lists.linaro.org

5 participants
2627 discussions

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

by Greg Kroah-Hartman

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

7 years

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

by Leo Yan

This patch seris adds support for sample flags so can facilitate perf to print sample flags for branch instruction. Patch 0001 is used to save last branch information in packet structure, this includes instruction type, subtype and condition flag to help making decision for which branch instruction it is. It passes related information from decoder layer to cs-etm.c, so we use cs-etm.c as a central place to set sample flags. Patch 0002 is used to set sample flags for instruction range packet. Patch 0003 is used to set sample flags for trace discontinuity packet. Patches 0004/0005/0006 are preparation for exception packet handling: Patch 0004 addes exception number in packet; pacth 0005/0006 is to use traceID/metadata tuple to access metadata pointer based on traceID, this can help decide if the CPU is connected with ETMv3 or ETMv4, ETMv3 and ETMv4 have totally different definition for exception numbers. Patch 0007 sets sample flags for exception packet; patch 0008 support sample flags for exception return packet. This patch series is applied on the acme's perf core branch with the with latest commit 02bb912ae451 ("perf tools: Replace automatic const char[] variables by statics"). After applying this patch series, we can verify sample flags with below command: # perf script -F,-time,+flags,+ip,+sym,+dso,+addr,+symoff -k vmlinux Changes from v5: * Addressed Rob's suggestion to add specification info for exception number encoding; * Added Rob's review tag in patch 0007. Changes from v4: * Fixed typos in comments, and removed redundant info from commit log; * Addressed Mathieu's suggestion to add helper functions for metadata fields (CS_ETM_CPU and CS_ETM_MAGIC) accessing; * Addressed Mathieu's suggestion to include headers with alphabetical order. Changes from v3: * Fixed typos in commit logs; * Rearranged fields in cs_etm_packet by grouping with same variable types; * Fixed ETMv4 exception number which pointed by Mike; * Fixed ETMv4 SVC / SMC / HVC in the same CALL, by checking svc instruction to distinguish them; * Refine ETMv4 return exception packet handling. Changes from v2: * Addressed Mathieu's suggestion to split one big patch to 3 small patches for setting sample flags, one is for instruction range packet, one is for discontinuity packet and one is for exception packet. * Added supporting for ETMv3 exception packet. * Followed Mathieu's suggestion to move all sample flags handling from decoder layer to cs-etm.c, thus it has enough info to set flags based on trace context in single place. Changes from v1: * Moved exception packets handling patches into patch series 'perf cs-etm: Correct packets handling'. * Added sample flags fixing up for TRACE_OFF packet. * Created a new function which is used to maintain flags fixing up. Leo Yan (8): perf cs-etm: Add last instruction information in packet perf cs-etm: Set sample flags for instruction range packet perf cs-etm: Set sample flags for trace discontinuity perf cs-etm: Add exception number in exception packet perf cs-etm: Change tuple from traceID-CPU# to traceID-metadata perf cs-etm: Add traceID in packet perf cs-etm: Set sample flags for exception packet perf cs-etm: Set sample flags for exception return packet .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 41 +- .../perf/util/cs-etm-decoder/cs-etm-decoder.h | 6 + tools/perf/util/cs-etm.c | 405 +++++++++++++++++- tools/perf/util/cs-etm.h | 48 ++- 4 files changed, 482 insertions(+), 18 deletions(-) -- 2.17.1

7 years

[RFC PATCH 00/10] CoreSight CTI Driver

by Mike Leach

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

7 years

Online Marketing

by Mattie Riddick

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

7 years

RFC: power saving

by Al Grant

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

7 years

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

by Leo Yan

This patch seris adds support for sample flags so can facilitate perf to print sample flags for branch instruction. Patch 0001 is used to save last branch information in packet structure, this includes instruction type, subtype and condition flag to help making decision for which branch instruction it is. It passes related information from decoder layer to cs-etm.c, so we use cs-etm.c as a central place to set sample flags. Patch 0002 is used to set sample flags for instruction range packet. Patch 0003 is used to set sample flags for trace discontinuity packet. Patches 0004/0005/0006 are preparation for exception packet handling: Patch 0004 addes exception number in packet; pacth 0005/0006 is to use traceID/metadata tuple to access metadata pointer based on traceID, this can help decide if the CPU is connected with ETMv3 or ETMv4, ETMv3 and ETMv4 have totally different definition for exception numbers. Patch 0007 sets sample flags for exception packet; patch 0008 support sample flags for exception return packet. As Mathieu pointed out, one most difficult thing is to handle nest interrupt and trace discontinuity for exception return packet; if we use one data structure to maintain the interrupt context and also track the nest interrupts, this will be complex. So in patch 0008 we simply to check if there have one SVC instruction prior to the return address, by this way we can simply get rid of the dependency between the exception packet and exception return packet for setting sample flags, thus this can let us to set sample flags for exception return packet only based on the sequential instruction range packet. This patch series is applied on the acme's perf core branch [1] with the with latest commit ee412f14693a ("tools include uapi: Sync linux/vhost.h with the kernel sources"). After applying this patch series, we can verify sample flags with below command: # perf script -F,-time,+flags,+ip,+sym,+dso,+addr,+symoff -k vmlinux Changes from v4: * Fixed typos in comments, and removed redundant info from commit log; * Addressed Mathieu's suggestion to add helper functions for metadata fields (CS_ETM_CPU and CS_ETM_MAGIC) accessing; * Addressed Mathieu's suggestion to include headers with alphabetical order. Changes from v3: * Fixed typos in commit logs; * Rearranged fields in cs_etm_packet by grouping with same variable types; * Fixed ETMv4 exception number which pointed by Mike; * Fixed ETMv4 SVC / SMC / HVC in the same CALL, by checking svc instruction to distinguish them; * Refine ETMv4 return exception packet handling. Changes from v2: * Addressed Mathieu's suggestion to split one big patch to 3 small patches for setting sample flags, one is for instruction range packet, one is for discontinuity packet and one is for exception packet. * Added supporting for ETMv3 exception packet. * Followed Mathieu's suggestion to move all sample flags handling from decoder layer to cs-etm.c, thus it has enough info to set flags based on trace context in single place. Changes from v1: * Moved exception packets handling patches into patch series 'perf cs-etm: Correct packets handling'. * Added sample flags fixing up for TRACE_OFF packet. * Created a new function which is used to maintain flags fixing up. [1] https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/log/?h=perf/… Leo Yan (8): perf cs-etm: Add last instruction information in packet perf cs-etm: Set sample flags for instruction range packet perf cs-etm: Set sample flags for trace discontinuity perf cs-etm: Add exception number in exception packet perf cs-etm: Change tuple from traceID-CPU# to traceID-metadata perf cs-etm: Add traceID in packet perf cs-etm: Set sample flags for exception packet perf cs-etm: Set sample flags for exception return packet .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 41 +- .../perf/util/cs-etm-decoder/cs-etm-decoder.h | 6 + tools/perf/util/cs-etm.c | 405 +++++++++++++++++- tools/perf/util/cs-etm.h | 45 +- 4 files changed, 479 insertions(+), 18 deletions(-) -- 2.17.1

7 years

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

by Leo Yan

This patch seris adds support for sample flags so can facilitate perf to print sample flags for branch instruction. Patch 0001 is used to save last branch information in packet structure, this includes instruction type, subtype and condition flag to help making decision for which branch instruction it is. It passes related information from decoder layer to cs-etm.c, so we use cs-etm.c as a central place to set sample flags. Patch 0002 is used to set sample flags for instruction range packet. Patch 0003 is used to set sample flags for trace discontinuity packet. Patches 0004/0005/0006 are preparation for exception packet handling: Patch 0004 addes exception number in packet; pacth 0005/0006 is to use traceID/metadata pointer tuple to access metadata pointer based on trace ID, so this can help decide if the CPU is connected with ETMv3 or ETMv4, ETMv3 and ETMv4 have totally different definition for exception numbers. Patch 0007 sets sample flags for exception packet; patch 0008 support sample flags for exception return packet. As Mathieu pointed out, one most difficult thing is to handle nest interrupt and trace discontinuity for exception return packet; if we use one data structure to maintain the interrupt context and also track the nest interrupts, this will be complex. So in patch 0008 we simply to check if there have one SVC instruction prior to the return address, by this way we can simply get rid of the dependency between the exception packet and exception return packet for setting sample flags, thus this can let us to set sample flags for exception return packet only based on the sequential instruction range packet. This patch series is applied on the acme's perf core branch [1] with the with latest commit ee412f14693a ("tools include uapi: Sync linux/vhost.h with the kernel sources"). After applying the dependency patches and this patch series, we can verify sample flags with below command: # perf script -F,-time,+flags,+ip,+sym,+dso,+addr,+symoff -k vmlinux Changes from v3: * Fixed typos in commit logs; * Rearranged fields in cs_etm_packet by grouping with same variable types; * Fixed ETMv4 exception number which pointed by Mike; * Fixed ETMv4 SVC / SMC / HVC in the same CALL, by checking svc instruction to distinguish them; * Refine ETMv4 return exception packet handling. Changes from v2: * Addressed Mathieu's suggestion to split one big patch to 3 small patches for setting sample flags, one is for instruction range packet, one is for discontinuity packet and one is for exception packet. * Added supporting for ETMv3 exception packet. * Followed Mathieu's suggestion to move all sample flags handling from decoder layer to cs-etm.c, thus it has enough info to set flags based on trace context in single place. Changes from v1: * Moved exception packets handling patches into patch series 'perf cs-etm: Correct packets handling'. * Added sample flags fixing up for TRACE_OFF packet. * Created a new function which is used to maintain flags fixing up. [1] https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/log/?h=perf/… Leo Yan (8): perf cs-etm: Add last instruction information in packet perf cs-etm: Set sample flags for instruction range packet perf cs-etm: Set sample flags for trace discontinuity perf cs-etm: Add exception number in exception packet perf cs-etm: Change tuple from traceID-CPU# to traceID-metadata perf cs-etm: Add traceID in packet perf cs-etm: Set sample flags for exception packet perf cs-etm: Set sample flags for exception return packet .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 36 +- .../perf/util/cs-etm-decoder/cs-etm-decoder.h | 6 + tools/perf/util/cs-etm.c | 383 +++++++++++++++++- tools/perf/util/cs-etm.h | 43 +- 4 files changed, 454 insertions(+), 14 deletions(-) -- 2.17.1

7 years

[PATCH AUTOSEL 4.19 77/97] perf cs-etm: Correct packets swapping in cs_etm__flush()

by Sasha Levin

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

7 years, 1 month

[PATCH AUTOSEL 4.20 093/117] perf cs-etm: Correct packets swapping in cs_etm__flush()

by Sasha Levin

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

7 years, 1 month

Re: [PATCH] dts: arm64: add CoreSight trace support for hi3660

by leo.yan＠linaro.org

Hi Wanglai, [ + CoreSight mailing list ] On Tue, Dec 11, 2018 at 06:05:49PM +0800, Wanglai Shi wrote: > This patch adds devicetree entries for the CoreSight trace > components on hi3660. > > Signed-off-by: Wanglai Shi <shiwanglai(a)hisilicon.com> > --- > .../arm64/boot/dts/hisilicon/hi3660-coresight.dtsi | 428 +++++++++++++++++++++ > 1 file changed, 428 insertions(+) > create mode 100644 arch/arm64/boot/dts/hisilicon/hi3660-coresight.dtsi This patch doesn't work on Hikey960 due CoreSight related dt binding has not been really included by dts file. > diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-coresight.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660-coresight.dtsi > new file mode 100644 > index 0000000..95c79e4 > --- /dev/null > +++ b/arch/arm64/boot/dts/hisilicon/hi3660-coresight.dtsi > @@ -0,0 +1,428 @@ > +/* > + * dtsi for Hisilicon Hi3660 Coresight > + * > + * Copyright (C) 2016-2017 Hisilicon Ltd. s/2017/2018 > + * > + * Author: Wanglai Shi <shiwanglai(a)hisilicon.com> > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * publishhed by the Free Software Foundation. > + */ > +/ { > + amba { s/amba/soc > + #address-cells = <2>; > + #size-cells = <2>; > + compatible = "arm,amba-bus"; > + ranges; If under 'soc' node, because 'soc' has defined its address/size cells length, thus you don't need to define these properties repeatly. > + > + /* A53 cluster internal coresight */ > + etm@0,ecc40000 { s/etm@0,ecc40000/etm@ecc40000 > + compatible = "arm,coresight-etm4x","arm,primecell"; Add extra space between two compatible strings: compatible = "arm,coresight-etm4x", "arm,primecell"; Please apply this rule for all below compatible string bindings. > + reg = <0 0xecc40000 0 0x1000>; > + clocks = <&pclk>; > + clock-names = "apb_pclk"; > + cpu = <&cpu0>; > + port { > + etm0_out_port: endpoint { > + remote-endpoint = <&funnel0_in_port0>; > + }; > + }; Since Suzuki introduced CoreSight DT bindings for "out-ports" and "in-ports", so it's suggested to use more explict way to bind hardware port with specifying direction: out-ports { port { etm0_out: endpoint { remote-endpoint = <&funnel0_in_port0>; }; }; }; > + }; > + > + etm@1,ecd40000 { Remove '1,' > + compatible = "arm,coresight-etm4x","arm,primecell"; > + reg = <0 0xecd40000 0 0x1000>; > + clocks = <&pclk>; > + clock-names = "apb_pclk"; > + cpu = <&cpu1>; > + port { Suggest for adding 'out-ports'. > + etm1_out_port: endpoint { > + remote-endpoint = <&funnel0_in_port1>; > + }; > + }; > + }; > + > + etm@2,ece40000 { Remove '2,' > + compatible = "arm,coresight-etm4x","arm,primecell"; > + reg = <0 0xece40000 0 0x1000>; > + clocks = <&pclk>; > + clock-names = "apb_pclk"; > + cpu = <&cpu2>; > + port { Suggest for adding 'out-ports'. > + etm2_out_port: endpoint { > + remote-endpoint = <&funnel0_in_port2>; > + }; > + }; > + }; > + > + etm@3,ecf40000 { Remove '3,' > + compatible = "arm,coresight-etm4x","arm,primecell"; > + reg = <0 0xecf40000 0 0x1000>; > + clocks = <&pclk>; > + clock-names = "apb_pclk"; > + cpu = <&cpu3>; > + port { Suggest for adding 'out-ports'. > + etm3_out_port: endpoint { > + remote-endpoint = <&funnel0_in_port3>; > + }; > + }; > + }; > + > + funnel0:funnel@0,ec801000 { funnel0: funnel@ec801000 > + compatible = "arm,coresight-funnel","arm,primecell"; > + reg = <0 0xec801000 0 0x1000>; > + clocks = <&pclk>; > + clock-names = "apb_pclk"; > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + /* funnel output port */ > + port@0 { > + reg = <0>; > + funnel0_out_port: endpoint { > + remote-endpoint = > + <&etf0_in_port>; > + }; > + }; Suggest for below format: out-ports { port { reg = <0>; clusster0_funnel_out_port: endpoint { remote-endpoint = <&etf0_in_port>; }; }; }; > + > + /* funnel input ports */ > + port@1 { Suggest for adding 'in-ports'. BTW, please keep the consistence between node name and registers; e.g. port@0 should be consistent with 'reg = <0>;' and port@1 for 'reg = <1>;' ... So this should be port@0 > + reg = <0>; > + funnel0_in_port0: endpoint { > + slave-mode; > + remote-endpoint = > + <&etm0_out_port>; > + }; > + }; > + > + port@2 { s/port@2/port@1 > + reg = <1>; > + funnel0_in_port1: endpoint { > + slave-mode; > + remote-endpoint = > + <&etm1_out_port>; > + }; > + }; > + > + port@3 { s/port@3/port@2 > + reg = <2>; > + funnel0_in_port2: endpoint { > + slave-mode; > + remote-endpoint = > + <&etm2_out_port>; > + }; > + }; > + > + port@4 { s/port@4/port@3 > + reg = <3>; > + funnel0_in_port3: endpoint { > + slave-mode; > + remote-endpoint = > + <&etm3_out_port>; > + }; > + }; > + }; > + }; > + > + etf0:etf@0,ec802000 { etf0: etf@ec802000 > + compatible = "arm,coresight-tmc","arm,primecell"; > + reg = <0 0xec802000 0 0x1000>; > + clocks = <&pclk>; > + clock-names = "apb_pclk"; > + ports { Same with upper suggestions: add 'in-ports' and 'out-ports'. > + #address-cells = <1>; > + #size-cells = <0>; > + /* input port */ > + port@0 { > + reg = <0>; > + etf0_in_port: endpoint { > + slave-mode; > + remote-endpoint = > + <&funnel0_out_port>; > + }; > + }; > + > + /* output port */ > + port@1 { s/port@1/port@0 > + reg = <0>; > + etf0_out_port: endpoint { > + remote-endpoint = > + <&funnel2_in_port0>; > + }; > + }; > + }; > + }; > + > + /* A73 cluster internal coresight */ > + etm@4,ed440000 { Same suggestion with CA53 cluster bindings for etm. > + compatible = "arm,coresight-etm4x","arm,primecell"; > + reg = <0 0xed440000 0 0x1000>; > + clocks = <&pclk>; > + clock-names = "apb_pclk"; > + cpu = <&cpu4>; > + port { > + etm4_out_port: endpoint { > + remote-endpoint = <&funnel1_in_port0>; > + }; > + }; > + }; > + > + etm@5,ed540000 { > + compatible = "arm,coresight-etm4x","arm,primecell"; > + reg = <0 0xed540000 0 0x1000>; > + clocks = <&pclk>; > + clock-names = "apb_pclk"; > + cpu = <&cpu5>; > + port { > + etm5_out_port: endpoint { > + remote-endpoint = <&funnel1_in_port1>; > + }; > + }; > + }; > + > + etm@6,ed640000 { > + compatible = "arm,coresight-etm4x","arm,primecell"; > + reg = <0 0xed640000 0 0x1000>; > + clocks = <&pclk>; > + clock-names = "apb_pclk"; > + cpu = <&cpu6>; > + port { > + etm6_out_port: endpoint { > + remote-endpoint = <&funnel1_in_port2>; > + }; > + }; > + }; > + > + etm@7,ed740000 { > + compatible = "arm,coresight-etm4x","arm,primecell"; > + reg = <0 0xed740000 0 0x1000>; > + clocks = <&pclk>; > + clock-names = "apb_pclk"; > + cpu = <&cpu7>; > + port { > + etm7_out_port: endpoint { > + remote-endpoint = <&funnel1_in_port3>; > + }; > + }; > + }; > + > + funnel1:funnel@1,ed001000 { Same suggestion for funnel0. > + compatible = "arm,coresight-funnel","arm,primecell"; > + reg = <0 0xed001000 0 0x1000>; > + clocks = <&pclk>; > + clock-names = "apb_pclk"; > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + /* funnel output port */ > + port@0 { > + reg = <0>; > + funnel1_out_port: endpoint { > + remote-endpoint = > + <&etf1_in_port>; > + }; > + }; > + > + /* funnel input ports */ > + port@1 { > + reg = <0>; > + funnel1_in_port0: endpoint { > + slave-mode; > + remote-endpoint = > + <&etm4_out_port>; > + }; > + }; > + > + port@2 { > + reg = <1>; > + funnel1_in_port1: endpoint { > + slave-mode; > + remote-endpoint = > + <&etm5_out_port>; > + }; > + }; > + > + port@3 { > + reg = <2>; > + funnel1_in_port2: endpoint { > + slave-mode; > + remote-endpoint = > + <&etm6_out_port>; > + }; > + }; > + > + port@4 { > + reg = <3>; > + funnel1_in_port3: endpoint { > + slave-mode; > + remote-endpoint = > + <&etm7_out_port>; > + }; > + }; > + }; > + }; > + > + etf1:etf@1,ed002000 { Same suggestion for etf0. > + compatible = "arm,coresight-tmc","arm,primecell"; > + reg = <0 0xed002000 0 0x1000>; > + clocks = <&pclk>; > + clock-names = "apb_pclk"; > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + /* input port */ > + port@0 { > + reg = <0>; > + etf1_in_port: endpoint { > + slave-mode; > + remote-endpoint = > + <&funnel1_out_port>; > + }; > + }; > + > + /* output port */ > + port@1 { > + reg = <0>; > + etf1_out_port: endpoint { > + remote-endpoint = > + <&funnel2_in_port0>; > + }; > + }; > + }; > + }; > + > + /* Top coresight config */ > + funnel@2,ec031000 { > + compatible = "arm,coresight-funnel","arm,primecell"; > + reg = <0 0xec031000 0 0x1000>; > + clocks = <&pclk>; > + clock-names = "apb_pclk"; > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + /* funnel output port */ > + port@0 { > + reg = <0>; > + funnel2_out_port: endpoint { > + remote-endpoint = > + <&etf2_in_port>; > + }; > + }; > + > + /* funnel input ports */ > + port@1 { > + reg = <0>; > + funnel2_in_port0: endpoint { > + slave-mode; > + remote-endpoint = > + <&etf0_out_port>; > + }; > + }; I think this funnel should have two input ports: one is for etf0 and another is for connection etf1, but here it misses for etf1. Do I miss anything for this? > + }; > + }; > + > + etf@2,ec036000 { Same suggestion for etf0/1. > + compatible = "arm,coresight-tmc","arm,primecell"; > + reg = <0 0xec036000 0 0x1000>; > + clocks = <&pclk>; > + clock-names = "apb_pclk"; > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + /* input port */ > + port@0 { > + reg = <0>; > + etf2_in_port: endpoint { > + slave-mode; > + remote-endpoint = > + <&funnel2_out_port>; > + }; > + }; > + > + /* output port */ > + port@1 { > + reg = <0>; > + etf2_out_port: endpoint { > + remote-endpoint = > + <&replicator0_in_port>; > + }; > + }; > + }; > + }; > + > + replicator { > + compatible = "arm,coresight-replicator"; Replicator doesn't have clock? > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + /* etr out port */ > + port@0 { > + reg = <0>; > + replicator0_out_port0: endpoint { > + remote-endpoint = > + <&etr_in_port>; > + }; > + }; > + /* TPIU out port */ > + port@1 { > + reg = <1>; > + replicator0_out_port1: endpoint { > + remote-endpoint = > + <&tpiu_in_port>; > + }; > + }; > + /* input port */ > + port@2 { > + reg = <0>; > + replicator0_in_port: endpoint { > + slave-mode; > + remote-endpoint = > + <&etf2_out_port>; > + }; > + }; > + }; > + }; > + > + etr@0,ec033000 { > + compatible = "arm,coresight-tmc","arm,primecell"; > + reg = <0 0xec033000 0 0x1000>; > + clocks = <&pclk>; > + clock-names = "apb_pclk"; > + ports { > + #address-cells = <1>; > + #size-cells = <0>; Usually etr doesn't need to set address-cells and size-cell anymore. > + > + /* etr input port */ > + port@0 { > + reg = <0>; > + etr_in_port: endpoint { > + slave-mode; >From Documentation/devicetree/bindings/arm/coresight.txt, I cannot see there have 'slave-mode' property. > + remote-endpoint = > + <&replicator0_out_port0>; > + }; > + }; > + }; > + }; > + > + tpiu@ec032000 { > + compatible = "arm,coresight-tpiu", "arm,primecell"; > + reg = <0 0xec032000 0 0x1000>; > + > + clocks = <&pclk>; > + clock-names = "apb_pclk"; > + port { > + tpiu_in_port: endpoint { > + slave-mode; > + remote-endpoint = > + <&replicator0_out_port1>; > + }; > + }; > + }; > + }; I don't see CPU debug module DT binding, could you add them as well? You could use the single one patch to contain CPU debug module or use one dedicated patch, both will be okay for me. Thanks, Leo Yan > +}; > -- > 2.7.4 >

7 years, 1 month

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight