From: Leo Yan <leo.yan(a)linaro.org>
commit 95c6fe970a0160cb770c5dce9f80311b42d030c0 upstream.
If packet processing wants to know the packet is bound with which ETM
version, it needs to access metadata to decide that based on metadata
magic number; but we cannot simply to use CPU logic ID number as index
to access metadata sequential array, especially when system have
hotplugged off CPUs, the metadata array are only allocated for online
CPUs but not offline CPUs, so the CPU logic number doesn't match with
its index in the array.
This patch is to change tuple from traceID-CPU# to traceID-metadata,
thus it can use the tuple to retrieve metadata pointer according to
traceID.
For safe accessing metadata fields, this patch provides helper function
cs_etm__get_cpu() which is used to return CPU number according to
traceID; cs_etm_decoder__buffer_packet() is the first consumer for this
helper function.
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: Suzuki K Poulouse <suzuki.poulose(a)arm.com>
Cc: coresight ml <coresight(a)lists.linaro.org>
Cc: linux-arm-kernel(a)lists.infradead.org
Link: http://lkml.kernel.org/r/20190129122842.32041-6-leo.yan@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
[Salvatore Bonaccorso: Adjust for context changes in
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c]
Signed-off-by: Salvatore Bonaccorso <carnil(a)debian.org>
---
.../perf/util/cs-etm-decoder/cs-etm-decoder.c | 8 +++---
tools/perf/util/cs-etm.c | 26 ++++++++++++++-----
tools/perf/util/cs-etm.h | 9 ++++++-
3 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index 938def6d0bb9..f540037eb705 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -278,14 +278,12 @@ cs_etm_decoder__buffer_packet(struct cs_etm_decoder *decoder,
enum cs_etm_sample_type sample_type)
{
u32 et = 0;
- struct int_node *inode = NULL;
+ int cpu;
if (decoder->packet_count >= MAX_BUFFER - 1)
return OCSD_RESP_FATAL_SYS_ERR;
- /* Search the RB tree for the cpu associated with this traceID */
- inode = intlist__find(traceid_list, trace_chan_id);
- if (!inode)
+ if (cs_etm__get_cpu(trace_chan_id, &cpu) < 0)
return OCSD_RESP_FATAL_SYS_ERR;
et = decoder->tail;
@@ -296,7 +294,7 @@ cs_etm_decoder__buffer_packet(struct cs_etm_decoder *decoder,
decoder->packet_buffer[et].sample_type = sample_type;
decoder->packet_buffer[et].exc = false;
decoder->packet_buffer[et].exc_ret = false;
- decoder->packet_buffer[et].cpu = *((int *)inode->priv);
+ decoder->packet_buffer[et].cpu = cpu;
decoder->packet_buffer[et].start_addr = CS_ETM_INVAL_ADDR;
decoder->packet_buffer[et].end_addr = CS_ETM_INVAL_ADDR;
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 7b5e15cc6b71..5cde3956e19a 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -91,6 +91,20 @@ static int cs_etm__update_queues(struct cs_etm_auxtrace *etm);
static int cs_etm__process_timeless_queues(struct cs_etm_auxtrace *etm,
pid_t tid, u64 time_);
+int cs_etm__get_cpu(u8 trace_chan_id, int *cpu)
+{
+ struct int_node *inode;
+ u64 *metadata;
+
+ inode = intlist__find(traceid_list, trace_chan_id);
+ if (!inode)
+ return -EINVAL;
+
+ metadata = inode->priv;
+ *cpu = (int)metadata[CS_ETM_CPU];
+ return 0;
+}
+
static void cs_etm__packet_dump(const char *pkt_string)
{
const char *color = PERF_COLOR_BLUE;
@@ -230,7 +244,7 @@ static void cs_etm__free(struct perf_session *session)
cs_etm__free_events(session);
session->auxtrace = NULL;
- /* First remove all traceID/CPU# nodes for the RB tree */
+ /* First remove all traceID/metadata nodes for the RB tree */
intlist__for_each_entry_safe(inode, tmp, traceid_list)
intlist__remove(traceid_list, inode);
/* Then the RB tree itself */
@@ -1316,9 +1330,9 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
0xffffffff);
/*
- * Create an RB tree for traceID-CPU# tuple. Since the conversion has
- * to be made for each packet that gets decoded, optimizing access in
- * anything other than a sequential array is worth doing.
+ * Create an RB tree for traceID-metadata tuple. Since the conversion
+ * has to be made for each packet that gets decoded, optimizing access
+ * in anything other than a sequential array is worth doing.
*/
traceid_list = intlist__new(NULL);
if (!traceid_list) {
@@ -1384,8 +1398,8 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
err = -EINVAL;
goto err_free_metadata;
}
- /* All good, associate the traceID with the CPU# */
- inode->priv = &metadata[j][CS_ETM_CPU];
+ /* All good, associate the traceID with the metadata pointer */
+ inode->priv = metadata[j];
}
/*
diff --git a/tools/perf/util/cs-etm.h b/tools/perf/util/cs-etm.h
index 37f8d48179ca..fb5fc6538b7f 100644
--- a/tools/perf/util/cs-etm.h
+++ b/tools/perf/util/cs-etm.h
@@ -53,7 +53,7 @@ enum {
CS_ETMV4_PRIV_MAX,
};
-/* RB tree for quick conversion between traceID and CPUs */
+/* RB tree for quick conversion between traceID and metadata pointers */
struct intlist *traceid_list;
#define KiB(x) ((x) * 1024)
@@ -69,6 +69,7 @@ static const u64 __perf_cs_etmv4_magic = 0x4040404040404040ULL;
#ifdef HAVE_CSTRACE_SUPPORT
int cs_etm__process_auxtrace_info(union perf_event *event,
struct perf_session *session);
+int cs_etm__get_cpu(u8 trace_chan_id, int *cpu);
#else
static inline int
cs_etm__process_auxtrace_info(union perf_event *event __maybe_unused,
@@ -76,6 +77,12 @@ cs_etm__process_auxtrace_info(union perf_event *event __maybe_unused,
{
return -1;
}
+
+static inline int cs_etm__get_cpu(u8 trace_chan_id __maybe_unused,
+ int *cpu __maybe_unused)
+{
+ return -1;
+}
#endif
#endif
--
2.29.2
With the steady stream of new features coming into the subsystem
it has been clear for some time now that help is needed.
Suzuki and Leo have worked extensively on various parts of the
project and have agreed to help.
While at it add the new location for the coresight git tree.
Signed-off-by: Mathieu Poirier <mathieu.poirier(a)linaro.org>
---
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e73636b75f29..8d0b008c7781 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1723,11 +1723,13 @@ F: arch/arm/mach-ep93xx/micro9.c
ARM/CORESIGHT FRAMEWORK AND DRIVERS
M: Mathieu Poirier <mathieu.poirier(a)linaro.org>
-R: Suzuki K Poulose <suzuki.poulose(a)arm.com>
+M: Suzuki K Poulose <suzuki.poulose(a)arm.com>
R: Mike Leach <mike.leach(a)linaro.org>
+R: Leo Yan <leo.yan(a)linaro.org>
L: coresight(a)lists.linaro.org (moderated for non-subscribers)
L: linux-arm-kernel(a)lists.infradead.org (moderated for non-subscribers)
S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git
F: Documentation/ABI/testing/sysfs-bus-coresight-devices-*
F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
F: Documentation/devicetree/bindings/arm/coresight-cti.yaml
--
2.25.1
Hi,
I've encountered a perf.data file whose PERF_RECORD_AUXTRACE_INFO
has an additional ETM register per CPU (i.e. the metadata for each CPU is
8 bytes longer than normal). Some patch somewhere must be adding this
register for reasons unknown.
Upstream perf won't even print this file, it reports failure to process
record type 70 and errors out. The metadata reading code in util/cs-etm.c
expects exactly CS_ETMV4_PRIV_MAX registers, no more. I.e. it won't
go skipping past extra ones to find the next "magic" number.
It's unfortunate that "perf report -D" errors out, when the reason for
using -D may be to investigate why perf in general isn't working.
I want to fix this at least.
Now firstly, has anyone got any ideas why there might be an additional
register, does anyone know of a patch that does this?
And secondly, could/should we make the metadata format more robust?
Cases of more or fewer registers than expected can, to some extent, be
handled by looking for the magic number, but that assumes that registers
don't legitimately have values equal to the magic number.
The version number could help us evolve upstream to a new format but
it isn't really an answer to robust interchange in general. Should we at
least have the metadata describe its own length (i.e. number of registers)
so that perf tools can read it, even if they might not be able to fully
understand it.
Al
From: Mao Jinlong <jinlmao(a)codeaurora.org>
alloc_pages_node() return should be checked before calling
dma_map_page() to make sure that valid page is mapped or
else it can lead to aborts as below:
Unable to handle kernel paging request at virtual address ffffffc008000000
Mem abort info:
<snip>...
pc : __dma_inv_area+0x40/0x58
lr : dma_direct_map_page+0xd8/0x1c8
Call trace:
__dma_inv_area
tmc_pages_alloc
tmc_alloc_data_pages
tmc_alloc_sg_table
tmc_init_etr_sg_table
tmc_alloc_etr_buf
tmc_enable_etr_sink_sysfs
tmc_enable_etr_sink
coresight_enable_path
coresight_enable
enable_source_store
dev_attr_store
sysfs_kf_write
Fixes: 99443ea19e8b ("coresight: Add generic TMC sg table framework")
Cc: stable(a)vger.kernel.org
Signed-off-by: Mao Jinlong <jinlmao(a)codeaurora.org>
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan(a)codeaurora.org>
---
drivers/hwtracing/coresight/coresight-tmc-etr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index 525f0ecc129c..a31a4d7ae25e 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -217,6 +217,8 @@ static int tmc_pages_alloc(struct tmc_pages *tmc_pages,
} else {
page = alloc_pages_node(node,
GFP_KERNEL | __GFP_ZERO, 0);
+ if (!page)
+ goto err;
}
paddr = dma_map_page(real_dev, page, 0, PAGE_SIZE, dir);
if (dma_mapping_error(real_dev, paddr))
base-commit: c04e5d7bbf6f92a346d6b36770705e7f034df42d
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
The patch below does not apply to the 5.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From dd94ac807a5e10e0b25b68397c473276905cca73 Mon Sep 17 00:00:00 2001
From: Leo Yan <leo.yan(a)linaro.org>
Date: Tue, 10 Nov 2020 14:34:17 +0800
Subject: [PATCH] perf test: Update branch sample pattern for cs-etm
Since the commit 943b69ac1884 ("perf parse-events: Set exclude_guest=1
for user-space counting"), 'exclude_guest=1' is set for user-space
counting; and the branch sample's modifier has been altered, the sample
event name has been changed from "branches:u:" to "branches:uH:", which
gives out info for "user-space and host counting".
But the cs-etm testing's regular expression cannot match the updated
branch sample event and leads to test failure.
This patch updates the branch sample pattern by using a more flexible
expression '.*' to match branch sample's modifiers, so that allows the
testing to work as expected.
Fixes: 943b69ac1884 ("perf parse-events: Set exclude_guest=1 for user-space counting")
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: Jin Yao <yao.jin(a)linux.intel.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Mark Rutland <mark.rutland(a)arm.com>
Cc: Mike Leach <mike.leach(a)linaro.org>
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: stable(a)kernel.org
Link: http://lore.kernel.org/lkml/20201110063417.14467-2-leo.yan@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
diff --git a/tools/perf/tests/shell/test_arm_coresight.sh b/tools/perf/tests/shell/test_arm_coresight.sh
index 59d847d4981d..18fde2f179cd 100755
--- a/tools/perf/tests/shell/test_arm_coresight.sh
+++ b/tools/perf/tests/shell/test_arm_coresight.sh
@@ -44,7 +44,7 @@ perf_script_branch_samples() {
# touch 6512 1 branches:u: ffffb22082e0 strcmp+0xa0 (/lib/aarch64-linux-gnu/ld-2.27.so)
# touch 6512 1 branches:u: ffffb2208320 strcmp+0xe0 (/lib/aarch64-linux-gnu/ld-2.27.so)
perf script -F,-time -i ${perfdata} | \
- egrep " +$1 +[0-9]+ .* +branches:([u|k]:)? +"
+ egrep " +$1 +[0-9]+ .* +branches:(.*:)? +"
}
perf_report_branch_samples() {
Hi,
When using the /cycacc=1/ option the cycle-counting threshold (setting the
minimum gap between cycle packets) is set to a default of 256, which is very
high and gives poor cycle resolution. Cores can manage far better than this
(single digits, if not 1).
The threshold can be set lower via sysfs, but it's capped by an ID register
which has a (CPU-specific) minimum possible value. Unfortunately on
some widely used cores this ID register incorrectly reports 0x100 i.e. 256.
The intended value for these cores is 0b100 i.e. 4.
The default threshold is rather high and means we don't get as much value
out of this feature as we could. In fact, we typically get timestamp packets
more often than we get cycle count packets (timestamp packets also
have cycle counts, but take up more space in the trace, so it's not the best
way to get high resolution cycle counting).
The effect of writing a threshold value below what the ID register says,
is architecturally unpredictable. So it's not something we can do generally.
What I would suggest as the way forward is to:
- set the default lower
- cap it against the value in the ID register (i.e. the default might be 10,
but if the ID register on a given core says 20, program the ETM to 20)
- add an event parameter to set the threshold:
-e cs_etm/cycacc=1,cycthreshold=10/
- add a 1-bit event parameter to override the checking of the ID register:
-e cs_etm/cycacc=1,cycthreshold=10,cycoverride=1/
We could use the CPU errata mechanism to work around the incorrect
ID register, but it seems overkill in this case.
I'd suggest a default of 8 for the threshold, and 10 bits for the
cycthreshold event parameter. If anyone has other ideas, please say.
Al
Perf tool relies on MMAP/MMAP2 events to prepare DSO maps, it allocates
DSO maps for MMAP/MMAP2 events which is used for parsing symbol. Thus,
during the recording, perf tool implictly expects the MMAP/MMAP2 events
should arrive before AUX event, in other words, MMAP/MMAP2's timestamp
should less than AUX event's timestamp, and the MMAP/MMAP2 events will
be added into the front of ordered event list; this can allow the DSO
maps to be prepared and can be consumed when process AUX event.
See the function perf_evlist__prepare_workload(), though it uses pipes
to handshake before perf process (the parent process) and forked process
for the profiled program, it cannot promise the timing between
MMAP/MMAP2 events and AUX event.
On Arm Juno board, the AUX event can be observed to arrive ahead than
MMAP2 event, with the command:
perf record -e cs_etm/@tmc_etr0/ -S -- dd if=/dev/zero of=/dev/null
The follow diagram depicts the flow for how the AUX event is arriving
ahead than MMAP2 event:
T1: T3: T4:
perf process Open PMU device Perf is scheduled out;
invoke perf_aux_output_end()
and generate AUX event
^ ^ ^
| | |
CPU0 ---------------------------------------------------> (T)
\
\ Forked process is placed on another CPU
V
CPU1 ---------------------------------------------------> (T)
| |
V V
T2: T5:
Invoke execvp() for profiled Record MMAP2 event
program
In this scenario, the perf main process runs on CPU0 and the profiled
program (which is forked child process) runs on CPU1. The main process
opens PMU device for AUX trace (T3) and it will generate AUX event until
the perf process is scheduled out (T4); the profiled program will be
launched by execvp() (T2) and later will record MMAP event for memory
mapping (T5).
Usually, the AUX event will be later than MMAP2 event, but on the Arm
Juno platform, it has chance that AUX event occurs prior to MMAP2 event
with two reasons:
- Arm Juno platform is big.LITTLE architecture, so CPU0 is big CPU and
CPU1 is LITTLE CPU, the performance between big CPU and LITTLE CPU is
significant, this gives chance for the perf main process to run much
faster than the profiled program;
- In the kernel, the RT thread (like kernel's CPUFreq thread) has chance
to preempt perf main thread, so when the perf main thread is
switched out, the AUX event will be generated and it might be early
than profiled program's MMAP2 event.
To fix this issue, this patch records the first AUX event's timestamp
into 'aux_timestamp', if find any MMAP/MMAP2 event is late coming, it
fixes up the MMAP/MMAP2 events' timestamp as 'aux_timestamp-1', so the
MMAP/MMAP2 event will be inserted into ordered list ahead than AUX event
and also will be handled before AUX event.
Signed-off-by: Leo Yan <leo.yan(a)linaro.org>
---
tools/perf/util/session.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 098080287c68..1aa54941bf81 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1753,11 +1753,36 @@ static s64 perf_session__process_event(struct perf_session *session,
if (tool->ordered_events) {
u64 timestamp = -1ULL;
+ static u64 aux_timestamp = -1ULL;
ret = perf_evlist__parse_sample_timestamp(evlist, event, ×tamp);
if (ret && ret != -1)
return ret;
+ /*
+ * Cache the first AUX event's timestamp into 'aux_timestamp',
+ * which is used to fixup MMAP/MMAP2's timestamp.
+ */
+ if ((event->header.type == PERF_RECORD_AUX) &&
+ (aux_timestamp == -1ULL))
+ aux_timestamp = timestamp;
+
+ /*
+ * If the AUX event arrives prior to MMAP/MMAP2 events, it's
+ * possible to have no chance to create DSOs when decode AUX
+ * trace data, thus the symbol cannot be parsed properly.
+ * To allow the DSOs are prepared before process AUX event,
+ * fixup the MMAP/MMAP2 events' timestamp to be prior to any
+ * AUX event's timestamp, so MMAP/MMAP2 events will be
+ * handled ahead and the DSO map will be prepared before AUX
+ * event handling.
+ */
+ if (event->header.type == PERF_RECORD_MMAP2 ||
+ event->header.type == PERF_RECORD_MMAP) {
+ if (timestamp > aux_timestamp)
+ timestamp = aux_timestamp - 1;
+ }
+
ret = perf_session__queue_event(session, event, timestamp, file_offset);
if (ret != -ETIME)
return ret;
--
2.17.1
Hi Liu,
On Wed, Aug 19, 2020 at 04:06:37PM +0800, Qi Liu wrote:
> When too much trace information is generated on-chip, the ETM will
> overflow, and cause data loss. This is a common phenomenon on ETM
> devices.
>
> But sometimes we do not want to lose performance trace data, so we
> suppress the speed of instructions sent from CPU core to ETM to
> avoid the overflow of ETM.
>
> Signed-off-by: Qi Liu <liuqi115(a)huawei.com>
> ---
>
> Changes since v1:
> - ETM on HiSilicon Hip09 platform supports backpressure, so does
> not need to modify core commit.
>
> drivers/hwtracing/coresight/coresight-etm4x.c | 43 +++++++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
> index 7797a57..7641f89 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> @@ -43,6 +43,10 @@ MODULE_PARM_DESC(boot_enable, "Enable tracing on boot");
> #define PARAM_PM_SAVE_NEVER 1 /* never save any state */
> #define PARAM_PM_SAVE_SELF_HOSTED 2 /* save self-hosted state only */
>
> +#define CORE_COMMIT_CLEAR 0x3000
> +#define CORE_COMMIT_SHIFT 12
> +#define HISI_ETM_AMBA_ID_V1 0x000b6d01
> +
> static int pm_save_enable = PARAM_PM_SAVE_FIRMWARE;
> module_param(pm_save_enable, int, 0444);
> MODULE_PARM_DESC(pm_save_enable,
> @@ -104,11 +108,40 @@ struct etm4_enable_arg {
> int rc;
> };
>
> +static void etm4_cpu_actlr1_cfg(void *info)
> +{
> + struct etm4_enable_arg *arg = (struct etm4_enable_arg *)info;
> + u64 val;
> +
> + asm volatile("mrs %0,s3_1_c15_c2_5" : "=r"(val));
> + val &= ~CORE_COMMIT_CLEAR;
> + val |= arg->rc << CORE_COMMIT_SHIFT;
> + asm volatile("msr s3_1_c15_c2_5,%0" : : "r"(val));
> +}
> +
> +static void etm4_config_core_commit(int cpu, int val)
> +{
> + struct etm4_enable_arg arg = {0};
> +
> + arg.rc = val;
> + smp_call_function_single(cpu, etm4_cpu_actlr1_cfg, &arg, 1);
Function etm4_enable/disable_hw() are already running on the CPU they are
supposed to so no need to call smp_call_function_single().
> +}
> +
> static int etm4_enable_hw(struct etmv4_drvdata *drvdata)
> {
> int i, rc;
> + struct amba_device *adev;
> struct etmv4_config *config = &drvdata->config;
> struct device *etm_dev = &drvdata->csdev->dev;
> + struct device *dev = drvdata->csdev->dev.parent;
> +
> + adev = container_of(dev, struct amba_device, dev);
> + /*
> + * If ETM device is HiSilicon ETM device, reduce the
> + * core-commit to avoid ETM overflow.
> + */
> + if (adev->periphid == HISI_ETM_AMBA_ID_V1)
Do you have any documentation on this back pressure feature? I doubt this is
specific to Hip09 platform and as such would prefer to have a more generic
approach that works on any platform that supports it.
Anyone on the CS mailing list that knows what this is about?
Thanks,
Mathieu
> + etm4_config_core_commit(drvdata->cpu, 1);
>
> CS_UNLOCK(drvdata->base);
>
> @@ -472,10 +505,20 @@ static void etm4_disable_hw(void *info)
> {
> u32 control;
> struct etmv4_drvdata *drvdata = info;
> + struct device *dev = drvdata->csdev->dev.parent;
> struct etmv4_config *config = &drvdata->config;
> struct device *etm_dev = &drvdata->csdev->dev;
> + struct amba_device *adev;
> int i;
>
> + adev = container_of(dev, struct amba_device, dev);
> + /*
> + * If ETM device is HiSilicon ETM device, resume the
> + * core-commit after ETM trace is complete.
> + */
> + if (adev->periphid == HISI_ETM_AMBA_ID_V1)
> + etm4_config_core_commit(drvdata->cpu, 0);
> +
> CS_UNLOCK(drvdata->base);
>
> if (!drvdata->skip_power_up) {
> --
> 2.8.1
>