[RFT v3 2/4] perf script python: Add addr into perf sample dict

2018-05-28 Thread Leo Yan
ARM CoreSight auxtrace uses 'sample->addr' to record the target address
for branch instructions, so the data of 'sample->addr' is required for
tracing data analysis.

This commit collects data of 'sample->addr' into perf sample dict,
finally can be used for python script for parsing event.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 tools/perf/util/scripting-engines/trace-event-python.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/util/scripting-engines/trace-event-python.c 
b/tools/perf/util/scripting-engines/trace-event-python.c
index 10dd5fc..7f8afac 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -531,6 +531,8 @@ static PyObject *get_perf_sample_dict(struct perf_sample 
*sample,
PyLong_FromUnsignedLongLong(sample->period));
pydict_set_item_string_decref(dict_sample, "phys_addr",
PyLong_FromUnsignedLongLong(sample->phys_addr));
+   pydict_set_item_string_decref(dict_sample, "addr",
+   PyLong_FromUnsignedLongLong(sample->addr));
set_sample_read_in_dict(dict_sample, sample, evsel);
pydict_set_item_string_decref(dict, "sample", dict_sample);
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[RFT v3 3/4] perf script python: Add script for CoreSight trace disassembler

2018-05-28 Thread Leo Yan
This commit adds python script to parse CoreSight tracing event and
use command 'objdump' for disassembled lines, finally we can generate
readable program execution flow for reviewing tracing data.

The script receives CoreSight tracing packet with below format:

++++
  packet(n):|addr|ip  |cpu |
++++
  packet(n+1):  |addr|ip  |cpu |
++++

packet::ip is the last address of current branch instruction and
packet::addr presents the start address of the next coming branch
instruction.  So for one branch instruction which starts in packet(n),
its execution flow starts from packet(n)::addr and it stops at
packet(n+1)::ip.  As results we need to combine the two continuous
packets to generate the instruction range, this is the rationale for the
script implementation:

  [ sample(n)::addr .. sample(n+1)::ip ]

Credits to Tor Jeremiassen who have written the script skeleton and
provides the ideas for reading symbol file according to build-id,
creating memory map for dso and basic packet handling.  Mathieu Poirier
contributed fixes for build-id and memory map bugs.  The detailed
development history for this script you can find from [1].  Based on Tor
and Mathieu work, the script is updated samples handling for the
corrected sample format.  Another minor enhancement is to support for
without build-id case, the script can parse kernel symbols with option
'-k' for vmlinux file path.

[1] 
https://github.com/Linaro/perf-opencsd/commits/perf-opencsd-v4.15/tools/perf/scripts/python/cs-trace-disasm.py

Co-authored-by: Tor Jeremiassen <t...@ti.com>
Co-authored-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 tools/perf/scripts/python/arm-cs-trace-disasm.py | 235 +++
 1 file changed, 235 insertions(+)
 create mode 100644 tools/perf/scripts/python/arm-cs-trace-disasm.py

diff --git a/tools/perf/scripts/python/arm-cs-trace-disasm.py 
b/tools/perf/scripts/python/arm-cs-trace-disasm.py
new file mode 100644
index 000..1239ab4
--- /dev/null
+++ b/tools/perf/scripts/python/arm-cs-trace-disasm.py
@@ -0,0 +1,235 @@
+# arm-cs-trace-disasm.py: ARM CoreSight Trace Dump With Disassember
+# SPDX-License-Identifier: GPL-2.0
+#
+# Tor Jeremiassen <t...@ti.com> is original author who wrote script
+# skeleton, Mathieu Poirier <mathieu.poir...@linaro.org> contributed
+# fixes for build-id and memory map; Leo Yan <leo@linaro.org>
+# updated the packet parsing with new samples format.
+
+import os
+import sys
+import re
+from subprocess import *
+from optparse import OptionParser, make_option
+
+# Command line parsing
+
+option_list = [
+   # formatting options for the bottom entry of the stack
+   make_option("-k", "--vmlinux", dest="vmlinux_name",
+   help="Set path to vmlinux file"),
+   make_option("-d", "--objdump", dest="objdump_name",
+   help="Set path to objdump executable file"),
+   make_option("-v", "--verbose", dest="verbose",
+   action="store_true", default=False,
+   help="Enable debugging log")
+]
+
+parser = OptionParser(option_list=option_list)
+(options, args) = parser.parse_args()
+
+if (options.objdump_name == None):
+   sys.exit("No objdump executable file specified - use -d or --objdump 
option")
+
+# Initialize global dicts and regular expression
+
+build_ids = dict()
+mmaps = dict()
+disasm_cache = dict()
+cpu_data = dict()
+disasm_re = re.compile("^\s*([0-9a-fA-F]+):")
+disasm_func_re = re.compile("^\s*([0-9a-fA-F]+)\s\<.*\>:")
+cache_size = 32*1024
+prev_cpu = -1
+
+def parse_buildid():
+   global build_ids
+
+   buildid_regex = "([a-fA-f0-9]+)[ \t]([^ \n]+)"
+   buildid_re = re.compile(buildid_regex)
+
+   results = check_output(["perf", "buildid-list"]).split('\n');
+   for line in results:
+   m = buildid_re.search(line)
+   if (m == None):
+   continue;
+
+   id_name = m.group(2)
+   id_num  = m.group(1)
+
+   if (id_name == "[kernel.kallsyms]") :
+   append = "/kallsyms"
+   elif (id_name == "[vdso]") :
+   append = "/vdso"
+   else:
+   append = "/elf"
+
+   build_ids[id_name] = os.environ['PERF_BUILDID_DIR'] + \
+   "/" + id_name + "/" + id_num + append;
+   # Replace duplicate slash chars to single slash char
+ 

[RFT v3 4/4] coresight: Document for CoreSight trace disassembler

2018-05-28 Thread Leo Yan
This commit documents CoreSight trace disassembler usage and gives
example for it.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 Documentation/trace/coresight.txt | 52 +++
 1 file changed, 52 insertions(+)

diff --git a/Documentation/trace/coresight.txt 
b/Documentation/trace/coresight.txt
index 6f0120c..b8f2359 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -381,3 +381,55 @@ sort example is from the AutoFDO tutorial 
(https://gcc.gnu.org/wiki/AutoFDO/Tuto
$ taskset -c 2 ./sort_autofdo
Bubble sorting array of 3 elements
5806 ms
+
+
+Tracing data disassembler
+-
+
+'perf script' supports to use script to parse tracing packet and rely on
+'objdump' for disassembled lines, this can convert tracing data to readable
+program execution flow for easily reviewing tracing data.
+
+The CoreSight trace disassembler is located in the folder:
+tools/perf/scripts/python/arm-cs-trace-disasm.py.  This script support below
+options:
+
+   -d, --objdump: Set path to objdump executable, this option is
+  mandatory.
+   -k, --vmlinux: Set path to vmlinux file.
+   -v, --verbose: Enable debugging log, after enable this option the
+  script dumps every event data.
+
+Below is one example for using python script to dump CoreSight trace
+disassembler:
+
+   $ perf script -s arm-cs-trace-disasm.py -i perf.data \
+   -F cpu,event,ip,addr,sym -- -d objdump -k ./vmlinux > cs-disasm.log
+
+Below is one example for the disassembler log:
+
+ARM CoreSight Trace Data Assembler Dump
+   08a5f2dc <etm4_enable_hw+0x344>:
+   08a5f2dc:   34a0cbz w0, 08a5f2f0 
<etm4_enable_hw+0x358>
+   08a5f2f0 <etm4_enable_hw+0x358>:
+   08a5f2f0:   f9400260ldr x0, [x19]
+   08a5f2f4:   d5033f9fdsb sy
+   08a5f2f8:   913ec000add x0, x0, #0xfb0
+   08a5f2fc:   b91fstr wzr, [x0]
+   08a5f300:   f9400bf3ldr x19, [sp, #16]
+   08a5f304:   a8c27bfdldp x29, x30, [sp], #32
+   08a5f308:   d65f03c0ret
+   08a5fa18 <etm4_enable+0x1b0>:
+   08a5fa18:   1425b   08a5faac 
<etm4_enable+0x244>
+   08a5faac <etm4_enable+0x244>:
+   08a5faac:   b9406261ldr w1, [x19, #96]
+   08a5fab0:   52800015mov w21, #0x0   
// #0
+   08a5fab4:   f901ca61str x1, [x19, #912]
+   08a5fab8:   2a1503e0mov w0, w21
+   08a5fabc:   3940e261ldrbw1, [x19, #56]
+   08a5fac0:   f901ce61str x1, [x19, #920]
+   08a5fac4:   a94153f3ldp x19, x20, [sp, #16]
+   08a5fac8:   a9425bf5ldp x21, x22, [sp, #32]
+   08a5facc:   a94363f7ldp x23, x24, [sp, #48]
+   08a5fad0:   a8c47bfdldp x29, x30, [sp], #64
+   08a5fad4:   d65f03c0ret
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[RFT v3 0/4] Perf script: Add python script for CoreSight trace disassembler

2018-05-28 Thread Leo Yan
This patch series is to support for using 'perf script' for CoreSight
trace disassembler, for this purpose this patch series adds a new
python script to parse CoreSight tracing event and use command 'objdump'
for disassembled lines, finally this can generate readable program
execution flow for reviewing tracing data.

Patch 0001 is one fixing patch to generate samples for the start packet
and exception packets.

Patch 0002 is the prerequisite to add addr into sample dict, so this
value can be used by python script to analyze instruction range.

Patch 0003 is to add python script for trace disassembler.

Patch 0004 is to add doc to explain python script usage and give
example for it.

This patch series has been rebased on acme git tree [1] with the commit
19422a9f2a3b ("perf tools: Fix kernel_start for PTI on x86") and tested
on Hikey (ARM64 octa CA53 cores).

In this version the script has no dependency on ARM64 platform and is
expected to support ARM32 platform, but I am lacking ARM32 platform for
testing on it, so firstly upstream to support ARM64 platform.

This patch series is firstly to support 'per-thread' recording tracing
data, but we also need to verify the script can dump trace disassembler
CPU wide tracing and kernel panic kdump tracing data.  I also verified
this patch series which can work with kernel panic kdump tracing data,
because Mathieu is working on CPU wide tracing related work, so after
this we need to retest for CPU wide tracing and kdump tracing to ensure
the python script can handle well for all cases.

You are very welcome to test the script in this patch series, your
testing result and suggestion are very valuable to perfect this script
to cover more cases.

Changes from v2:
* Synced with Rob for handling CS_ETM_TRACE_ON packet, so refined 0001
  patch according to dicussion;
* Minor cleanup and fixes in 0003 patch for python script: remove 'svc'
  checking.

Changes from v1:
* According to Mike and Rob suggestion, add the fixing to generate samples
  for the start packet and exception packets.
* Simplify the python script to remove the exception prediction algorithm,
  we can rely on the sane exception packets for disassembler.


Leo Yan (4):
  perf cs-etm: Generate branch sample for missed packets
  perf script python: Add addr into perf sample dict
  perf script python: Add script for CoreSight trace disassembler
  coresight: Document for CoreSight trace disassembler

 Documentation/trace/coresight.txt  |  52 +
 tools/perf/scripts/python/arm-cs-trace-disasm.py   | 235 +
 tools/perf/util/cs-etm.c   |  93 ++--
 .../util/scripting-engines/trace-event-python.c|   2 +
 4 files changed, 362 insertions(+), 20 deletions(-)
 create mode 100644 tools/perf/scripts/python/arm-cs-trace-disasm.py

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[RFT v3 1/4] perf cs-etm: Generate branch sample for missed packets

2018-05-28 Thread Leo Yan
Commit e573e978fb12 ("perf cs-etm: Inject capabilitity for CoreSight
traces") reworks the samples generation flow from CoreSight trace to
match the correct format so Perf report tool can display the samples
properly.

But the change has side effect for branch packet handling, it only
generate branch samples by checking previous packet flag
'last_instr_taken_branch' is true, this results in below three kinds
packets are missed to generate branch samples:

- The start tracing packet at the beginning of tracing data;
- The exception handling packet;
- If one CS_ETM_TRACE_ON packet is inserted, we also miss to handle it
  for branch samples.  CS_ETM_TRACE_ON packet itself can give the info
  that there have a discontinuity in the trace, on the other hand we
  also miss to generate proper branch sample for packets before and
  after CS_ETM_TRACE_ON packet.

This patch is to add branch sample handling for up three kinds packets:

- In function cs_etm__sample(), check if 'prev_packet->sample_type' is
  zero and in this case it generates branch sample for the start tracing
  packet; furthermore, we also need to handle the condition for
  prev_packet::end_addr is zero in the cs_etm__last_executed_instr();

- In function cs_etm__sample(), check if 'prev_packet->exc' is true and
  generate branch sample for exception handling packet;

- If there has one CS_ETM_TRACE_ON packet is coming, we firstly generate
  branch sample in the function cs_etm__flush(), this can save complete
  info for the previous CS_ETM_RANGE packet just before CS_ETM_TRACE_ON
  packet.  We also generate branch sample for the new CS_ETM_RANGE
  packet after CS_ETM_TRACE_ON packet, this have two purposes, the
  first one purpose is to save the info for the new CS_ETM_RANGE packet,
  the second purpose is to save CS_ETM_TRACE_ON packet info so we can
  have hint for a discontinuity in the trace.

  For CS_ETM_TRACE_ON packet, its fields 'packet->start_addr' and
  'packet->end_addr' equal to 0xdeadbeefdeadbeefUL which are emitted in
  the decoder layer as dummy value.  This patch is to convert these
  values to zeros for more readable; this is accomplished by functions
  cs_etm__last_executed_instr() and cs_etm__first_executed_instr().  The
  later one is a new function introduced by this patch.

Reviewed-by: Robert Walker <robert.wal...@arm.com>
Fixes: e573e978fb12 ("perf cs-etm: Inject capabilitity for CoreSight traces")
Signed-off-by: Leo Yan <leo@linaro.org>
---
 tools/perf/util/cs-etm.c | 93 +---
 1 file changed, 73 insertions(+), 20 deletions(-)

diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 822ba91..8418173 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -495,6 +495,20 @@ static inline void cs_etm__reset_last_branch_rb(struct 
cs_etm_queue *etmq)
 static inline u64 cs_etm__last_executed_instr(struct cs_etm_packet *packet)
 {
/*
+* The packet is the start tracing packet if the end_addr is zero,
+* returns 0 for this case.
+*/
+   if (!packet->end_addr)
+   return 0;
+
+   /*
+* The packet is the CS_ETM_TRACE_ON packet if the end_addr is
+* magic number 0xdeadbeefdeadbeefUL, returns 0 for this case.
+*/
+   if (packet->end_addr == 0xdeadbeefdeadbeefUL)
+   return 0;
+
+   /*
 * The packet records the execution range with an exclusive end address
 *
 * A64 instructions are constant size, so the last executed
@@ -505,6 +519,18 @@ static inline u64 cs_etm__last_executed_instr(struct 
cs_etm_packet *packet)
return packet->end_addr - A64_INSTR_SIZE;
 }
 
+static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet *packet)
+{
+   /*
+* The packet is the CS_ETM_TRACE_ON packet if the start_addr is
+* magic number 0xdeadbeefdeadbeefUL, returns 0 for this case.
+*/
+   if (packet->start_addr == 0xdeadbeefdeadbeefUL)
+   return 0;
+
+   return packet->start_addr;
+}
+
 static inline u64 cs_etm__instr_count(const struct cs_etm_packet *packet)
 {
/*
@@ -546,7 +572,7 @@ static void cs_etm__update_last_branch_rb(struct 
cs_etm_queue *etmq)
 
be   = >entries[etmq->last_branch_pos];
be->from = cs_etm__last_executed_instr(etmq->prev_packet);
-   be->to   = etmq->packet->start_addr;
+   be->to   = cs_etm__first_executed_instr(etmq->packet);
/* No support for mispredict */
be->flags.mispred = 0;
be->flags.predicted = 1;
@@ -701,7 +727,7 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue 
*etmq)
sample.ip = cs_etm__last_executed_instr(etmq->prev_packet);
sample.pid = etmq->pid;
sample.tid = etmq->tid;
-   sample.addr = etmq->packet->start_addr;
+   sample.addr = cs_etm__first_exe

Re: [RFT v2 1/4] perf cs-etm: Generate sample for missed packets

2018-05-25 Thread Leo Yan
Hi Arnaldo, Rob,

On Fri, May 25, 2018 at 12:27:13PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, May 25, 2018 at 03:03:47PM +0100, Robert Walker escreveu:
> > Hi Leo,
> > 
> > Following the discussions from your reply to this with a simplified patch,
> > this version of the patch works better as you also need to emit a branch
> > sample when handling a CS_ETM_TRACE_ON packet to indicate the end of a block
> > of trace.

I also will follow the suggestion as Rob mentioned in another email:
"The deadbeefdeadbeef addresses are a bit ugly - these are just dummy
values emitted in the decoder layer - maybe these should be changed
to 0."

> > This patch does not break the output from perf inject to generate
> > instruction samples for AutoFDO, so I am happy with that.

Thanks for confirmation.

> > Regards
> > 
> > Rob
> > 
> > Reviewed-by: Robert Walker <robert.wal...@arm.com>
> 
> So, Leo, can you please resubmit, bumping the v2 to v3 (or the latest
> one, I haven't fully reread this thread) add this "Reviewed-by: Robert"
> tag and any other that people may have provided, so that I can merge it?

Sure!  I will respin the v3 patch series by following up Rob's
suggestion and add Rob's review tag.

BTW, I'd like to get ack from Mathieu as well.  Mathieu is working on
CPU wide tracing, so I talked with Mathieu he will review the patch
series if has conflict with CPU wide tracing.

[...]

Thanks,
Leo Yan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFT v2 1/4] perf cs-etm: Generate sample for missed packets

2018-05-23 Thread Leo Yan
Hi Rob,

On Wed, May 23, 2018 at 12:21:18PM +0100, Robert Walker wrote:
> Hi Leo,
> 
> On 22/05/18 10:52, Leo Yan wrote:
> >On Tue, May 22, 2018 at 04:39:20PM +0800, Leo Yan wrote:
> >
> >[...]
> >
> >Rather than the patch I posted in my previous email, I think below new
> >patch is more reasonable for me.
> >
> >In the below change, 'etmq->prev_packet' is only used to store the
> >previous CS_ETM_RANGE packet, we don't need to save CS_ETM_TRACE_ON
> >packet into 'etmq->prev_packet'.
> >
> >On the other hand, cs_etm__flush() can use 'etmq->period_instructions'
> >to indicate if need to generate instruction sample or not.  If it's
> >non-zero, then generate instruction sample and
> >'etmq->period_instructions' will be cleared; so next time if there
> >have more tracing CS_ETM_TRACE_ON packet, it can skip to generate
> >instruction sample due 'etmq->period_instructions' is zero.
> >
> >How about you think for this?
> >
> >Thanks,
> >Leo Yan
> >
> 
> I don't think this covers the cases where CS_ETM_TRACE_ON is used to
> indicate a discontinuity in the trace.  For example, there is work in
> progress to configure the ETM so that it only traces a few thousand cycles
> with a gap of many thousands of cycles between each chunk of trace - this
> can be used to sample program execution in the form of instruction events
> with branch stacks for feedback directed optimization (AutoFDO).
> 
> In this case, the raw trace is something like:
> 
> ...
> I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0x007E7B886908;
> I_ATOM_F3 : Atom format 3.; EEN
> I_ATOM_F1 : Atom format 1.; E
> # Trace stops here
> 
> # Some time passes, and then trace is turned on again
> I_TRACE_ON : Trace On.
> I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, IS0.;
> Addr=0x0057224322F4; Ctxt: AArch64,EL0, NS;
> I_ATOM_F3 : Atom format 3.; ENN
> I_ATOM_F5 : Atom format 5.; ENENE
> ...
> 
> This results in the following packets from the decoder:
> 
> CS_ETM_RANGE: [0x7e7b886908-0x7e7b886930] br
> CS_ETM_RANGE: [0x7e7b88699c-0x7e7b8869a4] br
> CS_ETM_RANGE: [0x7e7b8869d8-0x7e7b8869f0]
> CS_ETM_RANGE: [0x7e7b8869f0-0x7e7b8869fc] br
> CS_ETM_TRACE_ON
> CS_ETM_RANGE: [0x57224322f4-0x5722432304] br
> CS_ETM_RANGE: [0x57224320e8-0x57224320ec]
> CS_ETM_RANGE: [0x57224320ec-0x57224320f8]
> CS_ETM_RANGE: [0x57224320f8-0x572243212c] br
> CS_ETM_RANGE: [0x5722439b80-0x5722439bec]
> CS_ETM_RANGE: [0x5722439bec-0x5722439c14] br
> CS_ETM_RANGE: [0x5722437c30-0x5722437c6c]
> CS_ETM_RANGE: [0x5722437c6c-0x5722437c7c] br
> 
> Without handling the CS_ETM_TRACE_ON, this would be interpreted as a branch
> from 0x7e7b8869f8 to 0x57224322f4, when there is actually a gap of many
> thousand instructions between these.
> 
> I think this patch will break the branch stacks - by removing the
> prev_packet swap from cs_etm__flush(), the next time a CS_ETM_RANGE packet
> is handled, cs_etm__sample() will see prev_packet contains the last
> CS_ETM_RANGE from the previous block of trace, causing an erroneous call to
> cs_etm__update_last_branch_rb().  In the example above, the branch stack
> will contain an erroneous branch from 0x7e7b8869f8 to 0x57224322f4.
> 
> I think what you need to do is add a check for the previous packet being a
> CS_ETM_TRACE_ON when determining the generate_sample value.

I still can see there have hole for packets handling with your
suggestion, let's focus on below three packets:

CS_ETM_RANGE:[0x7e7b8869f0-0x7e7b8869fc] br
CS_ETM_TRACE_ON: [0xdeadbeefdeadbeef-0xdeadbeefdeadbeef]
CS_ETM_RANGE:[0x57224322f4-0x5722432304] br

When the CS_ETM_TRACE_ON packet is coming, cs_etm__flush() doesn't
handle for 'etmq->prev_packet' to generate branch sample, this results
in we miss the info for 0x7e7b8869fc, and with packet swapping
'etmq->prev_packet' is assigned to CS_ETM_TRACE_ON packet.

When the last CS_ETM_RANGE packet is coming, cs_etm__sample() will
combine the values from CS_ETM_TRACE_ON packet and the last
CS_ETM_RANGE packet to generate branch sample packet; at the end
we get below sample packets:

  packet(n):   sample::addr=0x7e7b8869f0
  packet(n+1): sample::ip=0xdeadbeefdeadbeeb sample::addr=0x57224322f4

So I think we also need to generate branch sample, and we can get
below results:

  packet(n):   sample::addr=0x7e7b8869f0
  packet(n+1): sample::ip=0x7e7b8869f8 sample::addr=0xdeadbeefdeadbeef
  packet(n+2): sample::ip=0xdeadbeefdeadbeeb sample::addr=0x57224322f4

So we also can rely on this to get to know there have one address
range is [0xdeadbeefdeadbeef..0xdeadbeefdeadbeeb] to indicate there
have a discontinuity in the trace.

> Regards
> 
> 

Re: [RFT v2 1/4] perf cs-etm: Generate sample for missed packets

2018-05-22 Thread Leo Yan
On Tue, May 22, 2018 at 04:39:20PM +0800, Leo Yan wrote:

[...]

Rather than the patch I posted in my previous email, I think below new
patch is more reasonable for me.

In the below change, 'etmq->prev_packet' is only used to store the
previous CS_ETM_RANGE packet, we don't need to save CS_ETM_TRACE_ON
packet into 'etmq->prev_packet'.

On the other hand, cs_etm__flush() can use 'etmq->period_instructions'
to indicate if need to generate instruction sample or not.  If it's
non-zero, then generate instruction sample and
'etmq->period_instructions' will be cleared; so next time if there
have more tracing CS_ETM_TRACE_ON packet, it can skip to generate
instruction sample due 'etmq->period_instructions' is zero.

How about you think for this?

Thanks,
Leo Yan


diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 822ba91..dd354ad 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -495,6 +495,13 @@ static inline void cs_etm__reset_last_branch_rb(struct 
cs_etm_queue *etmq)
 static inline u64 cs_etm__last_executed_instr(struct cs_etm_packet *packet)
 {
/*
+* The packet is the start tracing packet if the end_addr is zero,
+* returns 0 for this case.
+*/
+   if (!packet->end_addr)
+   return 0;
+
+   /*
 * The packet records the execution range with an exclusive end address
 *
 * A64 instructions are constant size, so the last executed
@@ -897,13 +904,27 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
etmq->period_instructions = instrs_over;
}
 
-   if (etm->sample_branches &&
-   etmq->prev_packet &&
-   etmq->prev_packet->sample_type == CS_ETM_RANGE &&
-   etmq->prev_packet->last_instr_taken_branch) {
-   ret = cs_etm__synth_branch_sample(etmq);
-   if (ret)
-   return ret;
+   if (etm->sample_branches && etmq->prev_packet) {
+   bool generate_sample = false;
+
+   /* Generate sample for start tracing packet */
+   if (etmq->prev_packet->sample_type == 0)
+   generate_sample = true;
+
+   /* Generate sample for exception packet */
+   if (etmq->prev_packet->exc == true)
+   generate_sample = true;
+
+   /* Generate sample for normal branch packet */
+   if (etmq->prev_packet->sample_type == CS_ETM_RANGE &&
+   etmq->prev_packet->last_instr_taken_branch)
+   generate_sample = true;
+
+   if (generate_sample) {
+   ret = cs_etm__synth_branch_sample(etmq);
+   if (ret)
+   return ret;
+   }
}
 
if (etm->sample_branches || etm->synth_opts.last_branch) {
@@ -922,11 +943,12 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
 static int cs_etm__flush(struct cs_etm_queue *etmq)
 {
int err = 0;
-   struct cs_etm_packet *tmp;
 
if (etmq->etm->synth_opts.last_branch &&
etmq->prev_packet &&
-   etmq->prev_packet->sample_type == CS_ETM_RANGE) {
+   etmq->prev_packet->sample_type == CS_ETM_RANGE &&
+   etmq->period_instructions) {
+
/*
 * Generate a last branch event for the branches left in the
 * circular buffer at the end of the trace.
@@ -940,14 +962,6 @@ static int cs_etm__flush(struct cs_etm_queue *etmq)
etmq, addr,
etmq->period_instructions);
etmq->period_instructions = 0;
-
-   /*
-* Swap PACKET with PREV_PACKET: PACKET becomes PREV_PACKET for
-* the next incoming packet.
-*/
-   tmp = etmq->packet;
-   etmq->packet = etmq->prev_packet;
-   etmq->prev_packet = tmp;
}
 
return err;
-- 
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFT v2 1/4] perf cs-etm: Generate sample for missed packets

2018-05-22 Thread Leo Yan
Hi Rob,

On Mon, May 21, 2018 at 12:27:42PM +0100, Robert Walker wrote:
> Hi Leo,
> 
> On 21/05/18 09:52, Leo Yan wrote:
> >Commit e573e978fb12 ("perf cs-etm: Inject capabilitity for CoreSight
> >traces") reworks the samples generation flow from CoreSight trace to
> >match the correct format so Perf report tool can display the samples
> >properly.  But the change has side effect for packet handling, it only
> >generate samples when 'prev_packet->last_instr_taken_branch' is true,
> >this results in the start tracing packet and exception packets are
> >dropped.
> >
> >This patch checks extra two conditions for complete samples:
> >
> >- If 'prev_packet->sample_type' is zero we can use this condition to
> >   get to know this is the start tracing packet; for this case, the start
> >   packet's end_addr is zero as well so we need to handle it in the
> >   function cs_etm__last_executed_instr();
> >
> 
> I think you also need to add something in to handle discontinuities in
> trace - for example it is possible to configure the ETM to only trace
> execution in specific code regions or to trace a few cycles every so
> often. In these cases, prev_packet->sample_type will not be zero, but
> whatever the previous packet was.  You will get a CS_ETM_TRACE_ON packet in
> such cases, generated by an I_TRACE_ON element in the trace stream.
> You also get this on exception return.
> 
> However, you should also keep the test for prev_packet->sample_type == 0
> as you may not see a CS_ETM_TRACE_ON when decoding a buffer that has
> wrapped.

Thanks for reviewing.  Let's dig more detailed into this issue,
especially for handling packet CS_ETM_TRACE_ON, I'd like divide into two
sub cases.

- The first case is for using python script:

  I use python script to analyze packets with below command:
  ./perf script --itrace=ril128 -s arm-cs-trace-disasm.py -F 
cpu,event,ip,addr,sym -- -v -d objdump -k ./vmlinux

  What I observe is after we pass python script with parameter '-s
  arm-cs-trace-disasm.py', then instruction tracing options
  '--itrace=ril128' isn't really used;  the perf tool creates another
  new process for launch python script and re-enter cmd_script()
  function, but at the second time when invoke cmd_script() for python
  script execution the option '--itrace=ril128' is dropped and all
  parameters are only valid defined by the python script.

  As result, I can the variable 'etmq->etm->synth_opts.last_branch' is
  always FALSE for running python script.  So all CS_ETM_TRACE_ON
  packets will be ignored in the function cs_etm__flush().

  Even the CS_ETM_TRACE_ON packets are missed to handle, the program
  flow still can work well.  The reason is without the interference by
  CS_ETM_TRACE_ON, the CS_ETM_RANGE packets can smoothly create
  instruction range by ignore the middle CS_ETM_TRACE_ON packet.

  Please see below example, in this example there have 3 packets, the
  first one packet is CS_ETM_RANGE packet which is labelled with
  'PACKET_1', the first one packet can properly generate branch sample
  data with previous packet as expected;  the second packet is
  PACKET_2 which is CS_ETM_TRACE_ON, but
  'etmq->etm->synth_opts.last_branch' is false so function
  cs_etm__flush() doesn't handle it and skip the swap operation
  "etmq->prev_packet = tmp"; the third packet is PACKET_3, which is
  CS_ETM_RANGE packet and we can see it's smoontly to create
  continous instruction range between PACKET_1 and PACKET_3.

  cs_etm__sample: prev_packet: sample_type=1 exc=0 exc_ret=0 cpu=1 
start_addr=0x08a5f79c end_addr=0x08a5f7bc 
last_instr_taken_branch=1
  PACKET_1: cs_etm__sample: packet: sample_type=1 exc=0 exc_ret=0 cpu=1 
start_addr=0x08a5f858 end_addr=0x08a5f864 
last_instr_taken_branch=1
  cs_etm__synth_branch_sample: ip=0x08a5f7b8 addr=0x08a5f858 
pid=2290 tid=2290 id=100021 stream_id=100021 period=1 cpu=1 flags=0 
cpumode=2

  cs_etm__flush: prev_packet: sample_type=1 exc=0 exc_ret=0 cpu=1 
start_addr=0x08a5f858 end_addr=0x08a5f864 
last_instr_taken_branch=1
  PACKET_2: cs_etm__flush: packet: sample_type=2 exc=0 exc_ret=0 cpu=2 
start_addr=0xdeadbeefdeadbeef end_addr=0xdeadbeefdeadbeef 
last_instr_taken_branch=1

  cs_etm__sample: prev_packet: sample_type=1 exc=0 exc_ret=0 cpu=1 
start_addr=0x08a5f858 end_addr=0x08a5f864 
last_instr_taken_branch=1
  PACKET_3: cs_etm__sample: packet: sample_type=1 exc=0 exc_ret=0 cpu=2 
start_addr=0x08be7528 end_addr=0x08be7538 
last_instr_taken_branch=1
  cs_etm__synth_branch_sample: ip=0x08a5f860 addr=0x08be7528 
pid=2290 tid=2290 id=100021 stream_id=100021 period=1 cpu=2 flags=0 
cpumode=2

  So seems to me, the CS_ETM_TRACE_ON packet doesn't introduce trouble
  for the

[RFT v2 1/4] perf cs-etm: Generate sample for missed packets

2018-05-21 Thread Leo Yan
Commit e573e978fb12 ("perf cs-etm: Inject capabilitity for CoreSight
traces") reworks the samples generation flow from CoreSight trace to
match the correct format so Perf report tool can display the samples
properly.  But the change has side effect for packet handling, it only
generate samples when 'prev_packet->last_instr_taken_branch' is true,
this results in the start tracing packet and exception packets are
dropped.

This patch checks extra two conditions for complete samples:

- If 'prev_packet->sample_type' is zero we can use this condition to
  get to know this is the start tracing packet; for this case, the start
  packet's end_addr is zero as well so we need to handle it in the
  function cs_etm__last_executed_instr();

- If 'prev_packet->exc' is true, we can know the previous packet is
  exception handling packet so need to generate sample for exception
  flow.

Fixes: e573e978fb12 ("perf cs-etm: Inject capabilitity for CoreSight traces")
Cc: Mike Leach <mike.le...@arm.com>
Cc: Robert Walker <robert.wal...@arm.com>
Cc: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 tools/perf/util/cs-etm.c | 35 ---
 1 file changed, 28 insertions(+), 7 deletions(-)

diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 822ba91..378953b 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -495,6 +495,13 @@ static inline void cs_etm__reset_last_branch_rb(struct 
cs_etm_queue *etmq)
 static inline u64 cs_etm__last_executed_instr(struct cs_etm_packet *packet)
 {
/*
+* The packet is the start tracing packet if the end_addr is zero,
+* returns 0 for this case.
+*/
+   if (!packet->end_addr)
+   return 0;
+
+   /*
 * The packet records the execution range with an exclusive end address
 *
 * A64 instructions are constant size, so the last executed
@@ -897,13 +904,27 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
etmq->period_instructions = instrs_over;
}
 
-   if (etm->sample_branches &&
-   etmq->prev_packet &&
-   etmq->prev_packet->sample_type == CS_ETM_RANGE &&
-   etmq->prev_packet->last_instr_taken_branch) {
-   ret = cs_etm__synth_branch_sample(etmq);
-   if (ret)
-   return ret;
+   if (etm->sample_branches && etmq->prev_packet) {
+   bool generate_sample = false;
+
+   /* Generate sample for start tracing packet */
+   if (etmq->prev_packet->sample_type == 0)
+   generate_sample = true;
+
+   /* Generate sample for exception packet */
+   if (etmq->prev_packet->exc == true)
+   generate_sample = true;
+
+   /* Generate sample for normal branch packet */
+   if (etmq->prev_packet->sample_type == CS_ETM_RANGE &&
+   etmq->prev_packet->last_instr_taken_branch)
+   generate_sample = true;
+
+   if (generate_sample) {
+   ret = cs_etm__synth_branch_sample(etmq);
+   if (ret)
+   return ret;
+   }
}
 
if (etm->sample_branches || etm->synth_opts.last_branch) {
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[RFT v2 0/4] Perf script: Add python script for CoreSight trace disassembler

2018-05-21 Thread Leo Yan
This patch series is to support for using 'perf script' for CoreSight
trace disassembler, for this purpose this patch series adds a new
python script to parse CoreSight tracing event and use command 'objdump'
for disassembled lines, finally this can generate readable program
execution flow for reviewing tracing data.

Patch 0001 is one fixing patch to generate samples for the start packet
and exception packets.

Patch 0002 is the prerequisite to add addr into sample dict, so this
value can be used by python script to analyze instruction range.

Patch 0003 is to add python script for trace disassembler.

Patch 0004 is to add doc to explain python script usage and give
example for it.

This patch series has been rebased on acme git tree [1] with the last
commit 19422a9f2a3b ("perf tools: Fix kernel_start for PTI on x86") and
tested on Hikey (ARM64 octa CA53 cores).

In this version the script has no dependency on ARM64 platform and is
expected to support ARM32 platform, but I am lacking ARM32 platform for
testing on it, so firstly upstream to support ARM64 platform.

This patch series is firstly to support 'per-thread' recording tracing
data, but we also need to verify the script can dump trace disassembler
CPU wide tracing and kernel panic kdump tracing data.  I also verified
this patch series which can work with kernel panic kdump tracing data,
because Mathieu is working on CPU wide tracing related work, so after
this we need to retest for CPU wide tracing and kdump tracing to ensure
the python script can handle well for all cases.

You are very welcome to test the script in this patch series, your
testing result and suggestion are very valuable to perfect this script
to cover more cases.

Changes from v1:
* According to Mike and Rob suggestion, add the fixing to generate samples
  for the start packet and exception packets.
* Simplify the python script to remove the exception prediction algorithm,
  we can rely on the sane exception packets for disassembler.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git


Leo Yan (4):
  perf cs-etm: Generate sample for missed packets
  perf script python: Add addr into perf sample dict
  perf script python: Add script for CoreSight trace disassembler
  coresight: Document for CoreSight trace disassembler

 Documentation/trace/coresight.txt  |  52 +
 tools/perf/scripts/python/arm-cs-trace-disasm.py   | 234 +
 tools/perf/util/cs-etm.c   |  35 ++-
 .../util/scripting-engines/trace-event-python.c|   2 +
 4 files changed, 316 insertions(+), 7 deletions(-)
 create mode 100644 tools/perf/scripts/python/arm-cs-trace-disasm.py

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[RFT v2 4/4] coresight: Document for CoreSight trace disassembler

2018-05-21 Thread Leo Yan
This commit documents CoreSight trace disassembler usage and gives
example for it.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 Documentation/trace/coresight.txt | 52 +++
 1 file changed, 52 insertions(+)

diff --git a/Documentation/trace/coresight.txt 
b/Documentation/trace/coresight.txt
index 6f0120c..b8f2359 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -381,3 +381,55 @@ sort example is from the AutoFDO tutorial 
(https://gcc.gnu.org/wiki/AutoFDO/Tuto
$ taskset -c 2 ./sort_autofdo
Bubble sorting array of 3 elements
5806 ms
+
+
+Tracing data disassembler
+-
+
+'perf script' supports to use script to parse tracing packet and rely on
+'objdump' for disassembled lines, this can convert tracing data to readable
+program execution flow for easily reviewing tracing data.
+
+The CoreSight trace disassembler is located in the folder:
+tools/perf/scripts/python/arm-cs-trace-disasm.py.  This script support below
+options:
+
+   -d, --objdump: Set path to objdump executable, this option is
+  mandatory.
+   -k, --vmlinux: Set path to vmlinux file.
+   -v, --verbose: Enable debugging log, after enable this option the
+  script dumps every event data.
+
+Below is one example for using python script to dump CoreSight trace
+disassembler:
+
+   $ perf script -s arm-cs-trace-disasm.py -i perf.data \
+   -F cpu,event,ip,addr,sym -- -d objdump -k ./vmlinux > cs-disasm.log
+
+Below is one example for the disassembler log:
+
+ARM CoreSight Trace Data Assembler Dump
+   08a5f2dc <etm4_enable_hw+0x344>:
+   08a5f2dc:   34a0cbz w0, 08a5f2f0 
<etm4_enable_hw+0x358>
+   08a5f2f0 <etm4_enable_hw+0x358>:
+   08a5f2f0:   f9400260ldr x0, [x19]
+   08a5f2f4:   d5033f9fdsb sy
+   08a5f2f8:   913ec000add x0, x0, #0xfb0
+   08a5f2fc:   b91fstr wzr, [x0]
+   08a5f300:   f9400bf3ldr x19, [sp, #16]
+   08a5f304:   a8c27bfdldp x29, x30, [sp], #32
+   08a5f308:   d65f03c0ret
+   08a5fa18 <etm4_enable+0x1b0>:
+   08a5fa18:   1425b   08a5faac 
<etm4_enable+0x244>
+   08a5faac <etm4_enable+0x244>:
+   08a5faac:   b9406261ldr w1, [x19, #96]
+   08a5fab0:   52800015mov w21, #0x0   
// #0
+   08a5fab4:   f901ca61str x1, [x19, #912]
+   08a5fab8:   2a1503e0mov w0, w21
+   08a5fabc:   3940e261ldrbw1, [x19, #56]
+   08a5fac0:   f901ce61str x1, [x19, #920]
+   08a5fac4:   a94153f3ldp x19, x20, [sp, #16]
+   08a5fac8:   a9425bf5ldp x21, x22, [sp, #32]
+   08a5facc:   a94363f7ldp x23, x24, [sp, #48]
+   08a5fad0:   a8c47bfdldp x29, x30, [sp], #64
+   08a5fad4:   d65f03c0ret
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[RFT v2 2/4] perf script python: Add addr into perf sample dict

2018-05-21 Thread Leo Yan
ARM CoreSight auxtrace uses 'sample->addr' to record the target address
for branch instructions, so the data of 'sample->addr' is required for
tracing data analysis.

This commit collects data of 'sample->addr' into perf sample dict,
finally can be used for python script for parsing event.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 tools/perf/util/scripting-engines/trace-event-python.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/util/scripting-engines/trace-event-python.c 
b/tools/perf/util/scripting-engines/trace-event-python.c
index 10dd5fc..7f8afac 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -531,6 +531,8 @@ static PyObject *get_perf_sample_dict(struct perf_sample 
*sample,
PyLong_FromUnsignedLongLong(sample->period));
pydict_set_item_string_decref(dict_sample, "phys_addr",
PyLong_FromUnsignedLongLong(sample->phys_addr));
+   pydict_set_item_string_decref(dict_sample, "addr",
+   PyLong_FromUnsignedLongLong(sample->addr));
set_sample_read_in_dict(dict_sample, sample, evsel);
pydict_set_item_string_decref(dict, "sample", dict_sample);
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] coresight: Remove %px for printing pcsr value

2018-05-02 Thread Leo Yan
On Tue, May 01, 2018 at 10:29:46PM -0700, Kees Cook wrote:
> On Tue, May 1, 2018 at 10:00 PM, Leo Yan <leo@linaro.org> wrote:
> > The driver prints pcsr twice: the first time it uses specifier %px to
> > print hexadecimal pcsr value and the second time uses specifier %pS for
> > output kernel symbols.
> >
> > As suggested by Kees, using %pS should be sufficient and %px isn't
> > necessary; the reason is if the pcsr is a kernel space address, we can
> > easily get to know the code line from %pS format, on the other hand, if
> > the pcsr value doesn't fall into kernel space range (e.g. if the CPU is
> > stuck in firmware), %pS also gives out pcsr hexadecimal value.
> >
> > So this commit removes useless %px and update section "Output format"
> > in the document for alignment between the code and document.
> >
> > Suggested-by: Kees Cook <keesc...@chromium.org>
> > Cc: Mathieu Poirier <mathieu.poir...@linaro.org>
> > Signed-off-by: Leo Yan <leo@linaro.org>
> 
> Thanks!
> 
> Reviewed-by: Kees Cook <keesc...@chromium.org>

Thanks for reviewing, Kees.

> -Kees
> 
> > ---
> >  Documentation/trace/coresight-cpu-debug.txt   | 4 ++--
> >  drivers/hwtracing/coresight/coresight-cpu-debug.c | 2 +-
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/trace/coresight-cpu-debug.txt 
> > b/Documentation/trace/coresight-cpu-debug.txt
> > index 2b9b51c..89ab09e 100644
> > --- a/Documentation/trace/coresight-cpu-debug.txt
> > +++ b/Documentation/trace/coresight-cpu-debug.txt
> > @@ -177,11 +177,11 @@ Here is an example of the debugging output format:
> >  ARM external debug module:
> >  coresight-cpu-debug 85.debug: CPU[0]:
> >  coresight-cpu-debug 85.debug:  EDPRSR:  0001 (Power:On DLK:Unlock)
> > -coresight-cpu-debug 85.debug:  EDPCSR:  [] 
> > handle_IPI+0x174/0x1d8
> > +coresight-cpu-debug 85.debug:  EDPCSR:  handle_IPI+0x174/0x1d8
> >  coresight-cpu-debug 85.debug:  EDCIDSR: 
> >  coresight-cpu-debug 85.debug:  EDVIDSR: 9000 (State:Non-secure 
> > Mode:EL1/0 Width:64bits VMID:0)
> >  coresight-cpu-debug 852000.debug: CPU[1]:
> >  coresight-cpu-debug 852000.debug:  EDPRSR:  0001 (Power:On DLK:Unlock)
> > -coresight-cpu-debug 852000.debug:  EDPCSR:  [] 
> > debug_notifier_call+0x23c/0x358
> > +coresight-cpu-debug 852000.debug:  EDPCSR:  debug_notifier_call+0x23c/0x358
> >  coresight-cpu-debug 852000.debug:  EDCIDSR: 
> >  coresight-cpu-debug 852000.debug:  EDVIDSR: 9000 (State:Non-secure 
> > Mode:EL1/0 Width:64bits VMID:0)
> > diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c 
> > b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> > index 9cdb3fb..78a054e 100644
> > --- a/drivers/hwtracing/coresight/coresight-cpu-debug.c
> > +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> > @@ -315,7 +315,7 @@ static void debug_dump_regs(struct debug_drvdata 
> > *drvdata)
> > }
> >
> > pc = debug_adjust_pc(drvdata);
> > -   dev_emerg(dev, " EDPCSR:  [<%px>] %pS\n", (void *)pc, (void *)pc);
> > +   dev_emerg(dev, " EDPCSR:  %pS\n", (void *)pc);
> >
> > if (drvdata->edcidsr_present)
> > dev_emerg(dev, " EDCIDSR: %08x\n", drvdata->edcidsr);
> > --
> > 2.7.4
> >
> 
> 
> 
> -- 
> Kees Cook
> Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] coresight: Remove %px for printing pcsr value

2018-05-01 Thread Leo Yan
The driver prints pcsr twice: the first time it uses specifier %px to
print hexadecimal pcsr value and the second time uses specifier %pS for
output kernel symbols.

As suggested by Kees, using %pS should be sufficient and %px isn't
necessary; the reason is if the pcsr is a kernel space address, we can
easily get to know the code line from %pS format, on the other hand, if
the pcsr value doesn't fall into kernel space range (e.g. if the CPU is
stuck in firmware), %pS also gives out pcsr hexadecimal value.

So this commit removes useless %px and update section "Output format"
in the document for alignment between the code and document.

Suggested-by: Kees Cook <keesc...@chromium.org>
Cc: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 Documentation/trace/coresight-cpu-debug.txt   | 4 ++--
 drivers/hwtracing/coresight/coresight-cpu-debug.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/trace/coresight-cpu-debug.txt 
b/Documentation/trace/coresight-cpu-debug.txt
index 2b9b51c..89ab09e 100644
--- a/Documentation/trace/coresight-cpu-debug.txt
+++ b/Documentation/trace/coresight-cpu-debug.txt
@@ -177,11 +177,11 @@ Here is an example of the debugging output format:
 ARM external debug module:
 coresight-cpu-debug 85.debug: CPU[0]:
 coresight-cpu-debug 85.debug:  EDPRSR:  0001 (Power:On DLK:Unlock)
-coresight-cpu-debug 85.debug:  EDPCSR:  [] 
handle_IPI+0x174/0x1d8
+coresight-cpu-debug 85.debug:  EDPCSR:  handle_IPI+0x174/0x1d8
 coresight-cpu-debug 85.debug:  EDCIDSR: 
 coresight-cpu-debug 85.debug:  EDVIDSR: 9000 (State:Non-secure 
Mode:EL1/0 Width:64bits VMID:0)
 coresight-cpu-debug 852000.debug: CPU[1]:
 coresight-cpu-debug 852000.debug:  EDPRSR:  0001 (Power:On DLK:Unlock)
-coresight-cpu-debug 852000.debug:  EDPCSR:  [] 
debug_notifier_call+0x23c/0x358
+coresight-cpu-debug 852000.debug:  EDPCSR:  debug_notifier_call+0x23c/0x358
 coresight-cpu-debug 852000.debug:  EDCIDSR: 
 coresight-cpu-debug 852000.debug:  EDVIDSR: 9000 (State:Non-secure 
Mode:EL1/0 Width:64bits VMID:0)
diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c 
b/drivers/hwtracing/coresight/coresight-cpu-debug.c
index 9cdb3fb..78a054e 100644
--- a/drivers/hwtracing/coresight/coresight-cpu-debug.c
+++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
@@ -315,7 +315,7 @@ static void debug_dump_regs(struct debug_drvdata *drvdata)
}
 
pc = debug_adjust_pc(drvdata);
-   dev_emerg(dev, " EDPCSR:  [<%px>] %pS\n", (void *)pc, (void *)pc);
+   dev_emerg(dev, " EDPCSR:  %pS\n", (void *)pc);
 
if (drvdata->edcidsr_present)
dev_emerg(dev, " EDCIDSR: %08x\n", drvdata->edcidsr);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH bpf-next v2] bpf, doc: Update bpf_jit_enable limitation for CONFIG_BPF_JIT_ALWAYS_ON

2018-04-27 Thread Leo Yan
When CONFIG_BPF_JIT_ALWAYS_ON is enabled, kernel has limitation for
bpf_jit_enable, so it has fixed value 1 and we cannot set it to 2
for JIT opcode dumping; this patch is to update the doc for it.

Suggested-by: Daniel Borkmann <dan...@iogearbox.net>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 Documentation/networking/filter.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/networking/filter.txt 
b/Documentation/networking/filter.txt
index fd55c7d..5032e12 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -483,6 +483,12 @@ Example output from dmesg:
 [ 3389.935851] JIT code: 0030: 00 e8 28 94 ff e0 83 f8 01 75 07 b8 ff ff 
00 00
 [ 3389.935852] JIT code: 0040: eb 02 31 c0 c9 c3
 
+When CONFIG_BPF_JIT_ALWAYS_ON is enabled, bpf_jit_enable is permanently set to 
1 and
+setting any other value than that will return in failure. This is even the 
case for
+setting bpf_jit_enable to 2, since dumping the final JIT image into the kernel 
log
+is discouraged and introspection through bpftool (under tools/bpf/bpftool/) is 
the
+generally recommended approach instead.
+
 In the kernel source tree under tools/bpf/, there's bpf_jit_disasm for
 generating disassembly out of the kernel log's hexdump:
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH bpf-next] bpf, doc: Update bpf_jit_enable limitation for CONFIG_BPF_JIT_ALWAYS_ON

2018-04-27 Thread Leo Yan
On Fri, Apr 27, 2018 at 11:44:44AM +0200, Daniel Borkmann wrote:
> On 04/26/2018 04:26 AM, Leo Yan wrote:
> > When CONFIG_BPF_JIT_ALWAYS_ON is enabled, kernel has limitation for
> > bpf_jit_enable, so it has fixed value 1 and we cannot set it to 2
> > for JIT opcode dumping; this patch is to update the doc for it.
> > 
> > Signed-off-by: Leo Yan <leo@linaro.org>
> > ---
> >  Documentation/networking/filter.txt | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/Documentation/networking/filter.txt 
> > b/Documentation/networking/filter.txt
> > index fd55c7d..feddab9 100644
> > --- a/Documentation/networking/filter.txt
> > +++ b/Documentation/networking/filter.txt
> > @@ -483,6 +483,12 @@ Example output from dmesg:
> >  [ 3389.935851] JIT code: 0030: 00 e8 28 94 ff e0 83 f8 01 75 07 b8 ff 
> > ff 00 00
> >  [ 3389.935852] JIT code: 0040: eb 02 31 c0 c9 c3
> >  
> > +When CONFIG_BPF_JIT_ALWAYS_ON is enabled, bpf_jit_enable is set to 1 by 
> > default
> > +and it returns failure if change to any other value from proc node; this is
> > +for security consideration to avoid leaking info to unprivileged users. In 
> > this
> > +case, we can't directly dump JIT opcode image from kernel log, 
> > alternatively we
> > +need to use bpf tool for the dumping.
> > +
> 
> Could you change this doc text a bit, I think it's slightly misleading. From 
> the first
> sentence one could also interpret that value 0 would leaking info to 
> unprivileged users
> whereas here we're only talking about the case of value 2. Maybe something 
> roughly like
> this to make it more clear:
> 
>   When CONFIG_BPF_JIT_ALWAYS_ON is enabled, bpf_jit_enable is permanently set 
> to 1 and
>   setting any other value than that will return in failure. This is even the 
> case for
>   setting bpf_jit_enable to 2, since dumping the final JIT image into the 
> kernel log
>   is discouraged and introspection through bpftool (under tools/bpf/bpftool/) 
> is the
>   generally recommended approach instead.

Yeah, your rephrasing is more clear and better.  Will do this and send
new patch soon.  Thanks for your helping.

> Thanks,
> Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH bpf-next] bpf, doc: Update bpf_jit_enable limitation for CONFIG_BPF_JIT_ALWAYS_ON

2018-04-25 Thread Leo Yan
When CONFIG_BPF_JIT_ALWAYS_ON is enabled, kernel has limitation for
bpf_jit_enable, so it has fixed value 1 and we cannot set it to 2
for JIT opcode dumping; this patch is to update the doc for it.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 Documentation/networking/filter.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/networking/filter.txt 
b/Documentation/networking/filter.txt
index fd55c7d..feddab9 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -483,6 +483,12 @@ Example output from dmesg:
 [ 3389.935851] JIT code: 0030: 00 e8 28 94 ff e0 83 f8 01 75 07 b8 ff ff 
00 00
 [ 3389.935852] JIT code: 0040: eb 02 31 c0 c9 c3
 
+When CONFIG_BPF_JIT_ALWAYS_ON is enabled, bpf_jit_enable is set to 1 by default
+and it returns failure if change to any other value from proc node; this is
+for security consideration to avoid leaking info to unprivileged users. In this
+case, we can't directly dump JIT opcode image from kernel log, alternatively we
+need to use bpf tool for the dumping.
+
 In the kernel source tree under tools/bpf/, there's bpf_jit_disasm for
 generating disassembly out of the kernel log's hexdump:
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v4 2/6] doc: Add documentation for Coresight panic kdump

2018-03-29 Thread Leo Yan
Add detailed documentation for Coresight panic kdump, which contains
the idea for why need Coresight panic kdump and introduce the
implementation of Coresight panic kdump framework; the last section is
to explain what's usage.

Credits to Mathieu Poirier for many suggestions since the first version
patch reviewing.  The suggestions include using an array to manage dump
related info, this makes code scalable for more CPUs; the Coresight
kdump driver and integration kdump flow with other Coresight devices
also have many ideas from Mathieu.

Suggested-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 .../trace/coresight/coresight-panic-kdump.txt  | 130 +
 MAINTAINERS|   1 +
 2 files changed, 131 insertions(+)
 create mode 100644 Documentation/trace/coresight/coresight-panic-kdump.txt

diff --git a/Documentation/trace/coresight/coresight-panic-kdump.txt 
b/Documentation/trace/coresight/coresight-panic-kdump.txt
new file mode 100644
index 000..c02e520
--- /dev/null
+++ b/Documentation/trace/coresight/coresight-panic-kdump.txt
@@ -0,0 +1,130 @@
+   Coresight Panic Kdump
+   =
+
+   Author:   Leo Yan <leo@linaro.org>
+   Date: March 29th, 2018
+
+Introduction
+
+
+Coresight has different sinks for trace data, the trace data is quite useful
+for postmortem debugging.  Embedded Trace Buffer (ETB) is one type sink which
+provides on-chip storage of trace data, usually uses SRAM as the buffer with
+several KBs size; if the SoC designs to support 'Local ETF' (ARM DDI 0461B,
+chapter 1.2.7), every CPU has one local ETB buffer so the per CPU trace data
+can avoid being overwritten by each other.  Trace Memory Controller (TMC) is
+another kind sink designed as a successor to the CoreSight ETB to capture trace
+into DRAM.
+
+After Linux kernel panic has occurred, the trace data keeps the last execution
+flow before issues happen.  We could consider the trace data is quite useful 
for
+postmortem debugging, especially when we can save trace data into DRAM and 
rely on
+kdump to preserve them into vmcore file; at the end, we can retrieve trace data
+from vmcore file and "offline" to analyze the execution flow.
+
+
+Implementation
+--
+
+Coresight panic kdump is a simple framework to support Coresight dump
+functionality when panic happens, it maintains an array for the dump, every 
array
+item is dedicated to one specific CPU by using CPU number as an index.  For
+'offline' recovery and analysis Coresight tracing data, except should to 
recovery
+tracing data for sinks, we also need to know CPU tracer configurations; for 
this
+purpose, the array item is a structure which combines source and sink device
+handlers, the device handler points to Coresight device structure which 
contains
+dump info: dump buffer base address and buffer size.  Below diagram is to
+present data structures relationship:
+
+  array: coresight_kdump_nodes
+  +--+--+--+
+  | CPU0 | CPU1 |   ...|
+  +--+--+--+
+ |
+ V
+  coresight_kdump_node  coresight_device
+  +---+ +---+
+  |source_csdev   | --> |kdump_buf  |
+  +---+  /  +---+
+  |sink_csdev | '   |kdump_buf_sz   |
+  +---+ +---+
+
+Every CPU has its own tracer, we need save tracer registers for tracer ID and
+configuration related information as metadata, the metadata is used by tracing
+decoder.  But the tracer has the different configuration at the different 
phase,
+below diagram explains tracer configurations for different time points: at the
+system boot phase, the tracer is disabled so its registers have not been set;
+after tracer has been enabled or when panic happens, tracer registers have been
+configured, but we need to consider if there has CPU is locked up at panic 
phase
+then this dead CPU has no chance to handle inter-processor interrupt for panic
+dump; thus we choose tracer enabling phase to save tracer metadata.  Coresight
+panic kdump provides API coresight_kdump_source() as helper function for
+recording tracer metadata.
+
+ Boot Enabling Panic
+
+  Timeline:  --->|--->|--->|--->
+
+  Tracer:Disabled Configured   Configured
+  Sink:  Disabled Enabled  Enabled with tracing data
+||
+|`--> Tracing data dump
+|
+`--> Tracer metadata dump
+
+After enabling Coresight sink device, function coresight_kdump_sink() is used 
to
+set

[PATCH v4 5/6] coresight: Set and clear sink device handler for kdump node

2018-03-29 Thread Leo Yan
If Coresight path is enabled for specific CPU, the sink device handler
need to be set to kdump node; on the other hand we also need to clear
sink device handler when path is disabled.

This patch sets sink devices handler for kdump node for two separate
Coresight enabling modes: CS_MODE_SYSFS and CS_MODE_PERF; and clear the
handler when Coresight is disabled.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm-perf.c |  5 +
 drivers/hwtracing/coresight/coresight.c  | 16 ++--
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c 
b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 8a0ad77..f8b159c 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -139,6 +139,8 @@ static void free_event_data(struct work_struct *work)
for_each_cpu(cpu, mask) {
if (!(IS_ERR_OR_NULL(event_data->path[cpu])))
coresight_release_path(event_data->path[cpu]);
+
+   coresight_kdump_sink(cpu, NULL);
}
 
kfree(event_data->path);
@@ -238,6 +240,9 @@ static void *etm_setup_aux(int event_cpu, void **pages,
event_data->path[cpu] = coresight_build_path(csdev, sink);
if (IS_ERR(event_data->path[cpu]))
goto err;
+
+   if (coresight_kdump_sink(cpu, sink))
+   goto err;
}
 
if (!sink_ops(sink)->alloc_buffer)
diff --git a/drivers/hwtracing/coresight/coresight.c 
b/drivers/hwtracing/coresight/coresight.c
index 389c4ba..483a1f7 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -272,6 +272,7 @@ static int coresight_enable_source(struct coresight_device 
*csdev, u32 mode)
 static bool coresight_disable_source(struct coresight_device *csdev)
 {
if (atomic_dec_return(csdev->refcnt) == 0) {
+
if (source_ops(csdev)->disable)
source_ops(csdev)->disable(csdev, NULL);
csdev->enable = false;
@@ -612,6 +613,13 @@ int coresight_enable(struct coresight_device *csdev)
if (ret)
goto err_source;
 
+   cpu = source_ops(csdev)->cpu_id(csdev);
+
+   /* Set sink device handler into kdump node */
+   ret = coresight_kdump_sink(cpu, sink);
+   if (ret)
+   goto err_kdump;
+
switch (subtype) {
case CORESIGHT_DEV_SUBTYPE_SOURCE_PROC:
/*
@@ -621,7 +629,6 @@ int coresight_enable(struct coresight_device *csdev)
 * be a single session per tracer (when working from sysFS)
 * a per-cpu variable will do just fine.
 */
-   cpu = source_ops(csdev)->cpu_id(csdev);
per_cpu(tracer_path, cpu) = path;
break;
case CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE:
@@ -636,6 +643,9 @@ int coresight_enable(struct coresight_device *csdev)
mutex_unlock(_mutex);
return ret;
 
+err_kdump:
+   coresight_disable_source(csdev);
+
 err_source:
coresight_disable_path(path);
 
@@ -659,9 +669,10 @@ void coresight_disable(struct coresight_device *csdev)
if (!csdev->enable || !coresight_disable_source(csdev))
goto out;
 
+   cpu = source_ops(csdev)->cpu_id(csdev);
+
switch (csdev->subtype.source_subtype) {
case CORESIGHT_DEV_SUBTYPE_SOURCE_PROC:
-   cpu = source_ops(csdev)->cpu_id(csdev);
path = per_cpu(tracer_path, cpu);
per_cpu(tracer_path, cpu) = NULL;
break;
@@ -674,6 +685,7 @@ void coresight_disable(struct coresight_device *csdev)
break;
}
 
+   coresight_kdump_sink(cpu, NULL);
coresight_disable_path(path);
coresight_release_path(path);
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v4 3/6] coresight: Support panic kdump functionality

2018-03-29 Thread Leo Yan
After kernel panic happens, Coresight tracing data has much useful info
which can be used for analysis.  For example, the trace info from ETB
RAM can be used to check the CPU execution flows before the crash.  So
we can save the tracing data from sink devices, and rely on kdump to
save DDR content and uses "crash" tool to extract Coresight dumping
from the vmcore file.

This patch is to add a simple framework to support panic dump
functionality; it registers panic notifier, and provide the helper
functions coresight_kdump_source()/coresight_kdump_sink() so Coresight
source and sink devices can be recorded into Coresight kdump node for
kernel panic kdump.

When kernel panic happens, the notifier iterates dump array and invoke
callback function to dump tracing data.  Later the tracing data can be
used to reverse execution flow before the kernel panic.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/Kconfig|   9 +
 drivers/hwtracing/coresight/Makefile   |   1 +
 .../hwtracing/coresight/coresight-panic-kdump.c| 199 +
 drivers/hwtracing/coresight/coresight-priv.h   |  12 ++
 include/linux/coresight.h  |   4 +
 5 files changed, 225 insertions(+)
 create mode 100644 drivers/hwtracing/coresight/coresight-panic-kdump.c

diff --git a/drivers/hwtracing/coresight/Kconfig 
b/drivers/hwtracing/coresight/Kconfig
index ef9cb3c..3089abf 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -103,4 +103,13 @@ config CORESIGHT_CPU_DEBUG
  properly, please refer Documentation/trace/coresight-cpu-debug.txt
  for detailed description and the example for usage.
 
+config CORESIGHT_PANIC_KDUMP
+   bool "CoreSight Panic Kdump driver"
+   depends on ARM || ARM64
+   help
+ This driver provides panic kdump functionality for CoreSight devices.
+ When kernel panic happen Coresight device supplied callback function
+ is to dump trace data to memory. From then on, kdump can be used to
+ extract the trace data from kernel dump file.
+
 endif
diff --git a/drivers/hwtracing/coresight/Makefile 
b/drivers/hwtracing/coresight/Makefile
index 61db9dd..946fe19 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
 obj-$(CONFIG_CORESIGHT_DYNAMIC_REPLICATOR) += coresight-dynamic-replicator.o
 obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
 obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
+obj-$(CONFIG_CORESIGHT_PANIC_KDUMP) += coresight-panic-kdump.o
diff --git a/drivers/hwtracing/coresight/coresight-panic-kdump.c 
b/drivers/hwtracing/coresight/coresight-panic-kdump.c
new file mode 100644
index 000..f4589e9
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-panic-kdump.c
@@ -0,0 +1,199 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017~2018 Linaro Limited.
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "coresight-priv.h"
+
+/**
+ * struct coresight_kdump_node - Node information for dump
+ * @source_csdev:  Handler for source coresight device
+ * @sink_csdev:Handler for sink coresight device
+ */
+struct coresight_kdump_node {
+   struct coresight_device *source_csdev;
+   struct coresight_device *sink_csdev;
+};
+
+static DEFINE_SPINLOCK(coresight_kdump_lock);
+static struct coresight_kdump_node *coresight_kdump_nodes;
+static struct notifier_block coresight_kdump_nb;
+
+/**
+ * coresight_kdump_source - Set source dump info for specific CPU
+ * @cpu:   CPU ID
+ * @csdev: Source device structure handler
+ * @data:  Pointer for source device metadata buffer
+ * @data_sz:   Size of source device metadata buffer
+ *
+ * This function is a helper function which is used to set/clear source device
+ * handler and metadata when the tracer is enabled; and it can be used to clear
+ * source device related info when the tracer is disabled.
+ *
+ * Returns:0 on success, negative errno otherwise.
+ */
+int coresight_kdump_source(int cpu, struct coresight_device *csdev,
+  char *data, unsigned int data_sz)
+{
+   struct coresight_kdump_node *node;
+   unsigned long flags;
+
+   if (!coresight_kdump_nodes)
+   return -EPROBE_DEFER;
+
+   spin_lock_irqsave(_kdump_lock, flags);
+
+   node = _kdump_nodes[cpu];
+   node->source_csdev = csdev;
+
+   csdev->kdump_buf = data;
+   csdev->kdump_buf_sz = data_sz;
+
+   spin_unlock_irqrestore(_kdump_lock, flags);
+   return 0;
+}
+
+/**
+ * coresight_kdump_sink - Set sink device handler for specific CPU
+ * @cpu:   CPU ID
+ * @csdev: Sink device structure handler
+ *
+ * This function is a helper function which is used to s

[PATCH v4 6/6] coresight: etm4x: Support panic kdump

2018-03-29 Thread Leo Yan
ETMv4 hardware information and configuration needs to be saved as
metadata; the metadata format should be compatible with 'perf' tool and
finally is used by tracing data decoder.  ETMv4 works as tracer per CPU,
we cannot wait for gathering ETM info after CPU panic has happened in
case there have CPU is locked up and can't response inter-processor
interrupt for execution dump operations; so it's more reliable to gather
tracer metadata when all of the CPUs are alive.

This patch saves ETMv4 metadata but with the different method for
different registers.  Since values in TRCIDR{0, 1, 2, 8} and
TRCAUTHSTATUS are read-only and won't change afterward, thus those
registers values are filled into metadata structure when tracers are
instantiated.  The configuration and control registers TRCCONFIGR and
TRCTRACEIDR are dynamically configured, their values are recorded during
tracer enabling phase.

To avoid unnecessary overload introduced by set/clear operations for
updating kdump node, we only set ETMv4 metadata info for the
corresponding kdump node at initialization and won't be cleared anymore.

Suggested-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm4x.c | 27 +++
 drivers/hwtracing/coresight/coresight-etm4x.h | 15 +++
 2 files changed, 42 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c 
b/drivers/hwtracing/coresight/coresight-etm4x.c
index cf364a5..88b1e19 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -288,6 +288,8 @@ static int etm4_enable(struct coresight_device *csdev,
int ret;
u32 val;
struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+   struct etmv4_config *config = >config;
+   struct etmv4_metadata *metadata = >metadata;
 
val = local_cmpxchg(>mode, CS_MODE_DISABLED, mode);
 
@@ -306,6 +308,10 @@ static int etm4_enable(struct coresight_device *csdev,
ret = -EINVAL;
}
 
+   /* Update tracer meta data after tracer configuration */
+   metadata->trcconfigr = config->cfg;
+   metadata->trctraceidr = drvdata->trcid;
+
/* The tracer didn't start */
if (ret)
local_set(>mode, CS_MODE_DISABLED);
@@ -438,6 +444,7 @@ static void etm4_init_arch_data(void *info)
u32 etmidr4;
u32 etmidr5;
struct etmv4_drvdata *drvdata = info;
+   struct etmv4_metadata *metadata = >metadata;
 
/* Make sure all registers are accessible */
etm4_os_unlock(drvdata);
@@ -590,6 +597,16 @@ static void etm4_init_arch_data(void *info)
drvdata->nrseqstate = BMVAL(etmidr5, 25, 27);
/* NUMCNTR, bits[30:28] number of counters available for tracing */
drvdata->nr_cntr = BMVAL(etmidr5, 28, 30);
+
+   /* Update metadata */
+   metadata->magic = ETM4_METADATA_MAGIC;
+   metadata->cpu = drvdata->cpu;
+   metadata->trcidr0 = readl_relaxed(drvdata->base + TRCIDR0);
+   metadata->trcidr1 = readl_relaxed(drvdata->base + TRCIDR1);
+   metadata->trcidr2 = readl_relaxed(drvdata->base + TRCIDR2);
+   metadata->trcidr8 = readl_relaxed(drvdata->base + TRCIDR8);
+   metadata->trcauthstatus = readl_relaxed(drvdata->base + TRCAUTHSTATUS);
+
CS_LOCK(drvdata->base);
 }
 
@@ -957,6 +974,7 @@ static int etm4_probe(struct amba_device *adev, const 
struct amba_id *id)
struct device *dev = >dev;
struct coresight_platform_data *pdata = NULL;
struct etmv4_drvdata *drvdata;
+   struct etmv4_metadata *metadata;
struct resource *res = >res;
struct coresight_desc desc = { 0 };
struct device_node *np = adev->dev.of_node;
@@ -1027,6 +1045,15 @@ static int etm4_probe(struct amba_device *adev, const 
struct amba_id *id)
goto err_arch_supported;
}
 
+   /* Set source device handler and metadata into kdump node */
+   metadata = >metadata;
+   ret = coresight_kdump_source(drvdata->cpu, drvdata->csdev,
+(char *)metadata, sizeof(*metadata));
+   if (ret) {
+   coresight_unregister(drvdata->csdev);
+   goto err_arch_supported;
+   }
+
ret = etm_perf_symlink(drvdata->csdev, true);
if (ret) {
coresight_unregister(drvdata->csdev);
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h 
b/drivers/hwtracing/coresight/coresight-etm4x.h
index b3b5ea7..08dc8b7 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -198,6 +198,20 @@
 #define ETM_EXLEVEL_NS_HYP BIT(14)
 #define ETM_EXLEVEL_NS_NA  BIT(15)
 
+#define ETM4_METADATA_MAGIC0x4040404040404

[PATCH v4 4/6] coresight: tmc: Hook callback for panic kdump

2018-03-29 Thread Leo Yan
Since Coresight panic kdump functionality has been ready, this patch is
to hook panic callback function for ETB/ETF driver.  The driver data
structure has allocated a buffer when the session started, so simply
save tracing data into this buffer when panic happens and update buffer
related info for kdump.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/coresight-tmc-etf.c | 30 +
 1 file changed, 30 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c 
b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index e2513b7..d20d546 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -504,6 +504,35 @@ static void tmc_update_etf_buffer(struct coresight_device 
*csdev,
CS_LOCK(drvdata->base);
 }
 
+static void tmc_panic_cb(void *data)
+{
+   struct coresight_device *csdev = (struct coresight_device *)data;
+   struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+   unsigned long flags;
+
+   if (WARN_ON_ONCE(drvdata->config_type != TMC_CONFIG_TYPE_ETB &&
+drvdata->config_type != TMC_CONFIG_TYPE_ETF))
+   return;
+
+   if (drvdata->mode == CS_MODE_DISABLED)
+   return;
+
+   spin_lock_irqsave(>spinlock, flags);
+
+   CS_UNLOCK(drvdata->base);
+
+   tmc_flush_and_stop(drvdata);
+   tmc_etb_dump_hw(drvdata);
+
+   CS_LOCK(drvdata->base);
+
+   /* Update buffer info for panic dump */
+   csdev->kdump_buf = drvdata->buf;
+   csdev->kdump_buf_sz = drvdata->len;
+
+   spin_unlock_irqrestore(>spinlock, flags);
+}
+
 static const struct coresight_ops_sink tmc_etf_sink_ops = {
.enable = tmc_enable_etf_sink,
.disable= tmc_disable_etf_sink,
@@ -512,6 +541,7 @@ static const struct coresight_ops_sink tmc_etf_sink_ops = {
.set_buffer = tmc_set_etf_buffer,
.reset_buffer   = tmc_reset_etf_buffer,
.update_buffer  = tmc_update_etf_buffer,
+   .panic_cb   = tmc_panic_cb,
 };
 
 static const struct coresight_ops_link tmc_etf_link_ops = {
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v4 0/6] Coresight: Support panic kdump

2018-03-29 Thread Leo Yan
This patch set is to explore Coresight tracing data for postmortem
debugging.  When kernel panic happens, the Coresight panic kdump can
help to save on-chip tracing data and tracer metadata into DRAM, later
relies on kdump and crash/perf tools to recovery tracing data for
"offline" analysis.

The documentation is important to understand the purpose of Coresight
panic kdump, the implementation of framework and usage. Patches 0001
and patch 0002 are used for creating new sub directory for placing
Coresight docs and add a new doc for Coresight panic kdump.

Patch 0003 introduces the simple panic kdump framework which provides
helper functions can be used by Coresight devices, and it registers
panic notifier for dump tracing data.

Patches 0004/0005 support panic kdump for ETB; Patch 0006 supports the
kdump for ETMv4.

This patch set has been reworked by following suggestions at Linaro
HKG18 connect (mainly suggestions from Mathieu, thanks a lot!), and
it's rebased on acme git tree [1] with last commit 109d59b900e7 ('perf
vendor events s390: Add JSON files for IBM z14').

Due Coresight kdump data structure has been changed significantly, the
corresponding crash extension program also has been updated for this
reason [2]; furthermore the crash extension program is updated to
dynamically generate kernel buildid according to vmlinux elf info [3],
this is a fixing for the old code which uses hard-coded buildid value.

This patch set has been verified on 96boards Hikey620 with Coresight
enabling by the sysFS interface.  Also the updated crash extension
program has been verified to cowork with Coresight panic kdump and it
successfully extracts tracing data from the vmcore and finally can be
decoded by perf tool.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
[2] https://git.linaro.org/people/leo.yan/crash.git/tree/extensions/csdump.c
[3] 
https://git.linaro.org/people/leo.yan/crash.git/tree/extensions/csdump_buildid.c

Changes from v3:
* Following Mathieu suggestion, reworked the panic kdump framework,
  used kdump array to maintain source and sink device handlers;
* According to Mathieu suggestion, optimized panic notifier to
  firstly dump panic CPU tracing data and then dump other CPUs tracing
  data;
* Refined doc to reflect these implementation changes;
* Changed ETMv4 driver to add source device handler at probe phase;
* Refactored crash extension program to reflect kernel changes.

Changes from v2:
* Add the two patches for documentation.
* Following Mathieu suggestion, reworked the panic kdump framework,
  removed the useless flag "PRE_PANIC".
* According to comment, changed to add and delete kdump node operations
  in sink enable/disable functions;
* According to Mathieu suggestion, handle kdump node
  addition/deletion/updating separately for sysFS interface and perf
  method.

Changes from v1:
* Add support to dump ETMv4 meta data.
* Wrote 'crash' extension csdump.so so rely on it to generate 'perf'
  format compatible file.
* Refactored panic dump driver to support pre & post panic dump.

Changes from RFC:
* Follow Mathieu's suggestion, use general framework to support dump
  functionality.
* Changed to use perf to analyse trace data.

Leo Yan (6):
  doc: Add Coresight documentation directory
  doc: Add documentation for Coresight panic kdump
  coresight: Support panic kdump functionality
  coresight: tmc: Hook callback for panic kdump
  coresight: Set and clear sink device handler for kdump node
  coresight: etm4x: Support panic kdump

 Documentation/trace/coresight-cpu-debug.txt| 187 --
 Documentation/trace/coresight.txt  | 383 -
 .../trace/coresight/coresight-cpu-debug.txt| 187 ++
 .../trace/coresight/coresight-panic-kdump.txt  | 130 +++
 Documentation/trace/coresight/coresight.txt| 383 +
 MAINTAINERS|   5 +-
 drivers/hwtracing/coresight/Kconfig|   9 +
 drivers/hwtracing/coresight/Makefile   |   1 +
 drivers/hwtracing/coresight/coresight-etm-perf.c   |   5 +
 drivers/hwtracing/coresight/coresight-etm4x.c  |  27 ++
 drivers/hwtracing/coresight/coresight-etm4x.h  |  15 +
 .../hwtracing/coresight/coresight-panic-kdump.c| 199 +++
 drivers/hwtracing/coresight/coresight-priv.h   |  12 +
 drivers/hwtracing/coresight/coresight-tmc-etf.c|  30 ++
 drivers/hwtracing/coresight/coresight.c|  16 +-
 include/linux/coresight.h  |   4 +
 16 files changed, 1019 insertions(+), 574 deletions(-)
 delete mode 100644 Documentation/trace/coresight-cpu-debug.txt
 delete mode 100644 Documentation/trace/coresight.txt
 create mode 100644 Documentation/trace/coresight/coresight-cpu-debug.txt
 create mode 100644 Documentation/trace/coresight/coresight-panic-kdump.txt
 create mode 100644 Documentation/trace/coresight/coresight.txt
 create mode 100644 dri

Re: [PATCH v3 6/6] coresight: etm4x: Support panic kdump

2018-01-09 Thread Leo Yan
On Tue, Jan 09, 2018 at 01:21:28PM -0700, Mathieu Poirier wrote:
> On Thu, Dec 21, 2017 at 04:20:15PM +0800, Leo Yan wrote:
> > ETMv4 hardware information and configuration needs to be saved as
> > metadata; these metadata should be compatible with tool 'perf' and
> > can be used for tracing data analysis.  ETMv4 usually works as tracer
> > per CPU, we cannot wait to gather ETM info after the CPU has been panic
> > and cannot execute dump operations for itself; so should gather
> > metadata when the corresponding CPU is alive.
> > 
> > Since values in TRCIDR{0, 1, 2, 8} and TRCAUTHSTATUS are read-only and
> > won't change at the runtime.  Those registers value are filled when
> > tracers are instantiated.
> > 
> > The configuration and control registers TRCCONFIGR and TRCTRACEIDR are
> > dynamically configured, we record their value when enabling coresight
> > path.  When operating from sysFS tracer these two registers are recorded
> > in etm4_enable_sysfs() and add kdump node into list, and remove the
> > kdump node in etm4_disable_sysfs().  When operating from perf,
> > etm_setup_aux() adds all tracers to the dump list and etm4_enable_perf()
> > is used to record configuration registers and update dump buffer info,
> > this can avoid unnecessary list addition and deletion operations.
> > Removal of the tracers from the dump list is done in function
> > free_event_data().
> > 
> > Suggested-by: Mathieu Poirier <mathieu.poir...@linaro.org>
> > Signed-off-by: Leo Yan <leo@linaro.org>
> > ---
> >  drivers/hwtracing/coresight/coresight-etm-perf.c | 12 +++-
> >  drivers/hwtracing/coresight/coresight-etm4x.c| 23 
> > +++
> >  drivers/hwtracing/coresight/coresight-etm4x.h| 15 +++
> >  3 files changed, 49 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c 
> > b/drivers/hwtracing/coresight/coresight-etm-perf.c
> > index 8a0ad77..fec779b 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> > @@ -137,6 +137,12 @@ static void free_event_data(struct work_struct *work)
> > }
> >  
> > for_each_cpu(cpu, mask) {
> > +   struct coresight_device *csdev;
> > +
> > +   csdev = per_cpu(csdev_src, cpu);
> > +   if (csdev)
> > +   coresight_kdump_del(csdev);
> > +
> > if (!(IS_ERR_OR_NULL(event_data->path[cpu])))
> > coresight_release_path(event_data->path[cpu]);
> > }
> > @@ -195,7 +201,7 @@ static void etm_free_aux(void *data)
> >  static void *etm_setup_aux(int event_cpu, void **pages,
> >int nr_pages, bool overwrite)
> >  {
> > -   int cpu;
> > +   int cpu, ret;
> > cpumask_t *mask;
> > struct coresight_device *sink;
> > struct etm_event_data *event_data = NULL;
> > @@ -238,6 +244,10 @@ static void *etm_setup_aux(int event_cpu, void **pages,
> > event_data->path[cpu] = coresight_build_path(csdev, sink);
> > if (IS_ERR(event_data->path[cpu]))
> > goto err;
> > +
> > +   ret = coresight_kdump_add(csdev, cpu);
> 
> Aren't you missing the configuration for trcconfigr and trctraceidr?

Ah, should update these two configurations in function
etm4_enable_perf()?

> > +   if (ret)
> > +   goto err;
> > }
> >  
> > if (!sink_ops(sink)->alloc_buffer)
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c 
> > b/drivers/hwtracing/coresight/coresight-etm4x.c
> > index cf364a5..cbde398 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> > @@ -258,10 +258,19 @@ static int etm4_enable_perf(struct coresight_device 
> > *csdev,
> >  static int etm4_enable_sysfs(struct coresight_device *csdev)
> >  {
> > struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
> > +   struct etmv4_config *config = >config;
> > +   struct etmv4_metadata *metadata = >metadata;
> > int ret;
> >  
> > spin_lock(>spinlock);
> >  
> > +   /* Update meta data and add into kdump list */
> > +   metadata->trcconfigr = config->cfg;
> > +   metadata->trctraceidr = drvdata->trcid;
> > +
> > +   coresight_kdump_add(csdev, drvdata->cpu);
> > +   coresight_kdump_update(csdev, (char *)metadata, sizeof(*m

Re: [PATCH v3 3/6] coresight: Support panic kdump functionality

2018-01-09 Thread Leo Yan
On Tue, Jan 09, 2018 at 11:41:26AM -0700, Mathieu Poirier wrote:
> On Thu, Dec 21, 2017 at 04:20:12PM +0800, Leo Yan wrote:
> > After kernel panic happens, coresight has many useful info can be used
> > for analysis.  For example, the trace info from ETB RAM can be used to
> > check the CPU execution flows before crash.  So we can save the tracing
> > data from sink devices, and rely on kdump to save DDR content and uses
> > "crash" tool to extract coresight dumping from vmcore file.
> > 
> > This patch is to add a simple framework to support panic dump
> > functionality; it registers panic notifier, and provide the general APIs
> > {coresight_kdump_add|coresight_kdump_del} as helper functions so any
> > coresight device can add itself into dump list or delete as needed.
> > 
> > This driver provides helper function coresight_kdump_update() to update
> > the dump buffer base address and buffer size.  This function can be used
> > by coresight driver, e.g. it can be used to save ETM meta data info at
> > runtime and these info can be prepared pre panic happening.
> > 
> > When kernel panic happens, the notifier iterates dump list and calls
> > callback function to dump device specific info.  The panic dump is
> > mainly used to dump trace data so we can get to know the execution flow
> > before the panic happens.
> > 
> > Signed-off-by: Leo Yan <leo@linaro.org>
> > ---
> >  drivers/hwtracing/coresight/Kconfig|   9 ++
> >  drivers/hwtracing/coresight/Makefile   |   1 +
> >  .../hwtracing/coresight/coresight-panic-kdump.c| 154 
> > +
> >  drivers/hwtracing/coresight/coresight-priv.h   |  13 ++
> >  include/linux/coresight.h  |   7 +
> >  5 files changed, 184 insertions(+)
> >  create mode 100644 drivers/hwtracing/coresight/coresight-panic-kdump.c
> > 
> > diff --git a/drivers/hwtracing/coresight/Kconfig 
> > b/drivers/hwtracing/coresight/Kconfig
> > index ef9cb3c..4812529 100644
> > --- a/drivers/hwtracing/coresight/Kconfig
> > +++ b/drivers/hwtracing/coresight/Kconfig
> > @@ -103,4 +103,13 @@ config CORESIGHT_CPU_DEBUG
> >   properly, please refer Documentation/trace/coresight-cpu-debug.txt
> >   for detailed description and the example for usage.
> >  
> > +config CORESIGHT_PANIC_KDUMP
> > +   bool "CoreSight Panic Kdump driver"
> > +   depends on ARM || ARM64
> 
> At this time only ETMv4 supports the feature, so it is only ARM64.

Thanks for reviewing, Mathieu.

Will change to only for ARM64.

> > +   help
> > + This driver provides panic kdump functionality for CoreSight
> > + devices.  When a kernel panic happen a device supplied callback 
> > function
> > + is used to save trace data to memory. From there we rely on kdump to 
> > extract
> > + the trace data from kernel dump file.
> > +
> >  endif
> > diff --git a/drivers/hwtracing/coresight/Makefile 
> > b/drivers/hwtracing/coresight/Makefile
> > index 61db9dd..946fe19 100644
> > --- a/drivers/hwtracing/coresight/Makefile
> > +++ b/drivers/hwtracing/coresight/Makefile
> > @@ -18,3 +18,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o 
> > \
> >  obj-$(CONFIG_CORESIGHT_DYNAMIC_REPLICATOR) += 
> > coresight-dynamic-replicator.o
> >  obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
> >  obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
> > +obj-$(CONFIG_CORESIGHT_PANIC_KDUMP) += coresight-panic-kdump.o
> > diff --git a/drivers/hwtracing/coresight/coresight-panic-kdump.c 
> > b/drivers/hwtracing/coresight/coresight-panic-kdump.c
> > new file mode 100644
> > index 000..c21d20b
> > --- /dev/null
> > +++ b/drivers/hwtracing/coresight/coresight-panic-kdump.c
> > @@ -0,0 +1,154 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (c) 2017 Linaro Limited.
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "coresight-priv.h"
> > +
> > +typedef void (*coresight_cb_t)(void *data);
> > +
> > +/**
> > + * struct coresight_kdump_node - Node information for dump
> > + * @cpu:   The cpu this node is affined to.
> > + * @csdev: Handler for coresight device.
> > + * @buf:   Pointer for dump buffer.
> > + * @buf_size:  Length of dump buffer.
> > + * @list:  Hook to the list.
> > + 

[PATCH v3 2/6] doc: Add documentation for Coresight panic kdump

2017-12-21 Thread Leo Yan
Add detailed documentation for Coresight panic kdump, which contains
the idea for why need this and introduce the framework implementation
and usage.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 .../trace/coresight/coresight-panic-kdump.txt  | 91 ++
 MAINTAINERS|  1 +
 2 files changed, 92 insertions(+)
 create mode 100644 Documentation/trace/coresight/coresight-panic-kdump.txt

diff --git a/Documentation/trace/coresight/coresight-panic-kdump.txt 
b/Documentation/trace/coresight/coresight-panic-kdump.txt
new file mode 100644
index 000..6bf9cac
--- /dev/null
+++ b/Documentation/trace/coresight/coresight-panic-kdump.txt
@@ -0,0 +1,91 @@
+   Coresight Panic Kdump
+   =
+
+   Author:   Leo Yan <leo@linaro.org>
+   Date: Dec 21th, 2017
+
+Introduction
+
+
+Coresight has different sinks for trace data, the trace data is quite useful
+for postmortem debugging.  Embedded Trace Buffer (ETB) is one type sink which
+provides on-chip storage of trace data, usually uses SRAM as buffer with
+several KBs size; if the SoC designs to support 'Local ETF' (ARM DDI 0461B,
+chapter 1.2.7), every CPU has one local ETB buffer so the per CPU trace data
+can avoid to be overwritted by other CPUs.  Trace Memory Controller (TMC) is
+another kind sink designed as a successor to the CoreSight ETB to capture trace
+into DRAM.
+
+After Linux kernel trigger panic, the trace data keeps the last execution flow
+before issues happen.  We could consider the trace data is quite useful for
+postmortem debugging, especially when we can record trace data into DRAM and 
rely
+on kdump to save them into vmcore file; at the end we can retrieve trace data
+from vmcore file and "offline" to analyze the execution flow.
+
+
+Implementation
+--
+
+Coresight panic kdump is a simple framework to support dump functionality,
+it maintains dump list with every node recording the dump buffer base address
+and buffer size.  Coresight panic kdump provides the general APIs
+{coresight_kdump_add|coresight_kdump_del} as helper functions so any coresight
+device can add itself into dump list or delete as needed.
+
+Generally coresight device set its 'panic_cb' in the ops structure, the panic
+notifier iterates dump list and invokes callback function to dump device 
specific
+info.
+
+For easily used by offline analysis, we also record tracer metadata so can
+retrieve tracer IDs and configuration, in this case the node records CPU 
number so
+can create connection between the metadata and specific CPU.  The tracer
+driver uses helper function coresight_kdump_update() to update the dump
+buffer base address and buffer size; so the tracer can save metadata at runtime
+and these info can be prepared well pre panic happening.
+
+
+Usage
+-
+
+Build Linux kernel with enabling 'CONFIG_CORESIGHT_PANIC_KDUMP' configuration.
+
+After system booting up, we need firstly prepare dump-capture kernel, this can
+refer doc [1] chapter 'Load the Dump-capture Kernel' for detailed steps.  Then
+we need enable the coresight tracer, this can use either perf framework method
+or sysFS interface, please refer doc [2] chapter 'How to use the tracer 
modules'
+for detailed steps.
+
+When kernel panic happens, the panic kdump records trace data and launches
+dump-capture kernel, we can utilize the dump-capture kernel to save kernel dump
+file, this can refer doc [1] chapter 'Write Out the Dump File'.
+
+After get kernel dump file, we can use 'crash' tool + csdump.so extension to
+extract trace data and generate 'perf.data' file:
+
+  ./crash vmcore vmlinux
+  crash> extend csdump.so
+  crash> csdump output_dir
+
+  We can see in the 'output_dir' there will generate out three files:
+  output_dir/
+  ├── cstrace.bin   -> trace raw data
+  ├── metadata.bin  -> meta data
+  └── perf.data -> 'perf' format compatible file
+
+Finally use 'perf' tool for offline analysis:
+
+  ./perf script -v -F cpu,event,ip,sym,symoff -i perf.data -k vmlinux 
--kallsyms /proc/kallsyms
+  [001] instructions:  08559ad0 pl011_console_write+0x90
+  [001] instructions:  08559230 pl011_read+0x0
+  [001] instructions:  0855924c pl011_read+0x1c
+  [001] instructions:  08559ae0 pl011_console_write+0xa0
+  [001] instructions:  08559ad0 pl011_console_write+0x90
+  [001] instructions:  08559230 pl011_read+0x0
+  [001] instructions:  0855924c pl011_read+0x1c
+  [001] instructions:  08559ae0 pl011_console_write+0xa0
+  [001] instructions:  08559ad0 pl011_console_write+0x90
+  [001] instructions:  08559230 pl011_read+0x0
+  [001] instructions:  0855924c pl011_read+0x1c
+
+[1] Documentation/kdump/kdump.txt
+[2] Documentation/trace/coresight/cor

[PATCH v3 3/6] coresight: Support panic kdump functionality

2017-12-21 Thread Leo Yan
After kernel panic happens, coresight has many useful info can be used
for analysis.  For example, the trace info from ETB RAM can be used to
check the CPU execution flows before crash.  So we can save the tracing
data from sink devices, and rely on kdump to save DDR content and uses
"crash" tool to extract coresight dumping from vmcore file.

This patch is to add a simple framework to support panic dump
functionality; it registers panic notifier, and provide the general APIs
{coresight_kdump_add|coresight_kdump_del} as helper functions so any
coresight device can add itself into dump list or delete as needed.

This driver provides helper function coresight_kdump_update() to update
the dump buffer base address and buffer size.  This function can be used
by coresight driver, e.g. it can be used to save ETM meta data info at
runtime and these info can be prepared pre panic happening.

When kernel panic happens, the notifier iterates dump list and calls
callback function to dump device specific info.  The panic dump is
mainly used to dump trace data so we can get to know the execution flow
before the panic happens.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/Kconfig|   9 ++
 drivers/hwtracing/coresight/Makefile   |   1 +
 .../hwtracing/coresight/coresight-panic-kdump.c| 154 +
 drivers/hwtracing/coresight/coresight-priv.h   |  13 ++
 include/linux/coresight.h  |   7 +
 5 files changed, 184 insertions(+)
 create mode 100644 drivers/hwtracing/coresight/coresight-panic-kdump.c

diff --git a/drivers/hwtracing/coresight/Kconfig 
b/drivers/hwtracing/coresight/Kconfig
index ef9cb3c..4812529 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -103,4 +103,13 @@ config CORESIGHT_CPU_DEBUG
  properly, please refer Documentation/trace/coresight-cpu-debug.txt
  for detailed description and the example for usage.
 
+config CORESIGHT_PANIC_KDUMP
+   bool "CoreSight Panic Kdump driver"
+   depends on ARM || ARM64
+   help
+ This driver provides panic kdump functionality for CoreSight
+ devices.  When a kernel panic happen a device supplied callback 
function
+ is used to save trace data to memory. From there we rely on kdump to 
extract
+ the trace data from kernel dump file.
+
 endif
diff --git a/drivers/hwtracing/coresight/Makefile 
b/drivers/hwtracing/coresight/Makefile
index 61db9dd..946fe19 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
 obj-$(CONFIG_CORESIGHT_DYNAMIC_REPLICATOR) += coresight-dynamic-replicator.o
 obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
 obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
+obj-$(CONFIG_CORESIGHT_PANIC_KDUMP) += coresight-panic-kdump.o
diff --git a/drivers/hwtracing/coresight/coresight-panic-kdump.c 
b/drivers/hwtracing/coresight/coresight-panic-kdump.c
new file mode 100644
index 000..c21d20b
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-panic-kdump.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017 Linaro Limited.
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "coresight-priv.h"
+
+typedef void (*coresight_cb_t)(void *data);
+
+/**
+ * struct coresight_kdump_node - Node information for dump
+ * @cpu:   The cpu this node is affined to.
+ * @csdev: Handler for coresight device.
+ * @buf:   Pointer for dump buffer.
+ * @buf_size:  Length of dump buffer.
+ * @list:  Hook to the list.
+ */
+struct coresight_kdump_node {
+   int cpu;
+   struct coresight_device *csdev;
+   char *buf;
+   unsigned int buf_size;
+   struct list_head list;
+};
+
+static DEFINE_SPINLOCK(coresight_kdump_lock);
+static LIST_HEAD(coresight_kdump_list);
+static struct notifier_block coresight_kdump_nb;
+
+int coresight_kdump_update(struct coresight_device *csdev, char *buf,
+  unsigned int buf_size)
+{
+   struct coresight_kdump_node *node = csdev->dump_node;
+
+   if (!node) {
+   dev_err(>dev, "Failed to update dump node.\n");
+   return -EINVAL;
+   }
+
+   node->buf = buf;
+   node->buf_size = buf_size;
+   return 0;
+}
+
+int coresight_kdump_add(struct coresight_device *csdev, int cpu)
+{
+   struct coresight_kdump_node *node;
+   unsigned long flags;
+
+   node = kzalloc(sizeof(*node), GFP_KERNEL);
+   if (!node)
+   return -ENOMEM;
+
+   csdev->dump_node = (void *)node;
+   node->cpu = cpu;
+   node->csdev = csdev;
+
+   spin_lock_irqsave(_kdump_lock, flags);
+   list_add_tail(>list, _kdump_list);
+   sp

[PATCH v3 4/6] coresight: tmc: Hook callback for panic kdump

2017-12-21 Thread Leo Yan
Since the panic kdump functionality has been ready, this patch is to
hook panic callback function for ETB/ETF.  Since the driver data
structure has allocated buffer when the session started, so simply save
ETB/ETF trace data into the buffer when panic happens and update
related info into dump node.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/coresight-tmc-etf.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c 
b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index e2513b7..f823464 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -504,6 +504,34 @@ static void tmc_update_etf_buffer(struct coresight_device 
*csdev,
CS_LOCK(drvdata->base);
 }
 
+static void tmc_panic_cb(void *data)
+{
+   struct coresight_device *csdev = (struct coresight_device *)data;
+   struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+   unsigned long flags;
+
+   if (WARN_ON_ONCE(drvdata->config_type != TMC_CONFIG_TYPE_ETB &&
+drvdata->config_type != TMC_CONFIG_TYPE_ETF))
+   return;
+
+   if (drvdata->mode == CS_MODE_DISABLED)
+   return;
+
+   spin_lock_irqsave(>spinlock, flags);
+
+   CS_UNLOCK(drvdata->base);
+
+   tmc_flush_and_stop(drvdata);
+   tmc_etb_dump_hw(drvdata);
+
+   CS_LOCK(drvdata->base);
+
+   /* Update buffer info for panic dump */
+   coresight_kdump_update(csdev, drvdata->buf, drvdata->len);
+
+   spin_unlock_irqrestore(>spinlock, flags);
+}
+
 static const struct coresight_ops_sink tmc_etf_sink_ops = {
.enable = tmc_enable_etf_sink,
.disable= tmc_disable_etf_sink,
@@ -512,6 +540,7 @@ static const struct coresight_ops_sink tmc_etf_sink_ops = {
.set_buffer = tmc_set_etf_buffer,
.reset_buffer   = tmc_reset_etf_buffer,
.update_buffer  = tmc_update_etf_buffer,
+   .panic_cb   = tmc_panic_cb,
 };
 
 static const struct coresight_ops_link tmc_etf_link_ops = {
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 6/6] coresight: etm4x: Support panic kdump

2017-12-21 Thread Leo Yan
ETMv4 hardware information and configuration needs to be saved as
metadata; these metadata should be compatible with tool 'perf' and
can be used for tracing data analysis.  ETMv4 usually works as tracer
per CPU, we cannot wait to gather ETM info after the CPU has been panic
and cannot execute dump operations for itself; so should gather
metadata when the corresponding CPU is alive.

Since values in TRCIDR{0, 1, 2, 8} and TRCAUTHSTATUS are read-only and
won't change at the runtime.  Those registers value are filled when
tracers are instantiated.

The configuration and control registers TRCCONFIGR and TRCTRACEIDR are
dynamically configured, we record their value when enabling coresight
path.  When operating from sysFS tracer these two registers are recorded
in etm4_enable_sysfs() and add kdump node into list, and remove the
kdump node in etm4_disable_sysfs().  When operating from perf,
etm_setup_aux() adds all tracers to the dump list and etm4_enable_perf()
is used to record configuration registers and update dump buffer info,
this can avoid unnecessary list addition and deletion operations.
Removal of the tracers from the dump list is done in function
free_event_data().

Suggested-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm-perf.c | 12 +++-
 drivers/hwtracing/coresight/coresight-etm4x.c| 23 +++
 drivers/hwtracing/coresight/coresight-etm4x.h| 15 +++
 3 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c 
b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 8a0ad77..fec779b 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -137,6 +137,12 @@ static void free_event_data(struct work_struct *work)
}
 
for_each_cpu(cpu, mask) {
+   struct coresight_device *csdev;
+
+   csdev = per_cpu(csdev_src, cpu);
+   if (csdev)
+   coresight_kdump_del(csdev);
+
if (!(IS_ERR_OR_NULL(event_data->path[cpu])))
coresight_release_path(event_data->path[cpu]);
}
@@ -195,7 +201,7 @@ static void etm_free_aux(void *data)
 static void *etm_setup_aux(int event_cpu, void **pages,
   int nr_pages, bool overwrite)
 {
-   int cpu;
+   int cpu, ret;
cpumask_t *mask;
struct coresight_device *sink;
struct etm_event_data *event_data = NULL;
@@ -238,6 +244,10 @@ static void *etm_setup_aux(int event_cpu, void **pages,
event_data->path[cpu] = coresight_build_path(csdev, sink);
if (IS_ERR(event_data->path[cpu]))
goto err;
+
+   ret = coresight_kdump_add(csdev, cpu);
+   if (ret)
+   goto err;
}
 
if (!sink_ops(sink)->alloc_buffer)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c 
b/drivers/hwtracing/coresight/coresight-etm4x.c
index cf364a5..cbde398 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -258,10 +258,19 @@ static int etm4_enable_perf(struct coresight_device 
*csdev,
 static int etm4_enable_sysfs(struct coresight_device *csdev)
 {
struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+   struct etmv4_config *config = >config;
+   struct etmv4_metadata *metadata = >metadata;
int ret;
 
spin_lock(>spinlock);
 
+   /* Update meta data and add into kdump list */
+   metadata->trcconfigr = config->cfg;
+   metadata->trctraceidr = drvdata->trcid;
+
+   coresight_kdump_add(csdev, drvdata->cpu);
+   coresight_kdump_update(csdev, (char *)metadata, sizeof(*metadata));
+
/*
 * Executing etm4_enable_hw on the cpu whose ETM is being enabled
 * ensures that register writes occur when cpu is powered.
@@ -384,6 +393,9 @@ static void etm4_disable_sysfs(struct coresight_device 
*csdev)
 */
smp_call_function_single(drvdata->cpu, etm4_disable_hw, drvdata, 1);
 
+   /* Delete from kdump list */
+   coresight_kdump_del(csdev);
+
spin_unlock(>spinlock);
cpus_read_unlock();
 
@@ -438,6 +450,7 @@ static void etm4_init_arch_data(void *info)
u32 etmidr4;
u32 etmidr5;
struct etmv4_drvdata *drvdata = info;
+   struct etmv4_metadata *metadata = >metadata;
 
/* Make sure all registers are accessible */
etm4_os_unlock(drvdata);
@@ -590,6 +603,16 @@ static void etm4_init_arch_data(void *info)
drvdata->nrseqstate = BMVAL(etmidr5, 25, 27);
/* NUMCNTR, bits[30:28] number of counters available for tracing */
drvdata->nr_cntr = BMVAL(etmidr5, 28, 30);
+
+   /* Update metadata */

[PATCH v3 5/6] coresight: Add and delete sink callback for panic kdump list

2017-12-21 Thread Leo Yan
If the sink device has panic kdump callback, this means the sink device
wants to save tracing data for panic happening.

This commit adds node into panic kdump list when the sink device is
enabled, and delete node when the sink device is disabled.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/coresight.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight.c 
b/drivers/hwtracing/coresight/coresight.c
index 389c4ba..56798b1 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -146,6 +146,14 @@ static int coresight_enable_sink(struct coresight_device 
*csdev, u32 mode)
if (ret)
return ret;
}
+
+   /* Add into panic kdump list */
+   if (sink_ops(csdev)->panic_cb) {
+   ret = coresight_kdump_add(csdev, 0);
+   if (ret)
+   return ret;
+   }
+
csdev->enable = true;
}
 
@@ -157,6 +165,10 @@ static int coresight_enable_sink(struct coresight_device 
*csdev, u32 mode)
 static void coresight_disable_sink(struct coresight_device *csdev)
 {
if (atomic_dec_return(csdev->refcnt) == 0) {
+   /* Delete from panic kdump list */
+   if (sink_ops(csdev)->panic_cb)
+   coresight_kdump_del(csdev);
+
if (sink_ops(csdev)->disable) {
sink_ops(csdev)->disable(csdev);
csdev->enable = false;
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 1/6] doc: Add Coresight documentation directory

2017-12-21 Thread Leo Yan
For easily management and friendly adding more Coresight related
documentations, this commit creates one dedicated directory:
Documentation/trace/coresight.  It moves Coresight related docs into
this new directory and updates MAINTAINERS file to reflect docs
movement.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 Documentation/trace/coresight-cpu-debug.txt| 187 
 Documentation/trace/coresight.txt  | 332 -
 .../trace/coresight/coresight-cpu-debug.txt| 187 
 Documentation/trace/coresight/coresight.txt| 332 +
 MAINTAINERS|   4 +-
 5 files changed, 521 insertions(+), 521 deletions(-)
 delete mode 100644 Documentation/trace/coresight-cpu-debug.txt
 delete mode 100644 Documentation/trace/coresight.txt
 create mode 100644 Documentation/trace/coresight/coresight-cpu-debug.txt
 create mode 100644 Documentation/trace/coresight/coresight.txt

diff --git a/Documentation/trace/coresight-cpu-debug.txt 
b/Documentation/trace/coresight-cpu-debug.txt
deleted file mode 100644
index 2b9b51c..000
--- a/Documentation/trace/coresight-cpu-debug.txt
+++ /dev/null
@@ -1,187 +0,0 @@
-   Coresight CPU Debug Module
-   ==
-
-   Author:   Leo Yan <leo@linaro.org>
-   Date: April 5th, 2017
-
-Introduction
-
-
-Coresight CPU debug module is defined in ARMv8-a architecture reference manual
-(ARM DDI 0487A.k) Chapter 'Part H: External debug', the CPU can integrate
-debug module and it is mainly used for two modes: self-hosted debug and
-external debug. Usually the external debug mode is well known as the external
-debugger connects with SoC from JTAG port; on the other hand the program can
-explore debugging method which rely on self-hosted debug mode, this document
-is to focus on this part.
-
-The debug module provides sample-based profiling extension, which can be used
-to sample CPU program counter, secure state and exception level, etc; usually
-every CPU has one dedicated debug module to be connected. Based on self-hosted
-debug mechanism, Linux kernel can access these related registers from mmio
-region when the kernel panic happens. The callback notifier for kernel panic
-will dump related registers for every CPU; finally this is good for assistant
-analysis for panic.
-
-
-Implementation
---
-
-- During driver registration, it uses EDDEVID and EDDEVID1 - two device ID
-  registers to decide if sample-based profiling is implemented or not. On some
-  platforms this hardware feature is fully or partially implemented; and if
-  this feature is not supported then registration will fail.
-
-- At the time this documentation was written, the debug driver mainly relies on
-  information gathered by the kernel panic callback notifier from three
-  sampling registers: EDPCSR, EDVIDSR and EDCIDSR: from EDPCSR we can get
-  program counter; EDVIDSR has information for secure state, exception level,
-  bit width, etc; EDCIDSR is context ID value which contains the sampled value
-  of CONTEXTIDR_EL1.
-
-- The driver supports a CPU running in either AArch64 or AArch32 mode. The
-  registers naming convention is a bit different between them, AArch64 uses
-  'ED' for register prefix (ARM DDI 0487A.k, chapter H9.1) and AArch32 uses
-  'DBG' as prefix (ARM DDI 0487A.k, chapter G5.1). The driver is unified to
-  use AArch64 naming convention.
-
-- ARMv8-a (ARM DDI 0487A.k) and ARMv7-a (ARM DDI 0406C.b) have different
-  register bits definition. So the driver consolidates two difference:
-
-  If PCSROffset=0b, on ARMv8-a the feature of EDPCSR is not implemented;
-  but ARMv7-a defines "PCSR samples are offset by a value that depends on the
-  instruction set state". For ARMv7-a, the driver checks furthermore if CPU
-  runs with ARM or thumb instruction set and calibrate PCSR value, the
-  detailed description for offset is in ARMv7-a ARM (ARM DDI 0406C.b) chapter
-  C11.11.34 "DBGPCSR, Program Counter Sampling Register".
-
-  If PCSROffset=0b0010, ARMv8-a defines "EDPCSR implemented, and samples have
-  no offset applied and do not sample the instruction set state in AArch32
-  state". So on ARMv8 if EDDEVID1.PCSROffset is 0b0010 and the CPU operates
-  in AArch32 state, EDPCSR is not sampled; when the CPU operates in AArch64
-  state EDPCSR is sampled and no offset are applied.
-
-
-Clock and power domain
---
-
-Before accessing debug registers, we should ensure the clock and power domain
-have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1
-Debug registers', the debug registers are spread into two domains: the debug
-domain and the CPU domain.
-
-+---+
-|   |
-|   |
- +

[PATCH v3 0/6] Coresight: support panic kdump

2017-12-21 Thread Leo Yan
This patch set is to explore Coresight trace data for postmortem
debugging.  When kernel panic happens, the Coresight panic kdump can
help save on-chip trace data and tracer metadata into DRAM, later
relies on kdump and crash/perf for "offline" analysis.

The documentation is important to understand the purpose of Coresight
panic kdump, the implementation and usage. Patches 0001/0002 are used
to relocate and add related documenation.

Patch 0003 introduces the simple panic kdump framework which can be
easily used by Coresight devices.

Patches 0004/0005 support panic kdump for ETB; Patch 0006 supports
the dump for ETMv4. As Mathieu suggested, patch 0006 distinguish two
different tracer enabling mode: sysFS interface and perf mode.

This patch set have been verified on 96boards Hikey with tracer
enabling by sysFS interface.

Changes from v2:
* Add the two patches for documentation.
* Following Mathieu suggestion, reworked the panic kdump framework,
  removed the useless flag "PRE_PANIC".
* According to comment, changed to add and delete kdump node operations
  in sink enable/disable functions;
* According to Mathieu suggestion, handle kdump node
  addition/deletion/updating separately for sysFS interface and perf
  method.

Changes from v1:
* Add support to dump ETMv4 meta data.
* Wrote 'crash' extension csdump.so so rely on it to generate 'perf'
  format compatible file.
* Refactored panic dump driver to support pre & post panic dump.

Changes from RFC:
* Follow Mathieu's suggestion, use general framework to support dump
  functionality.
* Changed to use perf to analyse trace data.


Leo Yan (6):
  doc: Add Coresight documentation directory
  doc: Add documentation for Coresight panic kdump
  coresight: Support panic kdump functionality
  coresight: tmc: Hook callback for panic kdump
  coresight: Add and delete sink callback for panic kdump list
  coresight: etm4x: Support panic kdump

 Documentation/trace/coresight-cpu-debug.txt| 187 
 Documentation/trace/coresight.txt  | 332 -
 .../trace/coresight/coresight-cpu-debug.txt| 187 
 .../trace/coresight/coresight-panic-kdump.txt  |  91 ++
 Documentation/trace/coresight/coresight.txt| 332 +
 MAINTAINERS|   5 +-
 drivers/hwtracing/coresight/Kconfig|   9 +
 drivers/hwtracing/coresight/Makefile   |   1 +
 drivers/hwtracing/coresight/coresight-etm-perf.c   |  12 +-
 drivers/hwtracing/coresight/coresight-etm4x.c  |  23 ++
 drivers/hwtracing/coresight/coresight-etm4x.h  |  15 +
 .../hwtracing/coresight/coresight-panic-kdump.c| 154 ++
 drivers/hwtracing/coresight/coresight-priv.h   |  13 +
 drivers/hwtracing/coresight/coresight-tmc-etf.c|  29 ++
 drivers/hwtracing/coresight/coresight.c|  12 +
 include/linux/coresight.h  |   7 +
 16 files changed, 887 insertions(+), 522 deletions(-)
 delete mode 100644 Documentation/trace/coresight-cpu-debug.txt
 delete mode 100644 Documentation/trace/coresight.txt
 create mode 100644 Documentation/trace/coresight/coresight-cpu-debug.txt
 create mode 100644 Documentation/trace/coresight/coresight-panic-kdump.txt
 create mode 100644 Documentation/trace/coresight/coresight.txt
 create mode 100644 drivers/hwtracing/coresight/coresight-panic-kdump.c

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3] doc: coresight: correct usage for disabling idle states

2017-10-04 Thread Leo Yan
On Mon, Oct 02, 2017 at 11:14:46AM -0700, Mathieu Poirier wrote:
> On 19 September 2017 at 21:46, Leo Yan <leo@linaro.org> wrote:
> > In the coresight CPU debug document it suggests to use 'echo' command
> > to set latency request to /dev/cpu_dma_latency so can disable all CPU
> > idle states, but in fact this doesn't work.
> >
> > This is because when the command 'echo' exits, it releases the device
> > node's file descriptor and the kernel release function removes the QoS
> > constraint; finally when the command 'echo' finished there have no
> > constraint imposed on cpu_dma_latency.
> >
> > This patch changes to use 'exec' to access '/dev/cpu_dma_latency', the
> > command 'exec' can avoid the file descriptor to be closed so we can
> > keep the constraint on cpu_dma_latency.
> >
> > This patch also adds the info for reference docs for PM QoS and cpuidle
> > sysfs.
> >
> > Cc: Jonathan Corbet <cor...@lwn.net>
> > Cc: Sudeep Holla <sudeep.ho...@arm.com>
> > Reported-by: Kim Phillips <kim.phill...@arm.com>
> > Suggested-by: Mathieu Poirier <mathieu.poir...@linaro.org>
> > Signed-off-by: Leo Yan <leo@linaro.org>
> > ---
> >  Documentation/trace/coresight-cpu-debug.txt | 22 +-
> >  1 file changed, 17 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/trace/coresight-cpu-debug.txt 
> > b/Documentation/trace/coresight-cpu-debug.txt
> > index b3da1f9..2b9b51c 100644
> > --- a/Documentation/trace/coresight-cpu-debug.txt
> > +++ b/Documentation/trace/coresight-cpu-debug.txt
> > @@ -149,11 +149,23 @@ If you want to limit idle states at boot time, you 
> > can use "nohlt" or
> >
> >  At the runtime you can disable idle states with below methods:
> >
> > -Set latency request to /dev/cpu_dma_latency to disable all CPUs specific 
> > idle
> > -states (if latency = 0uS then disable all idle states):
> > -# echo "what_ever_latency_you_need_in_uS" > /dev/cpu_dma_latency
> > -
> > -Disable specific CPU's specific idle state:
> > +It is possible to disable CPU idle states by way of the PM QoS
> > +subsystem, more specifically by using the "/dev/cpu_dma_latency"
> > +interface (see Documentation/power/pm_qos_interface.txt for more
> > +details).  As specified in the PM QoS documentation the requested
> > +parameter will stay in effect until the file descriptor is released.
> > +For example:
> > +
> > +# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
> > +...
> > +Do some work...
> > +...
> > +# exec 3<>-
> > +
> > +The same can also be done from an application program.
> > +
> > +Disable specific CPU's specific idle state from cpuidle sysfs (see
> > +Documentation/cpuidle/sysfs.txt):
> >  # echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
> >
> 
> Applied.

Thanks a lot, Mathieu.

> Thanks,
> Mathieu
> 
> >
> > --
> > 2.7.4
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3] doc: coresight: correct usage for disabling idle states

2017-09-19 Thread Leo Yan
In the coresight CPU debug document it suggests to use 'echo' command
to set latency request to /dev/cpu_dma_latency so can disable all CPU
idle states, but in fact this doesn't work.

This is because when the command 'echo' exits, it releases the device
node's file descriptor and the kernel release function removes the QoS
constraint; finally when the command 'echo' finished there have no
constraint imposed on cpu_dma_latency.

This patch changes to use 'exec' to access '/dev/cpu_dma_latency', the
command 'exec' can avoid the file descriptor to be closed so we can
keep the constraint on cpu_dma_latency.

This patch also adds the info for reference docs for PM QoS and cpuidle
sysfs.

Cc: Jonathan Corbet <cor...@lwn.net>
Cc: Sudeep Holla <sudeep.ho...@arm.com>
Reported-by: Kim Phillips <kim.phill...@arm.com>
Suggested-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 Documentation/trace/coresight-cpu-debug.txt | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/Documentation/trace/coresight-cpu-debug.txt 
b/Documentation/trace/coresight-cpu-debug.txt
index b3da1f9..2b9b51c 100644
--- a/Documentation/trace/coresight-cpu-debug.txt
+++ b/Documentation/trace/coresight-cpu-debug.txt
@@ -149,11 +149,23 @@ If you want to limit idle states at boot time, you can 
use "nohlt" or
 
 At the runtime you can disable idle states with below methods:
 
-Set latency request to /dev/cpu_dma_latency to disable all CPUs specific idle
-states (if latency = 0uS then disable all idle states):
-# echo "what_ever_latency_you_need_in_uS" > /dev/cpu_dma_latency
-
-Disable specific CPU's specific idle state:
+It is possible to disable CPU idle states by way of the PM QoS
+subsystem, more specifically by using the "/dev/cpu_dma_latency"
+interface (see Documentation/power/pm_qos_interface.txt for more
+details).  As specified in the PM QoS documentation the requested
+parameter will stay in effect until the file descriptor is released.
+For example:
+
+# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
+...
+Do some work...
+...
+# exec 3<>-
+
+The same can also be done from an application program.
+
+Disable specific CPU's specific idle state from cpuidle sysfs (see
+Documentation/cpuidle/sysfs.txt):
 # echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
 
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2] doc: coresight: correct usage for disabling idle states

2017-09-19 Thread Leo Yan
On Tue, Sep 19, 2017 at 03:32:54PM -0600, Mathieu Poirier wrote:
> On 15 September 2017 at 04:16, Leo Yan <leo@linaro.org> wrote:
> > In the coresight CPU debug document it suggests to use 'echo' command
> > to set latency request to /dev/cpu_dma_latency so can disable all CPU
> > idle states, but in fact this doesn't work.
> >
> > This is because when the command 'echo' exits, it releases the device
> > node's file descriptor and the kernel release function removes the QoS
> > constraint; finally when the command 'echo' finished there have no
> > constraint imposed on cpu_dma_latency.
> >
> > This patch changes to use 'exec' to access '/dev/cpu_dma_latency', the
> > command 'exec' can avoid the file descriptor to be closed so we can
> > keep the constraint on cpu_dma_latency.
> >
> > This patch also adds the info for reference docs for PM QoS and cpuidle
> > sysfs.
> >
> > Cc: Jonathan Corbet <cor...@lwn.net>
> > Cc: Mathieu Poirier <mathieu.poir...@linaro.org>
> > Cc: Sudeep Holla <sudeep.ho...@arm.com>
> > Reported-by: Kim Phillips <kim.phill...@arm.com>
> > Signed-off-by: Leo Yan <leo@linaro.org>
> > ---
> >  Documentation/trace/coresight-cpu-debug.txt | 14 +-
> >  1 file changed, 9 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/trace/coresight-cpu-debug.txt 
> > b/Documentation/trace/coresight-cpu-debug.txt
> > index b3da1f9..205ff95 100644
> > --- a/Documentation/trace/coresight-cpu-debug.txt
> > +++ b/Documentation/trace/coresight-cpu-debug.txt
> > @@ -149,11 +149,15 @@ If you want to limit idle states at boot time, you 
> > can use "nohlt" or
> >
> >  At the runtime you can disable idle states with below methods:
> >
> > -Set latency request to /dev/cpu_dma_latency to disable all CPUs specific 
> > idle
> > -states (if latency = 0uS then disable all idle states):
> > -# echo "what_ever_latency_you_need_in_uS" > /dev/cpu_dma_latency
> > -
> > -Disable specific CPU's specific idle state:
> > +By using PM QoS interface '/dev/cpu_dma_latency', we can set latency
> > +constraint to disable all CPUs specific idle states (see
> > +Documentation/power/pm_qos_interface.txt, section 'From user mode');
> > +below is one example to set latency constraint to '', it is
> > +hexadecimal format with microsecond unit:
> > +# exec 3<> /dev/cpu_dma_latency; echo '' >&3
> 
> Since doing echo '' >&3 or simply echo 0 >&3 yields the same
> result I would go for the latter.  I also think it is important to
> specify that using an "echo" command without holding the file open
> won't give the desired result.  I would reformat your paragraph as
> follow:
> 
> >>> Begin >>>
> 
> It is possible to disable CPU idle states by way of the PM QoS
> subsystem, more specifically by using the "/dev/cpu_dma_latency"
> interface (see Documentation/power/pm_qos_interface.txt for more
> details).  As specified in the PM QoS documentation the requested
> parameter will stay in effect until the file descriptor is released.
> For example:
> 
> # exec 3<> /dev/cpu_dma_latency; echo 0 >&3
> ...
> Do some work...
> ...
> # exec 3<>-
> 
> The same can also be done from an application program.
> 
> <<< End <<<

Very appreciate your rephasing and reviewing. Will spin a new patch
with it.

Thanks,
Leo Yan

> > +
> > +Disable specific CPU's specific idle state from cpuidle sysfs (see
> > +Documentation/cpuidle/sysfs.txt):
> >  # echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
> >
> >
> > --
> > 2.7.4
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2] doc: coresight: correct usage for disabling idle states

2017-09-15 Thread Leo Yan
In the coresight CPU debug document it suggests to use 'echo' command
to set latency request to /dev/cpu_dma_latency so can disable all CPU
idle states, but in fact this doesn't work.

This is because when the command 'echo' exits, it releases the device
node's file descriptor and the kernel release function removes the QoS
constraint; finally when the command 'echo' finished there have no
constraint imposed on cpu_dma_latency.

This patch changes to use 'exec' to access '/dev/cpu_dma_latency', the
command 'exec' can avoid the file descriptor to be closed so we can
keep the constraint on cpu_dma_latency.

This patch also adds the info for reference docs for PM QoS and cpuidle
sysfs.

Cc: Jonathan Corbet <cor...@lwn.net>
Cc: Mathieu Poirier <mathieu.poir...@linaro.org>
Cc: Sudeep Holla <sudeep.ho...@arm.com>
Reported-by: Kim Phillips <kim.phill...@arm.com>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 Documentation/trace/coresight-cpu-debug.txt | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/Documentation/trace/coresight-cpu-debug.txt 
b/Documentation/trace/coresight-cpu-debug.txt
index b3da1f9..205ff95 100644
--- a/Documentation/trace/coresight-cpu-debug.txt
+++ b/Documentation/trace/coresight-cpu-debug.txt
@@ -149,11 +149,15 @@ If you want to limit idle states at boot time, you can 
use "nohlt" or
 
 At the runtime you can disable idle states with below methods:
 
-Set latency request to /dev/cpu_dma_latency to disable all CPUs specific idle
-states (if latency = 0uS then disable all idle states):
-# echo "what_ever_latency_you_need_in_uS" > /dev/cpu_dma_latency
-
-Disable specific CPU's specific idle state:
+By using PM QoS interface '/dev/cpu_dma_latency', we can set latency
+constraint to disable all CPUs specific idle states (see
+Documentation/power/pm_qos_interface.txt, section 'From user mode');
+below is one example to set latency constraint to '', it is
+hexadecimal format with microsecond unit:
+# exec 3<> /dev/cpu_dma_latency; echo '' >&3
+
+Disable specific CPU's specific idle state from cpuidle sysfs (see
+Documentation/cpuidle/sysfs.txt):
 # echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
 
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] doc: coresight: correct usage for '/dev/cpu_dma_latency'

2017-08-23 Thread Leo Yan
Hi Sudeep,

On Wed, Aug 23, 2017 at 10:17:06AM +0100, Sudeep Holla wrote:
> 
> On 23/08/17 08:23, Leo Yan wrote:
> > In the coresight CPU debug document it suggests to use 'echo' command
> > to set latency request to /dev/cpu_dma_latency so can disable all CPU
> > idle states, but in fact this doesn't work.
> > 
> > This is because when the command 'echo' exits, it releases the device
> > node's file descriptor and the kernel release function removes the QoS
> > constraint; finally when the command 'echo' finished there have no
> > constraint imposed on cpu_dma_latency.
> > 
> > This patch changes to use 'exec' to access '/dev/cpu_dma_latency', the
> > command 'exec' can avoid the file descriptor to be closed so we can
> > keep the constraint on cpu_dma_latency.
> > 
> > This patch also corrects the description when set latency = 0uS, in
> > this case the idle state0 still can be selected by CPUIdle governor so
> > this means on ARM platform the 'WFI' state is still enabled, but all
> > other deeper states have been disabled so CPUs will not be powered off.
> > 
> 
> 
> IMO, we should just refer to cpuidle and PM QoS documents from here so
> that any updates or changes in those documents are observed. Having a
> copy of the text may result in it getting obsolete.

Agree, we should point to below docs:
Documentation/power/pm_qos_interface.txt, section 'From user mode';
Documentation/cpuidle/sysfs.txt;

Thanks for good suggestion.

> -- 
> Regards,
> Sudeep
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] doc: coresight: correct usage for '/dev/cpu_dma_latency'

2017-08-23 Thread Leo Yan
In the coresight CPU debug document it suggests to use 'echo' command
to set latency request to /dev/cpu_dma_latency so can disable all CPU
idle states, but in fact this doesn't work.

This is because when the command 'echo' exits, it releases the device
node's file descriptor and the kernel release function removes the QoS
constraint; finally when the command 'echo' finished there have no
constraint imposed on cpu_dma_latency.

This patch changes to use 'exec' to access '/dev/cpu_dma_latency', the
command 'exec' can avoid the file descriptor to be closed so we can
keep the constraint on cpu_dma_latency.

This patch also corrects the description when set latency = 0uS, in
this case the idle state0 still can be selected by CPUIdle governor so
this means on ARM platform the 'WFI' state is still enabled, but all
other deeper states have been disabled so CPUs will not be powered off.

Cc: Kim Phillips <kim.phill...@arm.com>
Reported-by: Kim Phillips <kim.phill...@arm.com>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 Documentation/trace/coresight-cpu-debug.txt | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/trace/coresight-cpu-debug.txt 
b/Documentation/trace/coresight-cpu-debug.txt
index b3da1f9..17ff8ed 100644
--- a/Documentation/trace/coresight-cpu-debug.txt
+++ b/Documentation/trace/coresight-cpu-debug.txt
@@ -150,8 +150,10 @@ If you want to limit idle states at boot time, you can use 
"nohlt" or
 At the runtime you can disable idle states with below methods:
 
 Set latency request to /dev/cpu_dma_latency to disable all CPUs specific idle
-states (if latency = 0uS then disable all idle states):
-# echo "what_ever_latency_you_need_in_uS" > /dev/cpu_dma_latency
+states (if latency = 0uS then CPU Idle governor selects idle state0, so this
+means 'WFI' is still enabled but other deeper states have be disabled, this
+can avoid power off CPUs):
+# exec 3<> /dev/cpu_dma_latency; echo "what_ever_latency_you_need_in_uS" >&3
 
 Disable specific CPU's specific idle state:
 # echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v13 9/9] arm64: dts: qcom: msm8916: Add debug unit

2017-05-30 Thread Leo Yan
Hi Andy, David,

[ + Nico ]

On Fri, May 26, 2017 at 12:04:13AM +0800, Leo Yan wrote:
> Add debug unit on Qualcomm msm8916 based platforms, including the
> DragonBoard 410c board.

Could you take a look for this patch? After get your ACK I think
Mathieu could help pick up this patch through coresight repository.

If you want me to send a separate patch to you directly, also is okay.
Please let me know which is your preferring.

Thanks,
Leo Yan

> Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
> Signed-off-by: Leo Yan <leo@linaro.org>
> ---
>  arch/arm64/boot/dts/qcom/msm8916.dtsi | 32 
>  1 file changed, 32 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
> b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index ab30939..17691ab 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -1116,6 +1116,38 @@
>   };
>   };
>  
> + debug@85 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0x85 0x1000>;
> + clocks = < RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <>;
> + };
> +
> + debug@852000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0x852000 0x1000>;
> + clocks = < RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <>;
> + };
> +
> + debug@854000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0x854000 0x1000>;
> + clocks = < RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <>;
> + };
> +
> + debug@856000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0x856000 0x1000>;
> + clocks = < RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <>;
> + };
> +
>   etm@85c000 {
>   compatible = "arm,coresight-etm4x", "arm,primecell";
>   reg = <0x85c000 0x1000>;
> -- 
> 2.7.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v13 8/9] arm64: dts: hi6220: register debug module

2017-05-30 Thread Leo Yan
Hi Wei,

On Thu, May 25, 2017 at 11:57:15PM +0800, Leo Yan wrote:
> Bind debug module driver for Hi6220.

Could you ACK this patch? From Mathieu's previous suggestion, after
your confirmation he could pick up this patch.

If you want me to send a separate patch to you directly, also is okay.
Please let me know which is preferring.

Thanks,
Leo Yan

> Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
> Signed-off-by: Leo Yan <leo@linaro.org>
> ---
>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 64 
> +++
>  1 file changed, 64 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 1e5129b..21805b9 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -916,5 +916,69 @@
>   };
>   };
>   };
> +
> + debug@f659 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf659 0 0x1000>;
> + clocks = <_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <>;
> + };
> +
> + debug@f6592000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf6592000 0 0x1000>;
> + clocks = <_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <>;
> + };
> +
> + debug@f6594000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf6594000 0 0x1000>;
> + clocks = <_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <>;
> + };
> +
> + debug@f6596000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf6596000 0 0x1000>;
> + clocks = <_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <>;
> + };
> +
> + debug@f65d {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf65d 0 0x1000>;
> + clocks = <_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <>;
> + };
> +
> + debug@f65d2000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf65d2000 0 0x1000>;
> + clocks = <_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <>;
> + };
> +
> + debug@f65d4000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf65d4000 0 0x1000>;
> + clocks = <_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <>;
> + };
> +
> + debug@f65d6000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf65d6000 0 0x1000>;
> + clocks = <_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <>;
> + };
>   };
>  };
> -- 
> 2.7.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v13 0/9] coresight: enable debug module

2017-05-30 Thread Leo Yan
On Mon, May 29, 2017 at 10:41:17AM -0600, Mathieu Poirier wrote:
> On 25 May 2017 at 09:57, Leo Yan <leo@linaro.org> wrote:
> > ARMv8 architecture reference manual (ARM DDI 0487A.k) Chapter H7 "The
> > Sample-based Profiling Extension" has description for sampling
> > registers, we can utilize these registers to check program counter
> > value with combined CPU exception level, secure state, etc. So this is
> > helpful for CPU lockup bugs, e.g. if one CPU has run into infinite loop
> > with IRQ disabled; the 'hang' CPU cannot switch context and handle any
> > interrupt, so it cannot handle SMP call for stack dump, etc.
> >
> > This patch series is to enable coresight debug module with sample-based
> > registers and register call back notifier for PCSR register dumping
> > when panic happens, so we can see below dumping info for panic; and
> > this patch series has considered the conditions for access permission
> > for debug registers self, so this can avoid access debug registers when
> > CPU power domain is off; the driver also try to figure out the CPU is
> > in secure or non-secure state.
> 
> I have queued patches 1 to 7 to my tree.  I can't do anything about
> patches 8 and 9 because they haven't been ack'ed.  From here you can
> either chase them to get an ACK or send a separate patch to them
> directly.

Thanks a lot, Mathieu. I will ping Wei and Andy/David saperately.

> Thanks,
> Mathieu
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v13 9/9] arm64: dts: qcom: msm8916: Add debug unit

2017-05-25 Thread Leo Yan
Add debug unit on Qualcomm msm8916 based platforms, including the
DragonBoard 410c board.

Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index ab30939..17691ab 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -1116,6 +1116,38 @@
};
};
 
+   debug@85 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x85 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@852000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x852000 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@854000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x854000 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@856000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x856000 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
etm@85c000 {
compatible = "arm,coresight-etm4x", "arm,primecell";
reg = <0x85c000 0x1000>;
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v13 1/9] coresight: bindings for CPU debug module

2017-05-25 Thread Leo Yan
According to ARMv8 architecture reference manual (ARM DDI 0487A.k)
Chapter 'Part H: External debug', the CPU can integrate debug module
and it can support self-hosted debug and external debug. Especially
for supporting self-hosted debug, this means the program can access
the debug module from mmio region; and usually the mmio region is
integrated with coresight.

So add document for binding debug component, includes binding to APB
clock; and also need specify the CPU node which the debug module is
dedicated to specific CPU.

Suggested-by: Mike Leach <mike.le...@linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Acked-by: Rob Herring <r...@kernel.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 .../bindings/arm/coresight-cpu-debug.txt   | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt

diff --git a/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt 
b/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
new file mode 100644
index 000..2982912
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
@@ -0,0 +1,49 @@
+* CoreSight CPU Debug Component:
+
+CoreSight CPU debug component are compliant with the ARMv8 architecture
+reference manual (ARM DDI 0487A.k) Chapter 'Part H: External debug'. The
+external debug module is mainly used for two modes: self-hosted debug and
+external debug, and it can be accessed from mmio region from Coresight
+and eventually the debug module connects with CPU for debugging. And the
+debug module provides sample-based profiling extension, which can be used
+to sample CPU program counter, secure state and exception level, etc;
+usually every CPU has one dedicated debug module to be connected.
+
+Required properties:
+
+- compatible : should be "arm,coresight-cpu-debug"; supplemented with
+   "arm,primecell" since this driver is using the AMBA bus
+  interface.
+
+- reg : physical base address and length of the register set.
+
+- clocks : the clock associated to this component.
+
+- clock-names : the name of the clock referenced by the code. Since we are
+using the AMBA framework, the name of the clock providing
+   the interconnect should be "apb_pclk" and the clock is
+   mandatory. The interface between the debug logic and the
+   processor core is clocked by the internal CPU clock, so it
+   is enabled with CPU clock by default.
+
+- cpu : the CPU phandle the debug module is affined to. When omitted
+   the module is considered to belong to CPU0.
+
+Optional properties:
+
+- power-domains: a phandle to the debug power domain. We use "power-domains"
+ binding to turn on the debug logic if it has own dedicated
+power domain and if necessary to use "cpuidle.off=1" or
+"nohlt" in the kernel command line or sysfs node to
+constrain idle states to ensure registers in the CPU power
+domain are accessible.
+
+Example:
+
+   debug@f659 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf659 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v13 2/9] doc: Add documentation for Coresight CPU debug

2017-05-25 Thread Leo Yan
Add detailed documentation for Coresight CPU debug driver, which
contains the info for driver implementation, Mike Leach excellent
summary for "clock and power domain". At the end some examples on how
to enable the debugging functionality are provided.

Suggested-by: Mike Leach <mike.le...@linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 Documentation/trace/coresight-cpu-debug.txt | 175 
 1 file changed, 175 insertions(+)
 create mode 100644 Documentation/trace/coresight-cpu-debug.txt

diff --git a/Documentation/trace/coresight-cpu-debug.txt 
b/Documentation/trace/coresight-cpu-debug.txt
new file mode 100644
index 000..b3da1f9
--- /dev/null
+++ b/Documentation/trace/coresight-cpu-debug.txt
@@ -0,0 +1,175 @@
+   Coresight CPU Debug Module
+   ==========
+
+   Author:   Leo Yan <leo@linaro.org>
+   Date: April 5th, 2017
+
+Introduction
+
+
+Coresight CPU debug module is defined in ARMv8-a architecture reference manual
+(ARM DDI 0487A.k) Chapter 'Part H: External debug', the CPU can integrate
+debug module and it is mainly used for two modes: self-hosted debug and
+external debug. Usually the external debug mode is well known as the external
+debugger connects with SoC from JTAG port; on the other hand the program can
+explore debugging method which rely on self-hosted debug mode, this document
+is to focus on this part.
+
+The debug module provides sample-based profiling extension, which can be used
+to sample CPU program counter, secure state and exception level, etc; usually
+every CPU has one dedicated debug module to be connected. Based on self-hosted
+debug mechanism, Linux kernel can access these related registers from mmio
+region when the kernel panic happens. The callback notifier for kernel panic
+will dump related registers for every CPU; finally this is good for assistant
+analysis for panic.
+
+
+Implementation
+--
+
+- During driver registration, it uses EDDEVID and EDDEVID1 - two device ID
+  registers to decide if sample-based profiling is implemented or not. On some
+  platforms this hardware feature is fully or partially implemented; and if
+  this feature is not supported then registration will fail.
+
+- At the time this documentation was written, the debug driver mainly relies on
+  information gathered by the kernel panic callback notifier from three
+  sampling registers: EDPCSR, EDVIDSR and EDCIDSR: from EDPCSR we can get
+  program counter; EDVIDSR has information for secure state, exception level,
+  bit width, etc; EDCIDSR is context ID value which contains the sampled value
+  of CONTEXTIDR_EL1.
+
+- The driver supports a CPU running in either AArch64 or AArch32 mode. The
+  registers naming convention is a bit different between them, AArch64 uses
+  'ED' for register prefix (ARM DDI 0487A.k, chapter H9.1) and AArch32 uses
+  'DBG' as prefix (ARM DDI 0487A.k, chapter G5.1). The driver is unified to
+  use AArch64 naming convention.
+
+- ARMv8-a (ARM DDI 0487A.k) and ARMv7-a (ARM DDI 0406C.b) have different
+  register bits definition. So the driver consolidates two difference:
+
+  If PCSROffset=0b, on ARMv8-a the feature of EDPCSR is not implemented;
+  but ARMv7-a defines "PCSR samples are offset by a value that depends on the
+  instruction set state". For ARMv7-a, the driver checks furthermore if CPU
+  runs with ARM or thumb instruction set and calibrate PCSR value, the
+  detailed description for offset is in ARMv7-a ARM (ARM DDI 0406C.b) chapter
+  C11.11.34 "DBGPCSR, Program Counter Sampling Register".
+
+  If PCSROffset=0b0010, ARMv8-a defines "EDPCSR implemented, and samples have
+  no offset applied and do not sample the instruction set state in AArch32
+  state". So on ARMv8 if EDDEVID1.PCSROffset is 0b0010 and the CPU operates
+  in AArch32 state, EDPCSR is not sampled; when the CPU operates in AArch64
+  state EDPCSR is sampled and no offset are applied.
+
+
+Clock and power domain
+--
+
+Before accessing debug registers, we should ensure the clock and power domain
+have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1
+Debug registers', the debug registers are spread into two domains: the debug
+domain and the CPU domain.
+
++---+
+|   |
+|   |
+ +--+--+|
+dbg_clock -->|  |**||<-- cpu_clock
+ |Debug |**|   CPU  |
+ dbg_power_domain -->|  |**||<-- cpu_power_domain
+ +--+--+|
+|   |
+|   |
+   

[PATCH v13 8/9] arm64: dts: hi6220: register debug module

2017-05-25 Thread Leo Yan
Bind debug module driver for Hi6220.

Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 64 +++
 1 file changed, 64 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 1e5129b..21805b9 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -916,5 +916,69 @@
};
};
};
+
+   debug@f659 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf659 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f6592000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf6592000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f6594000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf6594000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f6596000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf6596000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d2000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d2000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d4000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d4000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d6000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d6000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
};
 };
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v13 3/9] doc: Add coresight_cpu_debug.enable to kernel-parameters.txt

2017-05-25 Thread Leo Yan
Add coresight_cpu_debug.enable to kernel-parameters.txt, this flag is
used to enable/disable the CPU sampling based debugging.

Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 Documentation/admin-guide/kernel-parameters.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 15f79c2..ff67ad7 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -649,6 +649,13 @@
/proc//coredump_filter.
See also Documentation/filesystems/proc.txt.
 
+   coresight_cpu_debug.enable
+   [ARM,ARM64]
+   Format: 
+   Enable/disable the CPU sampling based debugging.
+   0: default value, disable debugging
+   1: enable debugging at boot time
+
cpuidle.off=1   [CPU_IDLE]
disable the cpuidle sub-system
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v13 6/9] coresight: refactor with function of_coresight_get_cpu

2017-05-25 Thread Leo Yan
This is refactor to add function of_coresight_get_cpu(), so it's used to
retrieve CPU id for coresight component. Finally can use it as a common
function for multiple places.

Suggested-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/of_coresight.c | 43 +++---
 include/linux/coresight.h  |  3 +++
 2 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/drivers/hwtracing/coresight/of_coresight.c 
b/drivers/hwtracing/coresight/of_coresight.c
index 225b2dd..a187941 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -101,16 +101,40 @@ static int of_coresight_alloc_memory(struct device *dev,
return 0;
 }
 
+int of_coresight_get_cpu(const struct device_node *node)
+{
+   int cpu;
+   bool found;
+   struct device_node *dn, *np;
+
+   dn = of_parse_phandle(node, "cpu", 0);
+
+   /* Affinity defaults to CPU0 */
+   if (!dn)
+   return 0;
+
+   for_each_possible_cpu(cpu) {
+   np = of_cpu_device_node_get(cpu);
+   found = (dn == np);
+   of_node_put(np);
+   if (found)
+   break;
+   }
+   of_node_put(dn);
+
+   /* Affinity to CPU0 if no cpu nodes are found */
+   return found ? cpu : 0;
+}
+EXPORT_SYMBOL_GPL(of_coresight_get_cpu);
+
 struct coresight_platform_data *
 of_get_coresight_platform_data(struct device *dev,
   const struct device_node *node)
 {
-   int i = 0, ret = 0, cpu;
+   int i = 0, ret = 0;
struct coresight_platform_data *pdata;
struct of_endpoint endpoint, rendpoint;
struct device *rdev;
-   bool found;
-   struct device_node *dn, *np;
struct device_node *ep = NULL;
struct device_node *rparent = NULL;
struct device_node *rport = NULL;
@@ -177,18 +201,7 @@ of_get_coresight_platform_data(struct device *dev,
} while (ep);
}
 
-   dn = of_parse_phandle(node, "cpu", 0);
-   for_each_possible_cpu(cpu) {
-   np = of_cpu_device_node_get(cpu);
-   found = (dn == np);
-   of_node_put(np);
-   if (found)
-   break;
-   }
-   of_node_put(dn);
-
-   /* Affinity to CPU0 if no cpu nodes are found */
-   pdata->cpu = found ? cpu : 0;
+   pdata->cpu = of_coresight_get_cpu(node);
 
return pdata;
 }
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index bf0aa50..d950dad 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -263,10 +263,13 @@ static inline int coresight_timeout(void __iomem *addr, 
u32 offset,
 #endif
 
 #ifdef CONFIG_OF
+extern int of_coresight_get_cpu(const struct device_node *node);
 extern struct coresight_platform_data *
 of_get_coresight_platform_data(struct device *dev,
   const struct device_node *node);
 #else
+static inline int of_coresight_get_cpu(const struct device_node *node)
+{ return 0; }
 static inline struct coresight_platform_data *of_get_coresight_platform_data(
struct device *dev, const struct device_node *node) { return NULL; }
 #endif
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v13 4/9] MAINTAINERS: update file entries for Coresight subsystem

2017-05-25 Thread Leo Yan
Update document file entries for Coresight debug module.

Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9e98464..8623d95 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1207,7 +1207,9 @@ L:linux-arm-ker...@lists.infradead.org (moderated 
for non-subscribers)
 S: Maintained
 F: drivers/hwtracing/coresight/*
 F: Documentation/trace/coresight.txt
+F: Documentation/trace/coresight-cpu-debug.txt
 F: Documentation/devicetree/bindings/arm/coresight.txt
+F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
 F: Documentation/ABI/testing/sysfs-bus-coresight-devices-*
 F: tools/perf/arch/arm/util/pmu.c
 F: tools/perf/arch/arm/util/auxtrace.c
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v13 5/9] coresight: of_get_coresight_platform_data: Add missing of_node_put

2017-05-25 Thread Leo Yan
From: Suzuki K Poulose <suzuki.poul...@arm.com>

The of_get_coresight_platform_data iterates over the possible CPU nodes
to find a given cpu phandle. However it does not drop the reference
to the node pointer returned by the of_get_coresight_platform_data.

This patch also introduces another minor fix is to use
of_cpu_device_node_get() to replace of_get_cpu_node().

Cc: Mathieu Poirier <mathieu.poir...@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poul...@arm.com>
[Leo: minor tweaks for of_get_coresight_platform_data]
Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/of_coresight.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/hwtracing/coresight/of_coresight.c 
b/drivers/hwtracing/coresight/of_coresight.c
index 2749853..225b2dd 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -109,7 +109,8 @@ of_get_coresight_platform_data(struct device *dev,
struct coresight_platform_data *pdata;
struct of_endpoint endpoint, rendpoint;
struct device *rdev;
-   struct device_node *dn;
+   bool found;
+   struct device_node *dn, *np;
struct device_node *ep = NULL;
struct device_node *rparent = NULL;
struct device_node *rport = NULL;
@@ -176,17 +177,19 @@ of_get_coresight_platform_data(struct device *dev,
} while (ep);
}
 
-   /* Affinity defaults to CPU0 */
-   pdata->cpu = 0;
dn = of_parse_phandle(node, "cpu", 0);
-   for (cpu = 0; dn && cpu < nr_cpu_ids; cpu++) {
-   if (dn == of_get_cpu_node(cpu, NULL)) {
-   pdata->cpu = cpu;
+   for_each_possible_cpu(cpu) {
+   np = of_cpu_device_node_get(cpu);
+   found = (dn == np);
+   of_node_put(np);
+   if (found)
break;
-   }
}
of_node_put(dn);
 
+   /* Affinity to CPU0 if no cpu nodes are found */
+   pdata->cpu = found ? cpu : 0;
+
return pdata;
 }
 EXPORT_SYMBOL_GPL(of_get_coresight_platform_data);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v13 0/9] coresight: enable debug module

2017-05-25 Thread Leo Yan
ieu suggestion, refined dt binding description.
* Changed driver to support module mode;
* According to Mike suggestion and very appreciate the pseudo code,
  added support to force CPU powered up with register EDPRCR;
* According to discussions, added command line and debugfs nodes to
  support enabling debugging for boot time, or later can dynamically
  enable/disable debugging by debugfs.
* According to Rob Herring suggestion, one minor fixes in DT binding.
* According to Stephen Boyd suggestion, add const quality to structure
  device_node. And used use of_cpu_device_node_get() to replace
  of_get_cpu_node() in patch 0003.

Changes from v3:
* Added Suzuki K Poulose's patch to fix issue for the func
  of_get_coresight_platform_data() doesn't properly drop the reference
  to the CPU node pointer.
* According to Suzuki suggestion, added code to handl the corner case
  for ARMv8 CPU with aarch32 mode.
* According to Suzuki suggestion, changed compatible string to
  "arm,coresight-cpu-debug".
* According to Mathieu suggestion, added "power-domains" as optional
  properties.

Changes from v2:
* According to Mathieu Poirier suggestion, applied some minor fixes.
* Added two extra patches for enabling debug module on Hikey.

Changes from v1:
* According to Mike Leach suggestion, removed the binding for debug
  module clocks which have been directly provided by CPU clocks.
* According to Mathieu Poirier suggestion, added function
  of_coresight_get_cpu() and some minor refactors for debug module
  driver.

Changes from RFC:
* According to Mike Leach suggestion, added check for EDPRSR to avoid
  lockup; added supporting EDVIDSR and EDCIDSR registers.
* According to Mark Rutland and Mathieu Poirier suggestion, rewrote
  the documentation for DT binding.
* According to Mark and Mathieu suggestion, refined debug driver.

Leo Yan (8):
  coresight: bindings for CPU debug module
  doc: Add documentation for Coresight CPU debug
  doc: Add coresight_cpu_debug.enable to kernel-parameters.txt
  MAINTAINERS: update file entries for Coresight subsystem
  coresight: refactor with function of_coresight_get_cpu
  coresight: add support for CPU debug module
  arm64: dts: hi6220: register debug module
  arm64: dts: qcom: msm8916: Add debug unit

Suzuki K Poulose (1):
  coresight: of_get_coresight_platform_data: Add missing of_node_put

 Documentation/admin-guide/kernel-parameters.txt|   7 +
 .../bindings/arm/coresight-cpu-debug.txt   |  49 ++
 Documentation/trace/coresight-cpu-debug.txt| 175 ++
 MAINTAINERS|   2 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |  64 ++
 arch/arm64/boot/dts/qcom/msm8916.dtsi  |  32 +
 drivers/hwtracing/coresight/Kconfig|  14 +
 drivers/hwtracing/coresight/Makefile   |   1 +
 drivers/hwtracing/coresight/coresight-cpu-debug.c  | 700 +
 drivers/hwtracing/coresight/of_coresight.c |  40 +-
 include/linux/coresight.h  |   3 +
 11 files changed, 1075 insertions(+), 12 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
 create mode 100644 Documentation/trace/coresight-cpu-debug.txt
 create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v11 7/9] coresight: add support for CPU debug module

2017-05-23 Thread Leo Yan
Hi Mathieu,

On Tue, May 23, 2017 at 11:39:16AM -0600, Mathieu Poirier wrote:

[...]

> > +static bool debug_enable;
> > +module_param_named(enable, debug_enable, bool, 0600);
> > +MODULE_PARM_DESC(enable, "Knob to enable debug functionality "
> > +"(default is 0, which means is disabled by default)");
> 
> Checkpatch complains about a quoted string split across multiple
> lines.  You can probably removes the second one since information
> about the default value is already detailed in patch 03/09.  In this
> case I suggest modifiying the description to:
> 
> "Control to enable coresight CPU debug functionality"

It's shame for checkpatch.pl warning. Although everytime I used script
before sending out patch set, should think a bit more to handle them
better. Have sent new patch set to dismiss them.

Thanks,
Leo Yan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v12 1/9] coresight: bindings for CPU debug module

2017-05-23 Thread Leo Yan
According to ARMv8 architecture reference manual (ARM DDI 0487A.k)
Chapter 'Part H: External debug', the CPU can integrate debug module
and it can support self-hosted debug and external debug. Especially
for supporting self-hosted debug, this means the program can access
the debug module from mmio region; and usually the mmio region is
integrated with coresight.

So add document for binding debug component, includes binding to APB
clock; and also need specify the CPU node which the debug module is
dedicated to specific CPU.

Suggested-by: Mike Leach <mike.le...@linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Acked-by: Rob Herring <r...@kernel.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 .../bindings/arm/coresight-cpu-debug.txt   | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt

diff --git a/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt 
b/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
new file mode 100644
index 000..2982912
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
@@ -0,0 +1,49 @@
+* CoreSight CPU Debug Component:
+
+CoreSight CPU debug component are compliant with the ARMv8 architecture
+reference manual (ARM DDI 0487A.k) Chapter 'Part H: External debug'. The
+external debug module is mainly used for two modes: self-hosted debug and
+external debug, and it can be accessed from mmio region from Coresight
+and eventually the debug module connects with CPU for debugging. And the
+debug module provides sample-based profiling extension, which can be used
+to sample CPU program counter, secure state and exception level, etc;
+usually every CPU has one dedicated debug module to be connected.
+
+Required properties:
+
+- compatible : should be "arm,coresight-cpu-debug"; supplemented with
+   "arm,primecell" since this driver is using the AMBA bus
+  interface.
+
+- reg : physical base address and length of the register set.
+
+- clocks : the clock associated to this component.
+
+- clock-names : the name of the clock referenced by the code. Since we are
+using the AMBA framework, the name of the clock providing
+   the interconnect should be "apb_pclk" and the clock is
+   mandatory. The interface between the debug logic and the
+   processor core is clocked by the internal CPU clock, so it
+   is enabled with CPU clock by default.
+
+- cpu : the CPU phandle the debug module is affined to. When omitted
+   the module is considered to belong to CPU0.
+
+Optional properties:
+
+- power-domains: a phandle to the debug power domain. We use "power-domains"
+ binding to turn on the debug logic if it has own dedicated
+power domain and if necessary to use "cpuidle.off=1" or
+"nohlt" in the kernel command line or sysfs node to
+constrain idle states to ensure registers in the CPU power
+domain are accessible.
+
+Example:
+
+   debug@f659 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf659 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v12 2/9] doc: Add documentation for Coresight CPU debug

2017-05-23 Thread Leo Yan
Add detailed documentation for Coresight CPU debug driver, which
contains the info for driver implementation, Mike Leach excellent
summary for "clock and power domain". At the end some examples on how
to enable the debugging functionality are provided.

Suggested-by: Mike Leach <mike.le...@linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 Documentation/trace/coresight-cpu-debug.txt | 175 
 1 file changed, 175 insertions(+)
 create mode 100644 Documentation/trace/coresight-cpu-debug.txt

diff --git a/Documentation/trace/coresight-cpu-debug.txt 
b/Documentation/trace/coresight-cpu-debug.txt
new file mode 100644
index 000..b3da1f9
--- /dev/null
+++ b/Documentation/trace/coresight-cpu-debug.txt
@@ -0,0 +1,175 @@
+   Coresight CPU Debug Module
+   ==========
+
+   Author:   Leo Yan <leo@linaro.org>
+   Date: April 5th, 2017
+
+Introduction
+
+
+Coresight CPU debug module is defined in ARMv8-a architecture reference manual
+(ARM DDI 0487A.k) Chapter 'Part H: External debug', the CPU can integrate
+debug module and it is mainly used for two modes: self-hosted debug and
+external debug. Usually the external debug mode is well known as the external
+debugger connects with SoC from JTAG port; on the other hand the program can
+explore debugging method which rely on self-hosted debug mode, this document
+is to focus on this part.
+
+The debug module provides sample-based profiling extension, which can be used
+to sample CPU program counter, secure state and exception level, etc; usually
+every CPU has one dedicated debug module to be connected. Based on self-hosted
+debug mechanism, Linux kernel can access these related registers from mmio
+region when the kernel panic happens. The callback notifier for kernel panic
+will dump related registers for every CPU; finally this is good for assistant
+analysis for panic.
+
+
+Implementation
+--
+
+- During driver registration, it uses EDDEVID and EDDEVID1 - two device ID
+  registers to decide if sample-based profiling is implemented or not. On some
+  platforms this hardware feature is fully or partially implemented; and if
+  this feature is not supported then registration will fail.
+
+- At the time this documentation was written, the debug driver mainly relies on
+  information gathered by the kernel panic callback notifier from three
+  sampling registers: EDPCSR, EDVIDSR and EDCIDSR: from EDPCSR we can get
+  program counter; EDVIDSR has information for secure state, exception level,
+  bit width, etc; EDCIDSR is context ID value which contains the sampled value
+  of CONTEXTIDR_EL1.
+
+- The driver supports a CPU running in either AArch64 or AArch32 mode. The
+  registers naming convention is a bit different between them, AArch64 uses
+  'ED' for register prefix (ARM DDI 0487A.k, chapter H9.1) and AArch32 uses
+  'DBG' as prefix (ARM DDI 0487A.k, chapter G5.1). The driver is unified to
+  use AArch64 naming convention.
+
+- ARMv8-a (ARM DDI 0487A.k) and ARMv7-a (ARM DDI 0406C.b) have different
+  register bits definition. So the driver consolidates two difference:
+
+  If PCSROffset=0b, on ARMv8-a the feature of EDPCSR is not implemented;
+  but ARMv7-a defines "PCSR samples are offset by a value that depends on the
+  instruction set state". For ARMv7-a, the driver checks furthermore if CPU
+  runs with ARM or thumb instruction set and calibrate PCSR value, the
+  detailed description for offset is in ARMv7-a ARM (ARM DDI 0406C.b) chapter
+  C11.11.34 "DBGPCSR, Program Counter Sampling Register".
+
+  If PCSROffset=0b0010, ARMv8-a defines "EDPCSR implemented, and samples have
+  no offset applied and do not sample the instruction set state in AArch32
+  state". So on ARMv8 if EDDEVID1.PCSROffset is 0b0010 and the CPU operates
+  in AArch32 state, EDPCSR is not sampled; when the CPU operates in AArch64
+  state EDPCSR is sampled and no offset are applied.
+
+
+Clock and power domain
+--
+
+Before accessing debug registers, we should ensure the clock and power domain
+have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1
+Debug registers', the debug registers are spread into two domains: the debug
+domain and the CPU domain.
+
++---+
+|   |
+|   |
+ +--+--+|
+dbg_clock -->|  |**||<-- cpu_clock
+ |Debug |**|   CPU  |
+ dbg_power_domain -->|  |**||<-- cpu_power_domain
+ +--+--+|
+|   |
+|   |
+   

[PATCH v12 3/9] doc: Add coresight_cpu_debug.enable to kernel-parameters.txt

2017-05-23 Thread Leo Yan
Add coresight_cpu_debug.enable to kernel-parameters.txt, this flag is
used to enable/disable the CPU sampling based debugging.

Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 Documentation/admin-guide/kernel-parameters.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 15f79c2..ff67ad7 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -649,6 +649,13 @@
/proc//coredump_filter.
See also Documentation/filesystems/proc.txt.
 
+   coresight_cpu_debug.enable
+   [ARM,ARM64]
+   Format: 
+   Enable/disable the CPU sampling based debugging.
+   0: default value, disable debugging
+   1: enable debugging at boot time
+
cpuidle.off=1   [CPU_IDLE]
disable the cpuidle sub-system
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v12 5/9] coresight: of_get_coresight_platform_data: Add missing of_node_put

2017-05-23 Thread Leo Yan
From: Suzuki K Poulose <suzuki.poul...@arm.com>

The of_get_coresight_platform_data iterates over the possible CPU nodes
to find a given cpu phandle. However it does not drop the reference
to the node pointer returned by the of_get_coresight_platform_data.

This patch also introduces another minor fix is to use
of_cpu_device_node_get() to replace of_get_cpu_node().

Cc: Mathieu Poirier <mathieu.poir...@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poul...@arm.com>
[Leo: minor tweaks for of_get_coresight_platform_data]
Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/of_coresight.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/hwtracing/coresight/of_coresight.c 
b/drivers/hwtracing/coresight/of_coresight.c
index 2749853..225b2dd 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -109,7 +109,8 @@ of_get_coresight_platform_data(struct device *dev,
struct coresight_platform_data *pdata;
struct of_endpoint endpoint, rendpoint;
struct device *rdev;
-   struct device_node *dn;
+   bool found;
+   struct device_node *dn, *np;
struct device_node *ep = NULL;
struct device_node *rparent = NULL;
struct device_node *rport = NULL;
@@ -176,17 +177,19 @@ of_get_coresight_platform_data(struct device *dev,
} while (ep);
}
 
-   /* Affinity defaults to CPU0 */
-   pdata->cpu = 0;
dn = of_parse_phandle(node, "cpu", 0);
-   for (cpu = 0; dn && cpu < nr_cpu_ids; cpu++) {
-   if (dn == of_get_cpu_node(cpu, NULL)) {
-   pdata->cpu = cpu;
+   for_each_possible_cpu(cpu) {
+   np = of_cpu_device_node_get(cpu);
+   found = (dn == np);
+   of_node_put(np);
+   if (found)
break;
-   }
}
of_node_put(dn);
 
+   /* Affinity to CPU0 if no cpu nodes are found */
+   pdata->cpu = found ? cpu : 0;
+
return pdata;
 }
 EXPORT_SYMBOL_GPL(of_get_coresight_platform_data);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v12 9/9] arm64: dts: qcom: msm8916: Add debug unit

2017-05-23 Thread Leo Yan
Add debug unit on Qualcomm msm8916 based platforms, including the
DragonBoard 410c board.

Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index ab30939..17691ab 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -1116,6 +1116,38 @@
};
};
 
+   debug@85 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x85 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@852000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x852000 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@854000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x854000 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@856000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x856000 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
etm@85c000 {
compatible = "arm,coresight-etm4x", "arm,primecell";
reg = <0x85c000 0x1000>;
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v12 7/9] coresight: add support for CPU debug module

2017-05-23 Thread Leo Yan
Coresight includes debug module and usually the module connects with CPU
debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has
description for related info in "Part H: External Debug".

Chapter H7 "The Sample-based Profiling Extension" introduces several
sampling registers, e.g. we can check program counter value with
combined CPU exception level, secure state, etc. So this is helpful for
analysis CPU lockup scenarios, e.g. if one CPU has run into infinite
loop with IRQ disabled. In this case the CPU cannot switch context and
handle any interrupt (including IPIs), as the result it cannot handle
SMP call for stack dump.

This patch is to enable coresight debug module, so firstly this driver
is to bind apb clock for debug module and this is to ensure the debug
module can be accessed from program or external debugger. And the driver
uses sample-based registers for debug purpose, e.g. when system triggers
panic, the driver will dump program counter and combined context
registers (EDCIDSR, EDVIDSR); by parsing context registers so can
quickly get to know CPU secure state, exception level, etc.

Some of the debug module registers are located in CPU power domain, so
this requires the CPU power domain stays on when access related debug
registers, but the power management for CPU power domain is quite
dependent on SoC integration for power management. For the platforms
which with sane power controller implementations, this driver follows
the method to set EDPRCR to try to pull the CPU out of low power state
and then set 'no power down request' bit so the CPU has no chance to
lose power.

If the SoC has not followed up this design well for power management
controller, the user should use the command line parameter or sysfs
to constrain all or partial idle states to ensure the CPU power
domain is enabled and access coresight CPU debug component safely.

Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/Kconfig   |  14 +
 drivers/hwtracing/coresight/Makefile  |   1 +
 drivers/hwtracing/coresight/coresight-cpu-debug.c | 696 ++
 3 files changed, 711 insertions(+)
 create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c

diff --git a/drivers/hwtracing/coresight/Kconfig 
b/drivers/hwtracing/coresight/Kconfig
index 130cb21..8d55d6d 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -89,4 +89,18 @@ config CORESIGHT_STM
  logging useful software events or data coming from various entities
  in the system, possibly running different OSs
 
+config CORESIGHT_CPU_DEBUG
+   tristate "CoreSight CPU Debug driver"
+   depends on ARM || ARM64
+   depends on DEBUG_FS
+   help
+ This driver provides support for coresight debugging module. This
+ is primarily used to dump sample-based profiling registers when
+ system triggers panic, the driver will parse context registers so
+ can quickly get to know program counter (PC), secure state,
+ exception level, etc. Before use debugging functionality, platform
+ needs to ensure the clock domain and power domain are enabled
+ properly, please refer Documentation/trace/coresight-cpu-debug.txt
+ for detailed description and the example for usage.
+
 endif
diff --git a/drivers/hwtracing/coresight/Makefile 
b/drivers/hwtracing/coresight/Makefile
index af480d9..433d590 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
coresight-etm4x-sysfs.o
 obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
 obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
+obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c 
b/drivers/hwtracing/coresight/coresight-cpu-debug.c
new file mode 100644
index 000..f5c1235
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
@@ -0,0 +1,696 @@
+/*
+ * Copyright (c) 2017 Linaro Limited. All rights reserved.
+ *
+ * Author: Leo Yan <leo@linaro.org>
+ *
+ * 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 published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+#include 
+#include 
+#include 

[PATCH v12 8/9] arm64: dts: hi6220: register debug module

2017-05-23 Thread Leo Yan
Bind debug module driver for Hi6220.

Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 64 +++
 1 file changed, 64 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 1e5129b..21805b9 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -916,5 +916,69 @@
};
};
};
+
+   debug@f659 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf659 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f6592000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf6592000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f6594000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf6594000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f6596000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf6596000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d2000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d2000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d4000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d4000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d6000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d6000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
};
 };
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v12 6/9] coresight: refactor with function of_coresight_get_cpu

2017-05-23 Thread Leo Yan
This is refactor to add function of_coresight_get_cpu(), so it's used to
retrieve CPU id for coresight component. Finally can use it as a common
function for multiple places.

Suggested-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/of_coresight.c | 43 +++---
 include/linux/coresight.h  |  3 +++
 2 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/drivers/hwtracing/coresight/of_coresight.c 
b/drivers/hwtracing/coresight/of_coresight.c
index 225b2dd..a187941 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -101,16 +101,40 @@ static int of_coresight_alloc_memory(struct device *dev,
return 0;
 }
 
+int of_coresight_get_cpu(const struct device_node *node)
+{
+   int cpu;
+   bool found;
+   struct device_node *dn, *np;
+
+   dn = of_parse_phandle(node, "cpu", 0);
+
+   /* Affinity defaults to CPU0 */
+   if (!dn)
+   return 0;
+
+   for_each_possible_cpu(cpu) {
+   np = of_cpu_device_node_get(cpu);
+   found = (dn == np);
+   of_node_put(np);
+   if (found)
+   break;
+   }
+   of_node_put(dn);
+
+   /* Affinity to CPU0 if no cpu nodes are found */
+   return found ? cpu : 0;
+}
+EXPORT_SYMBOL_GPL(of_coresight_get_cpu);
+
 struct coresight_platform_data *
 of_get_coresight_platform_data(struct device *dev,
   const struct device_node *node)
 {
-   int i = 0, ret = 0, cpu;
+   int i = 0, ret = 0;
struct coresight_platform_data *pdata;
struct of_endpoint endpoint, rendpoint;
struct device *rdev;
-   bool found;
-   struct device_node *dn, *np;
struct device_node *ep = NULL;
struct device_node *rparent = NULL;
struct device_node *rport = NULL;
@@ -177,18 +201,7 @@ of_get_coresight_platform_data(struct device *dev,
} while (ep);
}
 
-   dn = of_parse_phandle(node, "cpu", 0);
-   for_each_possible_cpu(cpu) {
-   np = of_cpu_device_node_get(cpu);
-   found = (dn == np);
-   of_node_put(np);
-   if (found)
-   break;
-   }
-   of_node_put(dn);
-
-   /* Affinity to CPU0 if no cpu nodes are found */
-   pdata->cpu = found ? cpu : 0;
+   pdata->cpu = of_coresight_get_cpu(node);
 
return pdata;
 }
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index bf0aa50..d950dad 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -263,10 +263,13 @@ static inline int coresight_timeout(void __iomem *addr, 
u32 offset,
 #endif
 
 #ifdef CONFIG_OF
+extern int of_coresight_get_cpu(const struct device_node *node);
 extern struct coresight_platform_data *
 of_get_coresight_platform_data(struct device *dev,
   const struct device_node *node);
 #else
+static inline int of_coresight_get_cpu(const struct device_node *node)
+{ return 0; }
 static inline struct coresight_platform_data *of_get_coresight_platform_data(
struct device *dev, const struct device_node *node) { return NULL; }
 #endif
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v12 0/9] coresight: enable debug module

2017-05-23 Thread Leo Yan
 mode;
* According to Mike suggestion and very appreciate the pseudo code,
  added support to force CPU powered up with register EDPRCR;
* According to discussions, added command line and debugfs nodes to
  support enabling debugging for boot time, or later can dynamically
  enable/disable debugging by debugfs.
* According to Rob Herring suggestion, one minor fixes in DT binding.
* According to Stephen Boyd suggestion, add const quality to structure
  device_node. And used use of_cpu_device_node_get() to replace
  of_get_cpu_node() in patch 0003.

Changes from v3:
* Added Suzuki K Poulose's patch to fix issue for the func
  of_get_coresight_platform_data() doesn't properly drop the reference
  to the CPU node pointer.
* According to Suzuki suggestion, added code to handl the corner case
  for ARMv8 CPU with aarch32 mode.
* According to Suzuki suggestion, changed compatible string to
  "arm,coresight-cpu-debug".
* According to Mathieu suggestion, added "power-domains" as optional
  properties.

Changes from v2:
* According to Mathieu Poirier suggestion, applied some minor fixes.
* Added two extra patches for enabling debug module on Hikey.

Changes from v1:
* According to Mike Leach suggestion, removed the binding for debug
  module clocks which have been directly provided by CPU clocks.
* According to Mathieu Poirier suggestion, added function
  of_coresight_get_cpu() and some minor refactors for debug module
  driver.

Changes from RFC:
* According to Mike Leach suggestion, added check for EDPRSR to avoid
  lockup; added supporting EDVIDSR and EDCIDSR registers.
* According to Mark Rutland and Mathieu Poirier suggestion, rewrote
  the documentation for DT binding.
* According to Mark and Mathieu suggestion, refined debug driver.


Leo Yan (8):
  coresight: bindings for CPU debug module
  doc: Add documentation for Coresight CPU debug
  doc: Add coresight_cpu_debug.enable to kernel-parameters.txt
  MAINTAINERS: update file entries for Coresight subsystem
  coresight: refactor with function of_coresight_get_cpu
  coresight: add support for CPU debug module
  arm64: dts: hi6220: register debug module
  arm64: dts: qcom: msm8916: Add debug unit

Suzuki K Poulose (1):
  coresight: of_get_coresight_platform_data: Add missing of_node_put

 Documentation/admin-guide/kernel-parameters.txt|   7 +
 .../bindings/arm/coresight-cpu-debug.txt   |  49 ++
 Documentation/trace/coresight-cpu-debug.txt| 175 ++
 MAINTAINERS|   2 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |  64 ++
 arch/arm64/boot/dts/qcom/msm8916.dtsi  |  32 +
 drivers/hwtracing/coresight/Kconfig|  14 +
 drivers/hwtracing/coresight/Makefile   |   1 +
 drivers/hwtracing/coresight/coresight-cpu-debug.c  | 696 +
 drivers/hwtracing/coresight/of_coresight.c |  40 +-
 include/linux/coresight.h  |   3 +
 11 files changed, 1071 insertions(+), 12 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
 create mode 100644 Documentation/trace/coresight-cpu-debug.txt
 create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v11 0/9] coresight: enable debug module

2017-05-23 Thread Leo Yan
ssions, added command line and debugfs nodes to
  support enabling debugging for boot time, or later can dynamically
  enable/disable debugging by debugfs.
* According to Rob Herring suggestion, one minor fixes in DT binding.
* According to Stephen Boyd suggestion, add const quality to structure
  device_node. And used use of_cpu_device_node_get() to replace
  of_get_cpu_node() in patch 0003.

Changes from v3:
* Added Suzuki K Poulose's patch to fix issue for the func
  of_get_coresight_platform_data() doesn't properly drop the reference
  to the CPU node pointer.
* According to Suzuki suggestion, added code to handl the corner case
  for ARMv8 CPU with aarch32 mode.
* According to Suzuki suggestion, changed compatible string to
  "arm,coresight-cpu-debug".
* According to Mathieu suggestion, added "power-domains" as optional
  properties.

Changes from v2:
* According to Mathieu Poirier suggestion, applied some minor fixes.
* Added two extra patches for enabling debug module on Hikey.

Changes from v1:
* According to Mike Leach suggestion, removed the binding for debug
  module clocks which have been directly provided by CPU clocks.
* According to Mathieu Poirier suggestion, added function
  of_coresight_get_cpu() and some minor refactors for debug module
  driver.

Changes from RFC:
* According to Mike Leach suggestion, added check for EDPRSR to avoid
  lockup; added supporting EDVIDSR and EDCIDSR registers.
* According to Mark Rutland and Mathieu Poirier suggestion, rewrote
  the documentation for DT binding.
* According to Mark and Mathieu suggestion, refined debug driver.

Leo Yan (8):
  coresight: bindings for CPU debug module
  doc: Add documentation for Coresight CPU debug
  doc: Add coresight_cpu_debug.enable to kernel-parameters.txt
  MAINTAINERS: update file entries for Coresight subsystem
  coresight: refactor with function of_coresight_get_cpu
  coresight: add support for CPU debug module
  arm64: dts: hi6220: register debug module
  arm64: dts: qcom: msm8916: Add debug unit

Suzuki K Poulose (1):
  coresight: of_get_coresight_platform_data: Add missing of_node_put

 Documentation/admin-guide/kernel-parameters.txt|   7 +
 .../bindings/arm/coresight-cpu-debug.txt   |  49 ++
 Documentation/trace/coresight-cpu-debug.txt| 175 ++
 MAINTAINERS|   2 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |  64 ++
 arch/arm64/boot/dts/qcom/msm8916.dtsi  |  32 +
 drivers/hwtracing/coresight/Kconfig|  14 +
 drivers/hwtracing/coresight/Makefile   |   1 +
 drivers/hwtracing/coresight/coresight-cpu-debug.c  | 696 +
 drivers/hwtracing/coresight/of_coresight.c |  40 +-
 include/linux/coresight.h  |   3 +
 11 files changed, 1071 insertions(+), 12 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
 create mode 100644 Documentation/trace/coresight-cpu-debug.txt
 create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v11 5/9] coresight: of_get_coresight_platform_data: Add missing of_node_put

2017-05-23 Thread Leo Yan
From: Suzuki K Poulose <suzuki.poul...@arm.com>

The of_get_coresight_platform_data iterates over the possible CPU nodes
to find a given cpu phandle. However it does not drop the reference
to the node pointer returned by the of_get_coresight_platform_data.

This patch also introduces another minor fix is to use
of_cpu_device_node_get() to replace of_get_cpu_node().

Cc: Mathieu Poirier <mathieu.poir...@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poul...@arm.com>
[Leo: minor tweaks for of_get_coresight_platform_data]
Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/of_coresight.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/hwtracing/coresight/of_coresight.c 
b/drivers/hwtracing/coresight/of_coresight.c
index 2749853..225b2dd 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -109,7 +109,8 @@ of_get_coresight_platform_data(struct device *dev,
struct coresight_platform_data *pdata;
struct of_endpoint endpoint, rendpoint;
struct device *rdev;
-   struct device_node *dn;
+   bool found;
+   struct device_node *dn, *np;
struct device_node *ep = NULL;
struct device_node *rparent = NULL;
struct device_node *rport = NULL;
@@ -176,17 +177,19 @@ of_get_coresight_platform_data(struct device *dev,
} while (ep);
}
 
-   /* Affinity defaults to CPU0 */
-   pdata->cpu = 0;
dn = of_parse_phandle(node, "cpu", 0);
-   for (cpu = 0; dn && cpu < nr_cpu_ids; cpu++) {
-   if (dn == of_get_cpu_node(cpu, NULL)) {
-   pdata->cpu = cpu;
+   for_each_possible_cpu(cpu) {
+   np = of_cpu_device_node_get(cpu);
+   found = (dn == np);
+   of_node_put(np);
+   if (found)
break;
-   }
}
of_node_put(dn);
 
+   /* Affinity to CPU0 if no cpu nodes are found */
+   pdata->cpu = found ? cpu : 0;
+
return pdata;
 }
 EXPORT_SYMBOL_GPL(of_get_coresight_platform_data);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v11 6/9] coresight: refactor with function of_coresight_get_cpu

2017-05-23 Thread Leo Yan
This is refactor to add function of_coresight_get_cpu(), so it's used to
retrieve CPU id for coresight component. Finally can use it as a common
function for multiple places.

Suggested-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/of_coresight.c | 43 +++---
 include/linux/coresight.h  |  3 +++
 2 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/drivers/hwtracing/coresight/of_coresight.c 
b/drivers/hwtracing/coresight/of_coresight.c
index 225b2dd..a187941 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -101,16 +101,40 @@ static int of_coresight_alloc_memory(struct device *dev,
return 0;
 }
 
+int of_coresight_get_cpu(const struct device_node *node)
+{
+   int cpu;
+   bool found;
+   struct device_node *dn, *np;
+
+   dn = of_parse_phandle(node, "cpu", 0);
+
+   /* Affinity defaults to CPU0 */
+   if (!dn)
+   return 0;
+
+   for_each_possible_cpu(cpu) {
+   np = of_cpu_device_node_get(cpu);
+   found = (dn == np);
+   of_node_put(np);
+   if (found)
+   break;
+   }
+   of_node_put(dn);
+
+   /* Affinity to CPU0 if no cpu nodes are found */
+   return found ? cpu : 0;
+}
+EXPORT_SYMBOL_GPL(of_coresight_get_cpu);
+
 struct coresight_platform_data *
 of_get_coresight_platform_data(struct device *dev,
   const struct device_node *node)
 {
-   int i = 0, ret = 0, cpu;
+   int i = 0, ret = 0;
struct coresight_platform_data *pdata;
struct of_endpoint endpoint, rendpoint;
struct device *rdev;
-   bool found;
-   struct device_node *dn, *np;
struct device_node *ep = NULL;
struct device_node *rparent = NULL;
struct device_node *rport = NULL;
@@ -177,18 +201,7 @@ of_get_coresight_platform_data(struct device *dev,
} while (ep);
}
 
-   dn = of_parse_phandle(node, "cpu", 0);
-   for_each_possible_cpu(cpu) {
-   np = of_cpu_device_node_get(cpu);
-   found = (dn == np);
-   of_node_put(np);
-   if (found)
-   break;
-   }
-   of_node_put(dn);
-
-   /* Affinity to CPU0 if no cpu nodes are found */
-   pdata->cpu = found ? cpu : 0;
+   pdata->cpu = of_coresight_get_cpu(node);
 
return pdata;
 }
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index bf0aa50..d950dad 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -263,10 +263,13 @@ static inline int coresight_timeout(void __iomem *addr, 
u32 offset,
 #endif
 
 #ifdef CONFIG_OF
+extern int of_coresight_get_cpu(const struct device_node *node);
 extern struct coresight_platform_data *
 of_get_coresight_platform_data(struct device *dev,
   const struct device_node *node);
 #else
+static inline int of_coresight_get_cpu(const struct device_node *node)
+{ return 0; }
 static inline struct coresight_platform_data *of_get_coresight_platform_data(
struct device *dev, const struct device_node *node) { return NULL; }
 #endif
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v11 7/9] coresight: add support for CPU debug module

2017-05-23 Thread Leo Yan
Coresight includes debug module and usually the module connects with CPU
debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has
description for related info in "Part H: External Debug".

Chapter H7 "The Sample-based Profiling Extension" introduces several
sampling registers, e.g. we can check program counter value with
combined CPU exception level, secure state, etc. So this is helpful for
analysis CPU lockup scenarios, e.g. if one CPU has run into infinite
loop with IRQ disabled. In this case the CPU cannot switch context and
handle any interrupt (including IPIs), as the result it cannot handle
SMP call for stack dump.

This patch is to enable coresight debug module, so firstly this driver
is to bind apb clock for debug module and this is to ensure the debug
module can be accessed from program or external debugger. And the driver
uses sample-based registers for debug purpose, e.g. when system triggers
panic, the driver will dump program counter and combined context
registers (EDCIDSR, EDVIDSR); by parsing context registers so can
quickly get to know CPU secure state, exception level, etc.

Some of the debug module registers are located in CPU power domain, so
this requires the CPU power domain stays on when access related debug
registers, but the power management for CPU power domain is quite
dependent on SoC integration for power management. For the platforms
which with sane power controller implementations, this driver follows
the method to set EDPRCR to try to pull the CPU out of low power state
and then set 'no power down request' bit so the CPU has no chance to
lose power.

If the SoC has not followed up this design well for power management
controller, the user should use the command line parameter or sysfs
to constrain all or partial idle states to ensure the CPU power
domain is enabled and access coresight CPU debug component safely.

Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/Kconfig   |  14 +
 drivers/hwtracing/coresight/Makefile  |   1 +
 drivers/hwtracing/coresight/coresight-cpu-debug.c | 696 ++
 3 files changed, 711 insertions(+)
 create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c

diff --git a/drivers/hwtracing/coresight/Kconfig 
b/drivers/hwtracing/coresight/Kconfig
index 130cb21..8d55d6d 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -89,4 +89,18 @@ config CORESIGHT_STM
  logging useful software events or data coming from various entities
  in the system, possibly running different OSs
 
+config CORESIGHT_CPU_DEBUG
+   tristate "CoreSight CPU Debug driver"
+   depends on ARM || ARM64
+   depends on DEBUG_FS
+   help
+ This driver provides support for coresight debugging module. This
+ is primarily used to dump sample-based profiling registers when
+ system triggers panic, the driver will parse context registers so
+ can quickly get to know program counter (PC), secure state,
+ exception level, etc. Before use debugging functionality, platform
+ needs to ensure the clock domain and power domain are enabled
+ properly, please refer Documentation/trace/coresight-cpu-debug.txt
+ for detailed description and the example for usage.
+
 endif
diff --git a/drivers/hwtracing/coresight/Makefile 
b/drivers/hwtracing/coresight/Makefile
index af480d9..433d590 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
coresight-etm4x-sysfs.o
 obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
 obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
+obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c 
b/drivers/hwtracing/coresight/coresight-cpu-debug.c
new file mode 100644
index 000..3589174
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
@@ -0,0 +1,696 @@
+/*
+ * Copyright (c) 2017 Linaro Limited. All rights reserved.
+ *
+ * Author: Leo Yan <leo@linaro.org>
+ *
+ * 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 published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+#include 
+#include 
+#include 

[PATCH v11 8/9] arm64: dts: hi6220: register debug module

2017-05-23 Thread Leo Yan
Bind debug module driver for Hi6220.

Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 64 +++
 1 file changed, 64 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 1e5129b..21805b9 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -916,5 +916,69 @@
};
};
};
+
+   debug@f659 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf659 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f6592000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf6592000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f6594000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf6594000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f6596000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf6596000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d2000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d2000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d4000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d4000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d6000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d6000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
};
 };
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v11 9/9] arm64: dts: qcom: msm8916: Add debug unit

2017-05-23 Thread Leo Yan
Add debug unit on Qualcomm msm8916 based platforms, including the
DragonBoard 410c board.

Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index ab30939..17691ab 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -1116,6 +1116,38 @@
};
};
 
+   debug@85 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x85 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@852000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x852000 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@854000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x854000 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@856000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x856000 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
etm@85c000 {
compatible = "arm,coresight-etm4x", "arm,primecell";
reg = <0x85c000 0x1000>;
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v11 1/9] coresight: bindings for CPU debug module

2017-05-23 Thread Leo Yan
According to ARMv8 architecture reference manual (ARM DDI 0487A.k)
Chapter 'Part H: External debug', the CPU can integrate debug module
and it can support self-hosted debug and external debug. Especially
for supporting self-hosted debug, this means the program can access
the debug module from mmio region; and usually the mmio region is
integrated with coresight.

So add document for binding debug component, includes binding to APB
clock; and also need specify the CPU node which the debug module is
dedicated to specific CPU.

Suggested-by: Mike Leach <mike.le...@linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Acked-by: Rob Herring <r...@kernel.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 .../bindings/arm/coresight-cpu-debug.txt   | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt

diff --git a/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt 
b/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
new file mode 100644
index 000..2982912
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
@@ -0,0 +1,49 @@
+* CoreSight CPU Debug Component:
+
+CoreSight CPU debug component are compliant with the ARMv8 architecture
+reference manual (ARM DDI 0487A.k) Chapter 'Part H: External debug'. The
+external debug module is mainly used for two modes: self-hosted debug and
+external debug, and it can be accessed from mmio region from Coresight
+and eventually the debug module connects with CPU for debugging. And the
+debug module provides sample-based profiling extension, which can be used
+to sample CPU program counter, secure state and exception level, etc;
+usually every CPU has one dedicated debug module to be connected.
+
+Required properties:
+
+- compatible : should be "arm,coresight-cpu-debug"; supplemented with
+   "arm,primecell" since this driver is using the AMBA bus
+  interface.
+
+- reg : physical base address and length of the register set.
+
+- clocks : the clock associated to this component.
+
+- clock-names : the name of the clock referenced by the code. Since we are
+using the AMBA framework, the name of the clock providing
+   the interconnect should be "apb_pclk" and the clock is
+   mandatory. The interface between the debug logic and the
+   processor core is clocked by the internal CPU clock, so it
+   is enabled with CPU clock by default.
+
+- cpu : the CPU phandle the debug module is affined to. When omitted
+   the module is considered to belong to CPU0.
+
+Optional properties:
+
+- power-domains: a phandle to the debug power domain. We use "power-domains"
+ binding to turn on the debug logic if it has own dedicated
+power domain and if necessary to use "cpuidle.off=1" or
+"nohlt" in the kernel command line or sysfs node to
+constrain idle states to ensure registers in the CPU power
+domain are accessible.
+
+Example:
+
+   debug@f659 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf659 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v11 2/9] doc: Add documentation for Coresight CPU debug

2017-05-23 Thread Leo Yan
Add detailed documentation for Coresight CPU debug driver, which
contains the info for driver implementation, Mike Leach excellent
summary for "clock and power domain". At the end some examples on how
to enable the debugging functionality are provided.

Suggested-by: Mike Leach <mike.le...@linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 Documentation/trace/coresight-cpu-debug.txt | 175 
 1 file changed, 175 insertions(+)
 create mode 100644 Documentation/trace/coresight-cpu-debug.txt

diff --git a/Documentation/trace/coresight-cpu-debug.txt 
b/Documentation/trace/coresight-cpu-debug.txt
new file mode 100644
index 000..b3da1f9
--- /dev/null
+++ b/Documentation/trace/coresight-cpu-debug.txt
@@ -0,0 +1,175 @@
+   Coresight CPU Debug Module
+   ==========
+
+   Author:   Leo Yan <leo@linaro.org>
+   Date: April 5th, 2017
+
+Introduction
+
+
+Coresight CPU debug module is defined in ARMv8-a architecture reference manual
+(ARM DDI 0487A.k) Chapter 'Part H: External debug', the CPU can integrate
+debug module and it is mainly used for two modes: self-hosted debug and
+external debug. Usually the external debug mode is well known as the external
+debugger connects with SoC from JTAG port; on the other hand the program can
+explore debugging method which rely on self-hosted debug mode, this document
+is to focus on this part.
+
+The debug module provides sample-based profiling extension, which can be used
+to sample CPU program counter, secure state and exception level, etc; usually
+every CPU has one dedicated debug module to be connected. Based on self-hosted
+debug mechanism, Linux kernel can access these related registers from mmio
+region when the kernel panic happens. The callback notifier for kernel panic
+will dump related registers for every CPU; finally this is good for assistant
+analysis for panic.
+
+
+Implementation
+--
+
+- During driver registration, it uses EDDEVID and EDDEVID1 - two device ID
+  registers to decide if sample-based profiling is implemented or not. On some
+  platforms this hardware feature is fully or partially implemented; and if
+  this feature is not supported then registration will fail.
+
+- At the time this documentation was written, the debug driver mainly relies on
+  information gathered by the kernel panic callback notifier from three
+  sampling registers: EDPCSR, EDVIDSR and EDCIDSR: from EDPCSR we can get
+  program counter; EDVIDSR has information for secure state, exception level,
+  bit width, etc; EDCIDSR is context ID value which contains the sampled value
+  of CONTEXTIDR_EL1.
+
+- The driver supports a CPU running in either AArch64 or AArch32 mode. The
+  registers naming convention is a bit different between them, AArch64 uses
+  'ED' for register prefix (ARM DDI 0487A.k, chapter H9.1) and AArch32 uses
+  'DBG' as prefix (ARM DDI 0487A.k, chapter G5.1). The driver is unified to
+  use AArch64 naming convention.
+
+- ARMv8-a (ARM DDI 0487A.k) and ARMv7-a (ARM DDI 0406C.b) have different
+  register bits definition. So the driver consolidates two difference:
+
+  If PCSROffset=0b, on ARMv8-a the feature of EDPCSR is not implemented;
+  but ARMv7-a defines "PCSR samples are offset by a value that depends on the
+  instruction set state". For ARMv7-a, the driver checks furthermore if CPU
+  runs with ARM or thumb instruction set and calibrate PCSR value, the
+  detailed description for offset is in ARMv7-a ARM (ARM DDI 0406C.b) chapter
+  C11.11.34 "DBGPCSR, Program Counter Sampling Register".
+
+  If PCSROffset=0b0010, ARMv8-a defines "EDPCSR implemented, and samples have
+  no offset applied and do not sample the instruction set state in AArch32
+  state". So on ARMv8 if EDDEVID1.PCSROffset is 0b0010 and the CPU operates
+  in AArch32 state, EDPCSR is not sampled; when the CPU operates in AArch64
+  state EDPCSR is sampled and no offset are applied.
+
+
+Clock and power domain
+--
+
+Before accessing debug registers, we should ensure the clock and power domain
+have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1
+Debug registers', the debug registers are spread into two domains: the debug
+domain and the CPU domain.
+
++---+
+|   |
+|   |
+ +--+--+|
+dbg_clock -->|  |**||<-- cpu_clock
+ |Debug |**|   CPU  |
+ dbg_power_domain -->|  |**||<-- cpu_power_domain
+ +--+--+|
+|   |
+|   |
+   

Re: [PATCH v10 02/10] doc: Add documentation for Coresight CPU debug

2017-05-22 Thread Leo Yan
On Mon, May 22, 2017 at 11:16:00AM +0100, Liviu Dudau wrote:
> On Fri, May 19, 2017 at 12:25:49PM +0800, Leo Yan wrote:
> > Add detailed documentation for Coresight CPU debug driver, which
> > contains the info for driver implementation, Mike Leach excellent
> > summary for "clock and power domain". At the end some examples on how
> > to enable the debugging functionality are provided.
> 
> Hi Leo,
> 
> Below are my minor suggestions to improve readability of the documentation.

Thanks, Liviu. Accept all suggestions and will spin a new version.

[...]

Thanks,
Leo Yan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v10 04/10] MAINTAINERS: update file entries for Coresight subsystem

2017-05-18 Thread Leo Yan
Update document file entries for Coresight debug module.

Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f7d568b..d443258 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1208,7 +1208,9 @@ L:linux-arm-ker...@lists.infradead.org (moderated 
for non-subscribers)
 S: Maintained
 F: drivers/hwtracing/coresight/*
 F: Documentation/trace/coresight.txt
+F: Documentation/trace/coresight-cpu-debug.txt
 F: Documentation/devicetree/bindings/arm/coresight.txt
+F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
 F: Documentation/ABI/testing/sysfs-bus-coresight-devices-*
 F: tools/perf/arch/arm/util/pmu.c
 F: tools/perf/arch/arm/util/auxtrace.c
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v10 06/10] coresight: refactor with function of_coresight_get_cpu

2017-05-18 Thread Leo Yan
This is refactor to add function of_coresight_get_cpu(), so it's used to
retrieve CPU id for coresight component. Finally can use it as a common
function for multiple places.

Suggested-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/of_coresight.c | 43 +++---
 include/linux/coresight.h  |  3 +++
 2 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/drivers/hwtracing/coresight/of_coresight.c 
b/drivers/hwtracing/coresight/of_coresight.c
index 225b2dd..a187941 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -101,16 +101,40 @@ static int of_coresight_alloc_memory(struct device *dev,
return 0;
 }
 
+int of_coresight_get_cpu(const struct device_node *node)
+{
+   int cpu;
+   bool found;
+   struct device_node *dn, *np;
+
+   dn = of_parse_phandle(node, "cpu", 0);
+
+   /* Affinity defaults to CPU0 */
+   if (!dn)
+   return 0;
+
+   for_each_possible_cpu(cpu) {
+   np = of_cpu_device_node_get(cpu);
+   found = (dn == np);
+   of_node_put(np);
+   if (found)
+   break;
+   }
+   of_node_put(dn);
+
+   /* Affinity to CPU0 if no cpu nodes are found */
+   return found ? cpu : 0;
+}
+EXPORT_SYMBOL_GPL(of_coresight_get_cpu);
+
 struct coresight_platform_data *
 of_get_coresight_platform_data(struct device *dev,
   const struct device_node *node)
 {
-   int i = 0, ret = 0, cpu;
+   int i = 0, ret = 0;
struct coresight_platform_data *pdata;
struct of_endpoint endpoint, rendpoint;
struct device *rdev;
-   bool found;
-   struct device_node *dn, *np;
struct device_node *ep = NULL;
struct device_node *rparent = NULL;
struct device_node *rport = NULL;
@@ -177,18 +201,7 @@ of_get_coresight_platform_data(struct device *dev,
} while (ep);
}
 
-   dn = of_parse_phandle(node, "cpu", 0);
-   for_each_possible_cpu(cpu) {
-   np = of_cpu_device_node_get(cpu);
-   found = (dn == np);
-   of_node_put(np);
-   if (found)
-   break;
-   }
-   of_node_put(dn);
-
-   /* Affinity to CPU0 if no cpu nodes are found */
-   pdata->cpu = found ? cpu : 0;
+   pdata->cpu = of_coresight_get_cpu(node);
 
return pdata;
 }
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index bf0aa50..d950dad 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -263,10 +263,13 @@ static inline int coresight_timeout(void __iomem *addr, 
u32 offset,
 #endif
 
 #ifdef CONFIG_OF
+extern int of_coresight_get_cpu(const struct device_node *node);
 extern struct coresight_platform_data *
 of_get_coresight_platform_data(struct device *dev,
   const struct device_node *node);
 #else
+static inline int of_coresight_get_cpu(const struct device_node *node)
+{ return 0; }
 static inline struct coresight_platform_data *of_get_coresight_platform_data(
struct device *dev, const struct device_node *node) { return NULL; }
 #endif
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v10 10/10] arm64: dts: juno: Add Coresight CPU debug nodes

2017-05-18 Thread Leo Yan
From: Suzuki K Poulose <suzuki.poul...@arm.com>

Add Coresight CPU debug nodes for Juno r0, r1 & r2. The CPU
debug areas are mapped at the same address for all revisions,
like the ETM, even though the CPUs have changed from r1 to r2.

Cc: Sudeep Holla <sudeep.ho...@arm.com>
Cc: Leo Yan <leo@linaro.org>
Cc: Mathieu Poirier <mathieu.por...@linaro.org>
Cc: Liviu Dudau <liviu.du...@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poul...@arm.com>
---
 arch/arm64/boot/dts/arm/juno-base.dtsi | 54 ++
 arch/arm64/boot/dts/arm/juno-r1.dts| 24 +++
 arch/arm64/boot/dts/arm/juno-r2.dts| 24 +++
 arch/arm64/boot/dts/arm/juno.dts   | 24 +++
 4 files changed, 126 insertions(+)

diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi 
b/arch/arm64/boot/dts/arm/juno-base.dtsi
index bfe7d68..784a80a 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -216,6 +216,15 @@
};
};
 
+   cpu_debug0: cpu_debug@2201 {
+   compatible = "arm,coresight-cpu-debug", "arm,primecell";
+   reg = <0 0x2201 0 0x1000>;
+
+   clocks = <_smc50mhz>;
+   clock-names = "apb_pclk";
+   power-domains = <_devpd 0>;
+   };
+
funnel@220c { /* cluster0 funnel */
compatible = "arm,coresight-funnel", "arm,primecell";
reg = <0 0x220c 0 0x1000>;
@@ -266,6 +275,15 @@
};
};
 
+   cpu_debug1: cpu_debug@2211 {
+   compatible = "arm,coresight-cpu-debug", "arm,primecell";
+   reg = <0 0x2211 0 0x1000>;
+
+   clocks = <_smc50mhz>;
+   clock-names = "apb_pclk";
+   power-domains = <_devpd 0>;
+   };
+
etm2: etm@2304 {
compatible = "arm,coresight-etm4x", "arm,primecell";
reg = <0 0x2304 0 0x1000>;
@@ -280,6 +298,15 @@
};
};
 
+   cpu_debug2: cpu_debug@2301 {
+   compatible = "arm,coresight-cpu-debug", "arm,primecell";
+   reg = <0 0x2301 0 0x1000>;
+
+   clocks = <_smc50mhz>;
+   clock-names = "apb_pclk";
+   power-domains = <_devpd 0>;
+   };
+
funnel@230c { /* cluster1 funnel */
compatible = "arm,coresight-funnel", "arm,primecell";
reg = <0 0x230c 0 0x1000>;
@@ -344,6 +371,15 @@
};
};
 
+   cpu_debug3: cpu_debug@2311 {
+   compatible = "arm,coresight-cpu-debug", "arm,primecell";
+   reg = <0 0x2311 0 0x1000>;
+
+   clocks = <_smc50mhz>;
+   clock-names = "apb_pclk";
+   power-domains = <_devpd 0>;
+   };
+
etm4: etm@2324 {
compatible = "arm,coresight-etm4x", "arm,primecell";
reg = <0 0x2324 0 0x1000>;
@@ -358,6 +394,15 @@
};
};
 
+   cpu_debug4: cpu_debug@2321 {
+   compatible = "arm,coresight-cpu-debug", "arm,primecell";
+   reg = <0 0x2321 0 0x1000>;
+
+   clocks = <_smc50mhz>;
+   clock-names = "apb_pclk";
+   power-domains = <_devpd 0>;
+   };
+
etm5: etm@2334 {
compatible = "arm,coresight-etm4x", "arm,primecell";
reg = <0 0x2334 0 0x1000>;
@@ -372,6 +417,15 @@
};
};
 
+   cpu_debug5: cpu_debug@2331 {
+   compatible = "arm,coresight-cpu-debug", "arm,primecell";
+   reg = <0 0x2331 0 0x1000>;
+
+   clocks = <_smc50mhz>;
+   clock-names = "apb_pclk";
+   power-domains = <_devpd 0>;
+   };
+
replicator@2012 {
compatible = "qcom,coresight-replicator1x", "arm,primecell";
reg = <0 0x2012 0 0x1000>;
diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts 
b/arch/arm64/boot/dts/arm/juno-r1.dts
index 0e8943a..aed6389 100644
--- a/arch/arm64/boot/dts/arm/juno-r1.dts
+++ b/arch/arm64/boot/dts/arm/juno-r1.dts
@@ -281,3 +281,27 @@
 _out_port {
remote-endpoint = <_funnel_in_port0>;
 };
+
+_debug0 {
+   cpu = <_0>;
+};
+
+_debug1 {
+   cpu = <_1>;
+};
+
+_debug2 {
+   cpu = <_0>;
+};
+
+_debug3 {
+   cpu = <_1>;
+};
+
+_debug4 {
+   cpu = <_2>;
+}

[PATCH v10 09/10] arm64: dts: qcom: msm8916: Add debug unit

2017-05-18 Thread Leo Yan
Add debug unit on Qualcomm msm8916 based platforms, including the
DragonBoard 410c board.

Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index ab30939..17691ab 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -1116,6 +1116,38 @@
};
};
 
+   debug@85 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x85 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@852000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x852000 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@854000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x854000 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@856000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x856000 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
etm@85c000 {
compatible = "arm,coresight-etm4x", "arm,primecell";
reg = <0x85c000 0x1000>;
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v10 08/10] arm64: dts: hi6220: register debug module

2017-05-18 Thread Leo Yan
Bind debug module driver for Hi6220.

Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 64 +++
 1 file changed, 64 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 1e5129b..21805b9 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -916,5 +916,69 @@
};
};
};
+
+   debug@f659 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf659 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f6592000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf6592000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f6594000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf6594000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f6596000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf6596000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d2000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d2000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d4000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d4000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d6000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d6000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
};
 };
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v10 07/10] coresight: add support for CPU debug module

2017-05-18 Thread Leo Yan
Coresight includes debug module and usually the module connects with CPU
debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has
description for related info in "Part H: External Debug".

Chapter H7 "The Sample-based Profiling Extension" introduces several
sampling registers, e.g. we can check program counter value with
combined CPU exception level, secure state, etc. So this is helpful for
analysis CPU lockup scenarios, e.g. if one CPU has run into infinite
loop with IRQ disabled. In this case the CPU cannot switch context and
handle any interrupt (including IPIs), as the result it cannot handle
SMP call for stack dump.

This patch is to enable coresight debug module, so firstly this driver
is to bind apb clock for debug module and this is to ensure the debug
module can be accessed from program or external debugger. And the driver
uses sample-based registers for debug purpose, e.g. when system triggers
panic, the driver will dump program counter and combined context
registers (EDCIDSR, EDVIDSR); by parsing context registers so can
quickly get to know CPU secure state, exception level, etc.

Some of the debug module registers are located in CPU power domain, so
this requires the CPU power domain stays on when access related debug
registers, but the power management for CPU power domain is quite
dependent on SoC integration for power management. For the platforms
which with sane power controller implementations, this driver follows
the method to set EDPRCR to try to pull the CPU out of low power state
and then set 'no power down request' bit so the CPU has no chance to
lose power.

If the SoC has not followed up this design well for power management
controller, the user should use the command line parameter or sysfs
to constrain all or partial idle states to ensure the CPU power
domain is enabled and access coresight CPU debug component safely.

Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/Kconfig   |  14 +
 drivers/hwtracing/coresight/Makefile  |   1 +
 drivers/hwtracing/coresight/coresight-cpu-debug.c | 696 ++
 3 files changed, 711 insertions(+)
 create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c

diff --git a/drivers/hwtracing/coresight/Kconfig 
b/drivers/hwtracing/coresight/Kconfig
index 130cb21..8d55d6d 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -89,4 +89,18 @@ config CORESIGHT_STM
  logging useful software events or data coming from various entities
  in the system, possibly running different OSs
 
+config CORESIGHT_CPU_DEBUG
+   tristate "CoreSight CPU Debug driver"
+   depends on ARM || ARM64
+   depends on DEBUG_FS
+   help
+ This driver provides support for coresight debugging module. This
+ is primarily used to dump sample-based profiling registers when
+ system triggers panic, the driver will parse context registers so
+ can quickly get to know program counter (PC), secure state,
+ exception level, etc. Before use debugging functionality, platform
+ needs to ensure the clock domain and power domain are enabled
+ properly, please refer Documentation/trace/coresight-cpu-debug.txt
+ for detailed description and the example for usage.
+
 endif
diff --git a/drivers/hwtracing/coresight/Makefile 
b/drivers/hwtracing/coresight/Makefile
index af480d9..433d590 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
coresight-etm4x-sysfs.o
 obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
 obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
+obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c 
b/drivers/hwtracing/coresight/coresight-cpu-debug.c
new file mode 100644
index 000..3589174
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
@@ -0,0 +1,696 @@
+/*
+ * Copyright (c) 2017 Linaro Limited. All rights reserved.
+ *
+ * Author: Leo Yan <leo@linaro.org>
+ *
+ * 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 published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+#include 
+#include 
+#include 

[PATCH v10 05/10] coresight: of_get_coresight_platform_data: Add missing of_node_put

2017-05-18 Thread Leo Yan
From: Suzuki K Poulose <suzuki.poul...@arm.com>

The of_get_coresight_platform_data iterates over the possible CPU nodes
to find a given cpu phandle. However it does not drop the reference
to the node pointer returned by the of_get_coresight_platform_data.

This patch also introduces another minor fix is to use
of_cpu_device_node_get() to replace of_get_cpu_node().

Cc: Mathieu Poirier <mathieu.poir...@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poul...@arm.com>
[Leo: minor tweaks for of_get_coresight_platform_data]
Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/of_coresight.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/hwtracing/coresight/of_coresight.c 
b/drivers/hwtracing/coresight/of_coresight.c
index 2749853..225b2dd 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -109,7 +109,8 @@ of_get_coresight_platform_data(struct device *dev,
struct coresight_platform_data *pdata;
struct of_endpoint endpoint, rendpoint;
struct device *rdev;
-   struct device_node *dn;
+   bool found;
+   struct device_node *dn, *np;
struct device_node *ep = NULL;
struct device_node *rparent = NULL;
struct device_node *rport = NULL;
@@ -176,17 +177,19 @@ of_get_coresight_platform_data(struct device *dev,
} while (ep);
}
 
-   /* Affinity defaults to CPU0 */
-   pdata->cpu = 0;
dn = of_parse_phandle(node, "cpu", 0);
-   for (cpu = 0; dn && cpu < nr_cpu_ids; cpu++) {
-   if (dn == of_get_cpu_node(cpu, NULL)) {
-   pdata->cpu = cpu;
+   for_each_possible_cpu(cpu) {
+   np = of_cpu_device_node_get(cpu);
+   found = (dn == np);
+   of_node_put(np);
+   if (found)
break;
-   }
}
of_node_put(dn);
 
+   /* Affinity to CPU0 if no cpu nodes are found */
+   pdata->cpu = found ? cpu : 0;
+
return pdata;
 }
 EXPORT_SYMBOL_GPL(of_get_coresight_platform_data);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v10 03/10] doc: Add coresight_cpu_debug.enable to kernel-parameters.txt

2017-05-18 Thread Leo Yan
Add coresight_cpu_debug.enable to kernel-parameters.txt, this flag is
used to enable/disable the CPU sampling based debugging.

Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 Documentation/admin-guide/kernel-parameters.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 15f79c2..ff67ad7 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -649,6 +649,13 @@
/proc//coredump_filter.
See also Documentation/filesystems/proc.txt.
 
+   coresight_cpu_debug.enable
+   [ARM,ARM64]
+   Format: 
+   Enable/disable the CPU sampling based debugging.
+   0: default value, disable debugging
+   1: enable debugging at boot time
+
cpuidle.off=1   [CPU_IDLE]
disable the cpuidle sub-system
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v10 01/10] coresight: bindings for CPU debug module

2017-05-18 Thread Leo Yan
According to ARMv8 architecture reference manual (ARM DDI 0487A.k)
Chapter 'Part H: External debug', the CPU can integrate debug module
and it can support self-hosted debug and external debug. Especially
for supporting self-hosted debug, this means the program can access
the debug module from mmio region; and usually the mmio region is
integrated with coresight.

So add document for binding debug component, includes binding to APB
clock; and also need specify the CPU node which the debug module is
dedicated to specific CPU.

Suggested-by: Mike Leach <mike.le...@linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Acked-by: Rob Herring <r...@kernel.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 .../bindings/arm/coresight-cpu-debug.txt   | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt

diff --git a/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt 
b/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
new file mode 100644
index 000..2982912
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
@@ -0,0 +1,49 @@
+* CoreSight CPU Debug Component:
+
+CoreSight CPU debug component are compliant with the ARMv8 architecture
+reference manual (ARM DDI 0487A.k) Chapter 'Part H: External debug'. The
+external debug module is mainly used for two modes: self-hosted debug and
+external debug, and it can be accessed from mmio region from Coresight
+and eventually the debug module connects with CPU for debugging. And the
+debug module provides sample-based profiling extension, which can be used
+to sample CPU program counter, secure state and exception level, etc;
+usually every CPU has one dedicated debug module to be connected.
+
+Required properties:
+
+- compatible : should be "arm,coresight-cpu-debug"; supplemented with
+   "arm,primecell" since this driver is using the AMBA bus
+  interface.
+
+- reg : physical base address and length of the register set.
+
+- clocks : the clock associated to this component.
+
+- clock-names : the name of the clock referenced by the code. Since we are
+using the AMBA framework, the name of the clock providing
+   the interconnect should be "apb_pclk" and the clock is
+   mandatory. The interface between the debug logic and the
+   processor core is clocked by the internal CPU clock, so it
+   is enabled with CPU clock by default.
+
+- cpu : the CPU phandle the debug module is affined to. When omitted
+   the module is considered to belong to CPU0.
+
+Optional properties:
+
+- power-domains: a phandle to the debug power domain. We use "power-domains"
+ binding to turn on the debug logic if it has own dedicated
+power domain and if necessary to use "cpuidle.off=1" or
+"nohlt" in the kernel command line or sysfs node to
+constrain idle states to ensure registers in the CPU power
+domain are accessible.
+
+Example:
+
+   debug@f659 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf659 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v10 00/10] coresight: enable debug module

2017-05-18 Thread Leo Yan
e/disable debugging by debugfs.
* According to Rob Herring suggestion, one minor fixes in DT binding.
* According to Stephen Boyd suggestion, add const quality to structure
  device_node. And used use of_cpu_device_node_get() to replace
  of_get_cpu_node() in patch 0003.

Changes from v3:
* Added Suzuki K Poulose's patch to fix issue for the func
  of_get_coresight_platform_data() doesn't properly drop the reference
  to the CPU node pointer.
* According to Suzuki suggestion, added code to handl the corner case
  for ARMv8 CPU with aarch32 mode.
* According to Suzuki suggestion, changed compatible string to
  "arm,coresight-cpu-debug".
* According to Mathieu suggestion, added "power-domains" as optional
  properties.

Changes from v2:
* According to Mathieu Poirier suggestion, applied some minor fixes.
* Added two extra patches for enabling debug module on Hikey.

Changes from v1:
* According to Mike Leach suggestion, removed the binding for debug
  module clocks which have been directly provided by CPU clocks.
* According to Mathieu Poirier suggestion, added function
  of_coresight_get_cpu() and some minor refactors for debug module
  driver.

Changes from RFC:
* According to Mike Leach suggestion, added check for EDPRSR to avoid
  lockup; added supporting EDVIDSR and EDCIDSR registers.
* According to Mark Rutland and Mathieu Poirier suggestion, rewrote
  the documentation for DT binding.
* According to Mark and Mathieu suggestion, refined debug driver.

Leo Yan (8):
  coresight: bindings for CPU debug module
  doc: Add documentation for Coresight CPU debug
  doc: Add coresight_cpu_debug.enable to kernel-parameters.txt
  MAINTAINERS: update file entries for Coresight subsystem
  coresight: refactor with function of_coresight_get_cpu
  coresight: add support for CPU debug module
  arm64: dts: hi6220: register debug module
  arm64: dts: qcom: msm8916: Add debug unit

Suzuki K Poulose (2):
  coresight: of_get_coresight_platform_data: Add missing of_node_put
  arm64: dts: juno: Add Coresight CPU debug nodes

 Documentation/admin-guide/kernel-parameters.txt|   7 +
 .../bindings/arm/coresight-cpu-debug.txt   |  49 ++
 Documentation/trace/coresight-cpu-debug.txt| 174 ++
 MAINTAINERS|   2 +
 arch/arm64/boot/dts/arm/juno-base.dtsi |  54 ++
 arch/arm64/boot/dts/arm/juno-r1.dts|  24 +
 arch/arm64/boot/dts/arm/juno-r2.dts|  24 +
 arch/arm64/boot/dts/arm/juno.dts   |  24 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |  64 ++
 arch/arm64/boot/dts/qcom/msm8916.dtsi  |  32 +
 drivers/hwtracing/coresight/Kconfig|  14 +
 drivers/hwtracing/coresight/Makefile   |   1 +
 drivers/hwtracing/coresight/coresight-cpu-debug.c  | 696 +
 drivers/hwtracing/coresight/of_coresight.c |  40 +-
 include/linux/coresight.h  |   3 +
 15 files changed, 1196 insertions(+), 12 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
 create mode 100644 Documentation/trace/coresight-cpu-debug.txt
 create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v10 02/10] doc: Add documentation for Coresight CPU debug

2017-05-18 Thread Leo Yan
Add detailed documentation for Coresight CPU debug driver, which
contains the info for driver implementation, Mike Leach excellent
summary for "clock and power domain". At the end some examples on how
to enable the debugging functionality are provided.

Suggested-by: Mike Leach <mike.le...@linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 Documentation/trace/coresight-cpu-debug.txt | 174 
 1 file changed, 174 insertions(+)
 create mode 100644 Documentation/trace/coresight-cpu-debug.txt

diff --git a/Documentation/trace/coresight-cpu-debug.txt 
b/Documentation/trace/coresight-cpu-debug.txt
new file mode 100644
index 000..f0c3f0f
--- /dev/null
+++ b/Documentation/trace/coresight-cpu-debug.txt
@@ -0,0 +1,174 @@
+   Coresight CPU Debug Module
+   ==========
+
+   Author:   Leo Yan <leo@linaro.org>
+   Date: April 5th, 2017
+
+Introduction
+
+
+Coresight CPU debug module is defined in ARMv8-a architecture reference manual
+(ARM DDI 0487A.k) Chapter 'Part H: External debug', the CPU can integrate
+debug module and it is mainly used for two modes: self-hosted debug and
+external debug. Usually the external debug mode is well known as the external
+debugger connects with SoC from JTAG port; on the other hand the program can
+explore debugging method which rely on self-hosted debug mode, this document
+is to focus on this part.
+
+The debug module provides sample-based profiling extension, which can be used
+to sample CPU program counter, secure state and exception level, etc; usually
+every CPU has one dedicated debug module to be connected. Based on self-hosted
+debug mechanism, Linux kernel can access these related registers from mmio
+region when the kernel panic happens. The callback notifier for kernel panic
+will dump related registers for every CPU; finally this is good for assistant
+analysis for panic.
+
+
+Implementation
+--
+
+- During driver registration, use EDDEVID and EDDEVID1 two device ID
+  registers to decide if sample-based profiling is implemented or not. On some
+  platforms this hardware feature is fully or partialy implemented; and if
+  this feature is not supported then registration will fail.
+
+- When write this doc, the debug driver mainly relies on three sampling
+  registers. The kernel panic callback notifier gathers info from EDPCSR
+  EDVIDSR and EDCIDSR; from EDPCSR we can get program counter, EDVIDSR has
+  information for secure state, exception level, bit width, etc; EDCIDSR is
+  context ID value which contains the sampled value of CONTEXTIDR_EL1.
+
+- The driver supports CPU running mode with either AArch64 or AArch32. The
+  registers naming convention is a bit different between them, AArch64 uses
+  'ED' for register prefix (ARM DDI 0487A.k, chapter H9.1) and AArch32 uses
+  'DBG' as prefix (ARM DDI 0487A.k, chapter G5.1). The driver is unified to
+  use AArch64 naming convention.
+
+- ARMv8-a (ARM DDI 0487A.k) and ARMv7-a (ARM DDI 0406C.b) have different
+  register bits definition. So the driver consolidates two difference:
+
+  If PCSROffset=0b, on ARMv8-a the feature of EDPCSR is not implemented;
+  but ARMv7-a defines "PCSR samples are offset by a value that depends on the
+  instruction set state". For ARMv7-a, the driver checks furthermore if CPU
+  runs with ARM or thumb instruction set and calibrate PCSR value, the
+  detailed description for offset is in ARMv7-a ARM (ARM DDI 0406C.b) chapter
+  C11.11.34 "DBGPCSR, Program Counter Sampling Register".
+
+  If PCSROffset=0b0010, ARMv8-a defines "EDPCSR implemented, and samples have
+  no offset applied and do not sample the instruction set state in AArch32
+  state". So on ARMv8 if EDDEVID1.PCSROffset is 0b0010 and the CPU operates
+  in AArch32 state, EDPCSR is not sampled; when the CPU operates in AArch64
+  state EDPCSR is sampled and no offset are applied.
+
+
+Clock and power domain
+--
+
+Before accessing debug registers, we should ensure the clock and power domain
+have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1
+Debug registers', the debug registers are spread into two domains: the debug
+domain and the CPU domain.
+
++---+
+|   |
+|   |
+ +--+--+|
+  dbg_clk -->|  |**||<-- cpu_clk
+ |Debug |**|   CPU  |
+   dbg_pd -->|  |**||<-- cpu_pd
+ +--+--+|
+|   |
+|   |
++---+
+
+For deb

Re: [PATCH v8 2/7] doc: Add documentation for Coresight CPU debug

2017-05-08 Thread Leo Yan
Hi Mathieu,

On Wed, May 03, 2017 at 04:29:37PM -0600, Mathieu Poirier wrote:
> On Tue, May 02, 2017 at 06:08:32PM +0800, Leo Yan wrote:
> > Update kernel-parameters.txt to add new parameter:
> > coresight_cpu_debug.enable is a knob to enable debugging at boot time.
> > 
> > Add detailed documentation, which contains the implementation, Mike
> > Leach excellent summary for "clock and power domain". At the end some
> > examples on how to enable the debugging functionality are provided.
> > 
> > Suggested-by: Mike Leach <mike.le...@linaro.org>
> > Signed-off-by: Leo Yan <leo@linaro.org>
> > ---
> >  Documentation/admin-guide/kernel-parameters.txt |   7 +
> >  Documentation/trace/coresight-cpu-debug.txt | 174 
> > 
> 
> Please add coresight-cpu-debug.txt to the list of maintained files in
> MAINTAINERS.  Moreover I'm pretty sure John will want you to split this patch 
> in
> two, i.e one patch for kernel-parameters.txt and another for
> coresight-cpu-debug.txt

Thanks for the suggestion. Have splited doc related patches and
refined debug module related code as you suggested in another
email and sent out v9 patch set for reviewing.

[...]

Thanks,
Leo Yan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v9 5/9] coresight: of_get_coresight_platform_data: Add missing of_node_put

2017-05-08 Thread Leo Yan
From: Suzuki K Poulose <suzuki.poul...@arm.com>

The of_get_coresight_platform_data iterates over the possible CPU nodes
to find a given cpu phandle. However it does not drop the reference
to the node pointer returned by the of_get_coresight_platform_data.

This patch also introduces another minor fix is to use
of_cpu_device_node_get() to replace of_get_cpu_node().

Cc: Mathieu Poirier <mathieu.poir...@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poul...@arm.com>
[Leo: minor tweaks for of_get_coresight_platform_data]
Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/of_coresight.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/hwtracing/coresight/of_coresight.c 
b/drivers/hwtracing/coresight/of_coresight.c
index 2749853..225b2dd 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -109,7 +109,8 @@ of_get_coresight_platform_data(struct device *dev,
struct coresight_platform_data *pdata;
struct of_endpoint endpoint, rendpoint;
struct device *rdev;
-   struct device_node *dn;
+   bool found;
+   struct device_node *dn, *np;
struct device_node *ep = NULL;
struct device_node *rparent = NULL;
struct device_node *rport = NULL;
@@ -176,17 +177,19 @@ of_get_coresight_platform_data(struct device *dev,
} while (ep);
}
 
-   /* Affinity defaults to CPU0 */
-   pdata->cpu = 0;
dn = of_parse_phandle(node, "cpu", 0);
-   for (cpu = 0; dn && cpu < nr_cpu_ids; cpu++) {
-   if (dn == of_get_cpu_node(cpu, NULL)) {
-   pdata->cpu = cpu;
+   for_each_possible_cpu(cpu) {
+   np = of_cpu_device_node_get(cpu);
+   found = (dn == np);
+   of_node_put(np);
+   if (found)
break;
-   }
}
of_node_put(dn);
 
+   /* Affinity to CPU0 if no cpu nodes are found */
+   pdata->cpu = found ? cpu : 0;
+
return pdata;
 }
 EXPORT_SYMBOL_GPL(of_get_coresight_platform_data);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v9 4/9] MAINTAINERS: update file entries for Coresight subsystem

2017-05-08 Thread Leo Yan
Update document file entries for Coresight debug module.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b948dfa..a4b1f60 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1191,7 +1191,9 @@ L:linux-arm-ker...@lists.infradead.org (moderated 
for non-subscribers)
 S: Maintained
 F: drivers/hwtracing/coresight/*
 F: Documentation/trace/coresight.txt
+F: Documentation/trace/coresight-cpu-debug.txt
 F: Documentation/devicetree/bindings/arm/coresight.txt
+F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
 F: Documentation/ABI/testing/sysfs-bus-coresight-devices-*
 F: tools/perf/arch/arm/util/pmu.c
 F: tools/perf/arch/arm/util/auxtrace.c
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v9 0/9] coresight: enable debug module

2017-05-08 Thread Leo Yan
 aarch32 mode.
* According to Suzuki suggestion, changed compatible string to
  "arm,coresight-cpu-debug".
* According to Mathieu suggestion, added "power-domains" as optional
  properties.

Changes from v2:
* According to Mathieu Poirier suggestion, applied some minor fixes.
* Added two extra patches for enabling debug module on Hikey.

Changes from v1:
* According to Mike Leach suggestion, removed the binding for debug
  module clocks which have been directly provided by CPU clocks.
* According to Mathieu Poirier suggestion, added function
  of_coresight_get_cpu() and some minor refactors for debug module
  driver.

Changes from RFC:
* According to Mike Leach suggestion, added check for EDPRSR to avoid
  lockup; added supporting EDVIDSR and EDCIDSR registers.
* According to Mark Rutland and Mathieu Poirier suggestion, rewrote
  the documentation for DT binding.
* According to Mark and Mathieu suggestion, refined debug driver.


Leo Yan (8):
  coresight: bindings for CPU debug module
  doc: Add documentation for Coresight CPU debug
  doc: Add coresight_cpu_debug.enable to kernel-parameters.txt
  MAINTAINERS: update file entries for Coresight subsystem
  coresight: refactor with function of_coresight_get_cpu
  coresight: add support for CPU debug module
  arm64: dts: hi6220: register debug module
  arm64: dts: qcom: msm8916: Add debug unit

Suzuki K Poulose (1):
  coresight: of_get_coresight_platform_data: Add missing of_node_put

 Documentation/admin-guide/kernel-parameters.txt|   7 +
 .../bindings/arm/coresight-cpu-debug.txt   |  49 ++
 Documentation/trace/coresight-cpu-debug.txt| 174 ++
 MAINTAINERS|   2 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |  64 ++
 arch/arm64/boot/dts/qcom/msm8916.dtsi  |  32 +
 drivers/hwtracing/coresight/Kconfig|  14 +
 drivers/hwtracing/coresight/Makefile   |   1 +
 drivers/hwtracing/coresight/coresight-cpu-debug.c  | 693 +
 drivers/hwtracing/coresight/of_coresight.c |  40 +-
 include/linux/coresight.h  |   3 +
 11 files changed, 1067 insertions(+), 12 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
 create mode 100644 Documentation/trace/coresight-cpu-debug.txt
 create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v9 9/9] arm64: dts: qcom: msm8916: Add debug unit

2017-05-08 Thread Leo Yan
Add debug unit on Qualcomm msm8916 based platforms, including the
DragonBoard 410c board.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 68a8e67..3af814b 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -1104,6 +1104,38 @@
};
};
 
+   debug@85 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x85 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@852000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x852000 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@854000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x854000 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@856000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x856000 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
etm@85c000 {
compatible = "arm,coresight-etm4x", "arm,primecell";
reg = <0x85c000 0x1000>;
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v9 7/9] coresight: add support for CPU debug module

2017-05-08 Thread Leo Yan
Coresight includes debug module and usually the module connects with CPU
debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has
description for related info in "Part H: External Debug".

Chapter H7 "The Sample-based Profiling Extension" introduces several
sampling registers, e.g. we can check program counter value with
combined CPU exception level, secure state, etc. So this is helpful for
analysis CPU lockup scenarios, e.g. if one CPU has run into infinite
loop with IRQ disabled. In this case the CPU cannot switch context and
handle any interrupt (including IPIs), as the result it cannot handle
SMP call for stack dump.

This patch is to enable coresight debug module, so firstly this driver
is to bind apb clock for debug module and this is to ensure the debug
module can be accessed from program or external debugger. And the driver
uses sample-based registers for debug purpose, e.g. when system triggers
panic, the driver will dump program counter and combined context
registers (EDCIDSR, EDVIDSR); by parsing context registers so can
quickly get to know CPU secure state, exception level, etc.

Some of the debug module registers are located in CPU power domain, so
this requires the CPU power domain stays on when access related debug
registers, but the power management for CPU power domain is quite
dependent on SoC integration for power management. For the platforms
which with sane power controller implementations, this driver follows
the method to set EDPRCR to try to pull the CPU out of low power state
and then set 'no power down request' bit so the CPU has no chance to
lose power.

If the SoC has not followed up this design well for power management
controller, the user should use the command line parameter or sysfs
to constrain all or partial idle states to ensure the CPU power
domain is enabled and access coresight CPU debug component safely.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/Kconfig   |  14 +
 drivers/hwtracing/coresight/Makefile  |   1 +
 drivers/hwtracing/coresight/coresight-cpu-debug.c | 693 ++
 3 files changed, 708 insertions(+)
 create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c

diff --git a/drivers/hwtracing/coresight/Kconfig 
b/drivers/hwtracing/coresight/Kconfig
index 130cb21..8d55d6d 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -89,4 +89,18 @@ config CORESIGHT_STM
  logging useful software events or data coming from various entities
  in the system, possibly running different OSs
 
+config CORESIGHT_CPU_DEBUG
+   tristate "CoreSight CPU Debug driver"
+   depends on ARM || ARM64
+   depends on DEBUG_FS
+   help
+ This driver provides support for coresight debugging module. This
+ is primarily used to dump sample-based profiling registers when
+ system triggers panic, the driver will parse context registers so
+ can quickly get to know program counter (PC), secure state,
+ exception level, etc. Before use debugging functionality, platform
+ needs to ensure the clock domain and power domain are enabled
+ properly, please refer Documentation/trace/coresight-cpu-debug.txt
+ for detailed description and the example for usage.
+
 endif
diff --git a/drivers/hwtracing/coresight/Makefile 
b/drivers/hwtracing/coresight/Makefile
index af480d9..433d590 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
coresight-etm4x-sysfs.o
 obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
 obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
+obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c 
b/drivers/hwtracing/coresight/coresight-cpu-debug.c
new file mode 100644
index 000..ab12ec1
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
@@ -0,0 +1,693 @@
+/*
+ * Copyright (c) 2017 Linaro Limited. All rights reserved.
+ *
+ * Author: Leo Yan <leo@linaro.org>
+ *
+ * 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 published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#inc

[PATCH v9 8/9] arm64: dts: hi6220: register debug module

2017-05-08 Thread Leo Yan
Bind debug module driver for Hi6220.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 64 +++
 1 file changed, 64 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 470461d..467aa15 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -913,5 +913,69 @@
};
};
};
+
+   debug@f659 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf659 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f6592000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf6592000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f6594000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf6594000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f6596000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf6596000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d2000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d2000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d4000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d4000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d6000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d6000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
};
 };
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v9 6/9] coresight: refactor with function of_coresight_get_cpu

2017-05-08 Thread Leo Yan
This is refactor to add function of_coresight_get_cpu(), so it's used to
retrieve CPU id for coresight component. Finally can use it as a common
function for multiple places.

Suggested-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/of_coresight.c | 43 +++---
 include/linux/coresight.h  |  3 +++
 2 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/drivers/hwtracing/coresight/of_coresight.c 
b/drivers/hwtracing/coresight/of_coresight.c
index 225b2dd..a187941 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -101,16 +101,40 @@ static int of_coresight_alloc_memory(struct device *dev,
return 0;
 }
 
+int of_coresight_get_cpu(const struct device_node *node)
+{
+   int cpu;
+   bool found;
+   struct device_node *dn, *np;
+
+   dn = of_parse_phandle(node, "cpu", 0);
+
+   /* Affinity defaults to CPU0 */
+   if (!dn)
+   return 0;
+
+   for_each_possible_cpu(cpu) {
+   np = of_cpu_device_node_get(cpu);
+   found = (dn == np);
+   of_node_put(np);
+   if (found)
+   break;
+   }
+   of_node_put(dn);
+
+   /* Affinity to CPU0 if no cpu nodes are found */
+   return found ? cpu : 0;
+}
+EXPORT_SYMBOL_GPL(of_coresight_get_cpu);
+
 struct coresight_platform_data *
 of_get_coresight_platform_data(struct device *dev,
   const struct device_node *node)
 {
-   int i = 0, ret = 0, cpu;
+   int i = 0, ret = 0;
struct coresight_platform_data *pdata;
struct of_endpoint endpoint, rendpoint;
struct device *rdev;
-   bool found;
-   struct device_node *dn, *np;
struct device_node *ep = NULL;
struct device_node *rparent = NULL;
struct device_node *rport = NULL;
@@ -177,18 +201,7 @@ of_get_coresight_platform_data(struct device *dev,
} while (ep);
}
 
-   dn = of_parse_phandle(node, "cpu", 0);
-   for_each_possible_cpu(cpu) {
-   np = of_cpu_device_node_get(cpu);
-   found = (dn == np);
-   of_node_put(np);
-   if (found)
-   break;
-   }
-   of_node_put(dn);
-
-   /* Affinity to CPU0 if no cpu nodes are found */
-   pdata->cpu = found ? cpu : 0;
+   pdata->cpu = of_coresight_get_cpu(node);
 
return pdata;
 }
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index bf0aa50..d950dad 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -263,10 +263,13 @@ static inline int coresight_timeout(void __iomem *addr, 
u32 offset,
 #endif
 
 #ifdef CONFIG_OF
+extern int of_coresight_get_cpu(const struct device_node *node);
 extern struct coresight_platform_data *
 of_get_coresight_platform_data(struct device *dev,
   const struct device_node *node);
 #else
+static inline int of_coresight_get_cpu(const struct device_node *node)
+{ return 0; }
 static inline struct coresight_platform_data *of_get_coresight_platform_data(
struct device *dev, const struct device_node *node) { return NULL; }
 #endif
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v9 3/9] doc: Add coresight_cpu_debug.enable to kernel-parameters.txt

2017-05-08 Thread Leo Yan
Add coresight_cpu_debug.enable to kernel-parameters.txt, this flag is
used to enable/disable the CPU sampling based debugging.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 Documentation/admin-guide/kernel-parameters.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index e4c9e0e..010ae02 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -649,6 +649,13 @@
/proc//coredump_filter.
See also Documentation/filesystems/proc.txt.
 
+   coresight_cpu_debug.enable
+   [ARM,ARM64]
+   Format: 
+   Enable/disable the CPU sampling based debugging.
+   0: default value, disable debugging
+   1: enable debugging at boot time
+
cpuidle.off=1   [CPU_IDLE]
disable the cpuidle sub-system
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v9 2/9] doc: Add documentation for Coresight CPU debug

2017-05-08 Thread Leo Yan
Add detailed documentation for Coresight CPU debug driver, which
contains the info for driver implementation, Mike Leach excellent
summary for "clock and power domain". At the end some examples on how
to enable the debugging functionality are provided.

Suggested-by: Mike Leach <mike.le...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 Documentation/trace/coresight-cpu-debug.txt | 174 
 1 file changed, 174 insertions(+)
 create mode 100644 Documentation/trace/coresight-cpu-debug.txt

diff --git a/Documentation/trace/coresight-cpu-debug.txt 
b/Documentation/trace/coresight-cpu-debug.txt
new file mode 100644
index 000..0426d50
--- /dev/null
+++ b/Documentation/trace/coresight-cpu-debug.txt
@@ -0,0 +1,174 @@
+   Coresight CPU Debug Module
+   ======
+
+   Author:   Leo Yan <leo@linaro.org>
+   Date: April 5th, 2017
+
+Introduction
+
+
+Coresight CPU debug module is defined in ARMv8-a architecture reference manual
+(ARM DDI 0487A.k) Chapter 'Part H: External debug', the CPU can integrate
+debug module and it is mainly used for two modes: self-hosted debug and
+external debug. Usually the external debug mode is well known as the external
+debugger connects with SoC from JTAG port; on the other hand the program can
+explore debugging method which rely on self-hosted debug mode, this document
+is to focus on this part.
+
+The debug module provides sample-based profiling extension, which can be used
+to sample CPU program counter, secure state and exception level, etc; usually
+every CPU has one dedicated debug module to be connected. Based on self-hosted
+debug mechanism, Linux kernel can access these related registers from mmio
+region when the kernel panic happens. The callback notifier for kernel panic
+will dump related registers for every CPU; finally this is good for assistant
+analysis for panic.
+
+
+Implementation
+--
+
+- During driver registration, use EDDEVID and EDDEVID1 two device ID
+  registers to decide if sample-based profiling is implemented or not. On some
+  platforms this hardware feature is fully or partialy implemented; and if
+  this feature is not supported then registration will fail.
+
+- When write this doc, the debug driver mainly relies on three sampling
+  registers. The kernel panic callback notifier gathers info from EDPCSR
+  EDVIDSR and EDCIDSR; from EDPCSR we can get program counter, EDVIDSR has
+  information for secure state, exception level, bit width, etc; EDCIDSR is
+  context ID value which contains the sampled value of CONTEXTIDR_EL1.
+
+- The driver supports CPU running mode with either AArch64 or AArch32. The
+  registers naming convention is a bit different between them, AArch64 uses
+  'ED' for register prefix (ARM DDI 0487A.k, chapter H9.1) and AArch32 uses
+  'DBG' as prefix (ARM DDI 0487A.k, chapter G5.1). The driver is unified to
+  use AArch64 naming convention.
+
+- ARMv8-a (ARM DDI 0487A.k) and ARMv7-a (ARM DDI 0406C.b) have different
+  register bits definition. So the driver consolidates two difference:
+
+  If PCSROffset=0b, on ARMv8-a the feature of EDPCSR is not implemented;
+  but ARMv7-a defines "PCSR samples are offset by a value that depends on the
+  instruction set state". For ARMv7-a, the driver checks furthermore if CPU
+  runs with ARM or thumb instruction set and calibrate PCSR value, the
+  detailed description for offset is in ARMv7-a ARM (ARM DDI 0406C.b) chapter
+  C11.11.34 "DBGPCSR, Program Counter Sampling Register".
+
+  If PCSROffset=0b0010, ARMv8-a defines "EDPCSR implemented, and samples have
+  no offset applied and do not sample the instruction set state in AArch32
+  state". So on ARMv8 if EDDEVID1.PCSROffset is 0b0010 and the CPU operates
+  in AArch32 state, EDPCSR is not sampled; when the CPU operates in AArch64
+  state EDPCSR is sampled and no offset are applied.
+
+
+Clock and power domain
+--
+
+Before accessing debug registers, we should ensure the clock and power domain
+have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1
+Debug registers', the debug registers are spread into two domains: the debug
+domain and the CPU domain.
+
++---+
+|   |
+|   |
+ +--+--+|
+  dbg_clk -->|  |**||<-- cpu_clk
+ |Debug |**|   CPU  |
+   dbg_pd -->|  |**||<-- cpu_pd
+ +--+--+|
+|   |
+|   |
++---+
+
+For debug domain, the user uses DT binding "clocks" and "power-dom

[PATCH v9 1/9] coresight: bindings for CPU debug module

2017-05-08 Thread Leo Yan
According to ARMv8 architecture reference manual (ARM DDI 0487A.k)
Chapter 'Part H: External debug', the CPU can integrate debug module
and it can support self-hosted debug and external debug. Especially
for supporting self-hosted debug, this means the program can access
the debug module from mmio region; and usually the mmio region is
integrated with coresight.

So add document for binding debug component, includes binding to APB
clock; and also need specify the CPU node which the debug module is
dedicated to specific CPU.

Suggested-by: Mike Leach <mike.le...@linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Acked-by: Rob Herring <r...@kernel.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 .../bindings/arm/coresight-cpu-debug.txt   | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt

diff --git a/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt 
b/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
new file mode 100644
index 000..2982912
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
@@ -0,0 +1,49 @@
+* CoreSight CPU Debug Component:
+
+CoreSight CPU debug component are compliant with the ARMv8 architecture
+reference manual (ARM DDI 0487A.k) Chapter 'Part H: External debug'. The
+external debug module is mainly used for two modes: self-hosted debug and
+external debug, and it can be accessed from mmio region from Coresight
+and eventually the debug module connects with CPU for debugging. And the
+debug module provides sample-based profiling extension, which can be used
+to sample CPU program counter, secure state and exception level, etc;
+usually every CPU has one dedicated debug module to be connected.
+
+Required properties:
+
+- compatible : should be "arm,coresight-cpu-debug"; supplemented with
+   "arm,primecell" since this driver is using the AMBA bus
+  interface.
+
+- reg : physical base address and length of the register set.
+
+- clocks : the clock associated to this component.
+
+- clock-names : the name of the clock referenced by the code. Since we are
+using the AMBA framework, the name of the clock providing
+   the interconnect should be "apb_pclk" and the clock is
+   mandatory. The interface between the debug logic and the
+   processor core is clocked by the internal CPU clock, so it
+   is enabled with CPU clock by default.
+
+- cpu : the CPU phandle the debug module is affined to. When omitted
+   the module is considered to belong to CPU0.
+
+Optional properties:
+
+- power-domains: a phandle to the debug power domain. We use "power-domains"
+ binding to turn on the debug logic if it has own dedicated
+power domain and if necessary to use "cpuidle.off=1" or
+"nohlt" in the kernel command line or sysfs node to
+constrain idle states to ensure registers in the CPU power
+domain are accessible.
+
+Example:
+
+   debug@f659 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf659 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v8 4/7] coresight: refactor with function of_coresight_get_cpu

2017-05-02 Thread Leo Yan
This is refactor to add function of_coresight_get_cpu(), so it's used to
retrieve CPU id for coresight component. Finally can use it as a common
function for multiple places.

Suggested-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/of_coresight.c | 43 +++---
 include/linux/coresight.h  |  2 ++
 2 files changed, 30 insertions(+), 15 deletions(-)

diff --git a/drivers/hwtracing/coresight/of_coresight.c 
b/drivers/hwtracing/coresight/of_coresight.c
index de7e8ce..46eec0f 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -101,15 +101,39 @@ static int of_coresight_alloc_memory(struct device *dev,
return 0;
 }
 
+int of_coresight_get_cpu(const struct device_node *node)
+{
+   int cpu;
+   bool found;
+   struct device_node *dn, *np;
+
+   dn = of_parse_phandle(node, "cpu", 0);
+
+   /* Affinity defaults to CPU0 */
+   if (!dn)
+   return 0;
+
+   for_each_possible_cpu(cpu) {
+   np = of_cpu_device_node_get(cpu);
+   found = (dn == np);
+   of_node_put(np);
+   if (found)
+   break;
+   }
+   of_node_put(dn);
+
+   /* Affinity to CPU0 if no cpu nodes are found */
+   return found ? cpu : 0;
+}
+EXPORT_SYMBOL_GPL(of_coresight_get_cpu);
+
 struct coresight_platform_data *of_get_coresight_platform_data(
struct device *dev, const struct device_node *node)
 {
-   int i = 0, ret = 0, cpu;
+   int i = 0, ret = 0;
struct coresight_platform_data *pdata;
struct of_endpoint endpoint, rendpoint;
struct device *rdev;
-   bool found;
-   struct device_node *dn, *np;
struct device_node *ep = NULL;
struct device_node *rparent = NULL;
struct device_node *rport = NULL;
@@ -176,18 +200,7 @@ struct coresight_platform_data 
*of_get_coresight_platform_data(
} while (ep);
}
 
-   dn = of_parse_phandle(node, "cpu", 0);
-   for_each_possible_cpu(cpu) {
-   np = of_cpu_device_node_get(cpu);
-   found = (dn == np);
-   of_node_put(np);
-   if (found)
-   break;
-   }
-   of_node_put(dn);
-
-   /* Affinity to CPU0 if no cpu nodes are found */
-   pdata->cpu = found ? cpu : 0;
+   pdata->cpu = of_coresight_get_cpu(node);
 
return pdata;
 }
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 769f2c8..4915254 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -263,9 +263,11 @@ static inline int coresight_timeout(void __iomem *addr, 
u32 offset,
 #endif
 
 #ifdef CONFIG_OF
+extern int of_coresight_get_cpu(const struct device_node *node);
 extern struct coresight_platform_data *of_get_coresight_platform_data(
struct device *dev, const struct device_node *node);
 #else
+static inline int of_coresight_get_cpu(const struct device_node *node) { 
return 0; }
 static inline struct coresight_platform_data *of_get_coresight_platform_data(
struct device *dev, const struct device_node *node) { return NULL; }
 #endif
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v8 6/7] arm64: dts: hi6220: register debug module

2017-05-02 Thread Leo Yan
Bind debug module driver for Hi6220.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 64 +++
 1 file changed, 64 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 470461d..467aa15 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -913,5 +913,69 @@
};
};
};
+
+   debug@f659 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf659 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f6592000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf6592000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f6594000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf6594000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f6596000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf6596000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d2000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d2000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d4000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d4000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@f65d6000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf65d6000 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
};
 };
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v8 1/7] coresight: bindings for CPU debug module

2017-05-02 Thread Leo Yan
According to ARMv8 architecture reference manual (ARM DDI 0487A.k)
Chapter 'Part H: External debug', the CPU can integrate debug module
and it can support self-hosted debug and external debug. Especially
for supporting self-hosted debug, this means the program can access
the debug module from mmio region; and usually the mmio region is
integrated with coresight.

So add document for binding debug component, includes binding to APB
clock; and also need specify the CPU node which the debug module is
dedicated to specific CPU.

Suggested-by: Mike Leach <mike.le...@linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Acked-by: Rob Herring <r...@kernel.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 .../bindings/arm/coresight-cpu-debug.txt   | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt

diff --git a/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt 
b/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
new file mode 100644
index 000..2982912
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
@@ -0,0 +1,49 @@
+* CoreSight CPU Debug Component:
+
+CoreSight CPU debug component are compliant with the ARMv8 architecture
+reference manual (ARM DDI 0487A.k) Chapter 'Part H: External debug'. The
+external debug module is mainly used for two modes: self-hosted debug and
+external debug, and it can be accessed from mmio region from Coresight
+and eventually the debug module connects with CPU for debugging. And the
+debug module provides sample-based profiling extension, which can be used
+to sample CPU program counter, secure state and exception level, etc;
+usually every CPU has one dedicated debug module to be connected.
+
+Required properties:
+
+- compatible : should be "arm,coresight-cpu-debug"; supplemented with
+   "arm,primecell" since this driver is using the AMBA bus
+  interface.
+
+- reg : physical base address and length of the register set.
+
+- clocks : the clock associated to this component.
+
+- clock-names : the name of the clock referenced by the code. Since we are
+using the AMBA framework, the name of the clock providing
+   the interconnect should be "apb_pclk" and the clock is
+   mandatory. The interface between the debug logic and the
+   processor core is clocked by the internal CPU clock, so it
+   is enabled with CPU clock by default.
+
+- cpu : the CPU phandle the debug module is affined to. When omitted
+   the module is considered to belong to CPU0.
+
+Optional properties:
+
+- power-domains: a phandle to the debug power domain. We use "power-domains"
+ binding to turn on the debug logic if it has own dedicated
+power domain and if necessary to use "cpuidle.off=1" or
+"nohlt" in the kernel command line or sysfs node to
+constrain idle states to ensure registers in the CPU power
+domain are accessible.
+
+Example:
+
+   debug@f659 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0 0xf659 0 0x1000>;
+   clocks = <_ctrl HI6220_DAPB_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v8 5/7] coresight: add support for CPU debug module

2017-05-02 Thread Leo Yan
Coresight includes debug module and usually the module connects with CPU
debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has
description for related info in "Part H: External Debug".

Chapter H7 "The Sample-based Profiling Extension" introduces several
sampling registers, e.g. we can check program counter value with
combined CPU exception level, secure state, etc. So this is helpful for
analysis CPU lockup scenarios, e.g. if one CPU has run into infinite
loop with IRQ disabled. In this case the CPU cannot switch context and
handle any interrupt (including IPIs), as the result it cannot handle
SMP call for stack dump.

This patch is to enable coresight debug module, so firstly this driver
is to bind apb clock for debug module and this is to ensure the debug
module can be accessed from program or external debugger. And the driver
uses sample-based registers for debug purpose, e.g. when system triggers
panic, the driver will dump program counter and combined context
registers (EDCIDSR, EDVIDSR); by parsing context registers so can
quickly get to know CPU secure state, exception level, etc.

Some of the debug module registers are located in CPU power domain, so
this requires the CPU power domain stays on when access related debug
registers, but the power management for CPU power domain is quite
dependent on SoC integration for power management. For the platforms
which with sane power controller implementations, this driver follows
the method to set EDPRCR to try to pull the CPU out of low power state
and then set 'no power down request' bit so the CPU has no chance to
lose power.

If the SoC has not followed up this design well for power management
controller, the user should use the command line parameter or sysfs
to constrain all or partial idle states to ensure the CPU power
domain is enabled and access coresight CPU debug component safely.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/Kconfig   |  14 +
 drivers/hwtracing/coresight/Makefile  |   1 +
 drivers/hwtracing/coresight/coresight-cpu-debug.c | 670 ++
 3 files changed, 685 insertions(+)
 create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c

diff --git a/drivers/hwtracing/coresight/Kconfig 
b/drivers/hwtracing/coresight/Kconfig
index 130cb21..8d55d6d 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -89,4 +89,18 @@ config CORESIGHT_STM
  logging useful software events or data coming from various entities
  in the system, possibly running different OSs
 
+config CORESIGHT_CPU_DEBUG
+   tristate "CoreSight CPU Debug driver"
+   depends on ARM || ARM64
+   depends on DEBUG_FS
+   help
+ This driver provides support for coresight debugging module. This
+ is primarily used to dump sample-based profiling registers when
+ system triggers panic, the driver will parse context registers so
+ can quickly get to know program counter (PC), secure state,
+ exception level, etc. Before use debugging functionality, platform
+ needs to ensure the clock domain and power domain are enabled
+ properly, please refer Documentation/trace/coresight-cpu-debug.txt
+ for detailed description and the example for usage.
+
 endif
diff --git a/drivers/hwtracing/coresight/Makefile 
b/drivers/hwtracing/coresight/Makefile
index af480d9..433d590 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
coresight-etm4x-sysfs.o
 obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
 obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
+obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c 
b/drivers/hwtracing/coresight/coresight-cpu-debug.c
new file mode 100644
index 000..b77456d
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
@@ -0,0 +1,670 @@
+/*
+ * Copyright (c) 2017 Linaro Limited. All rights reserved.
+ *
+ * Author: Leo Yan <leo@linaro.org>
+ *
+ * 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 published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#inc

[PATCH v8 7/7] arm64: dts: qcom: msm8916: Add debug unit

2017-05-02 Thread Leo Yan
Add debug unit on Qualcomm msm8916 based platforms, including the
DragonBoard 410c board.

Signed-off-by: Leo Yan <leo@linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 68a8e67..3af814b 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -1104,6 +1104,38 @@
};
};
 
+   debug@85 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x85 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@852000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x852000 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@854000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x854000 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@856000 {
+   compatible = "arm,coresight-cpu-debug","arm,primecell";
+   reg = <0x856000 0x1000>;
+   clocks = < RPM_QDSS_CLK>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
etm@85c000 {
compatible = "arm,coresight-etm4x", "arm,primecell";
reg = <0x85c000 0x1000>;
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v8 2/7] doc: Add documentation for Coresight CPU debug

2017-05-02 Thread Leo Yan
Update kernel-parameters.txt to add new parameter:
coresight_cpu_debug.enable is a knob to enable debugging at boot time.

Add detailed documentation, which contains the implementation, Mike
Leach excellent summary for "clock and power domain". At the end some
examples on how to enable the debugging functionality are provided.

Suggested-by: Mike Leach <mike.le...@linaro.org>
Signed-off-by: Leo Yan <leo@linaro.org>
---
 Documentation/admin-guide/kernel-parameters.txt |   7 +
 Documentation/trace/coresight-cpu-debug.txt | 174 
 2 files changed, 181 insertions(+)
 create mode 100644 Documentation/trace/coresight-cpu-debug.txt

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index facc20a..cf90146 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -650,6 +650,13 @@
/proc//coredump_filter.
See also Documentation/filesystems/proc.txt.
 
+   coresight_cpu_debug.enable
+   [ARM,ARM64]
+   Format: 
+   Enable/disable the CPU sampling based debugging.
+   0: default value, disable debugging
+   1: enable debugging at boot time
+
cpuidle.off=1   [CPU_IDLE]
disable the cpuidle sub-system
 
diff --git a/Documentation/trace/coresight-cpu-debug.txt 
b/Documentation/trace/coresight-cpu-debug.txt
new file mode 100644
index 000..0426d50
--- /dev/null
+++ b/Documentation/trace/coresight-cpu-debug.txt
@@ -0,0 +1,174 @@
+   Coresight CPU Debug Module
+   ======
+
+   Author:   Leo Yan <leo@linaro.org>
+   Date: April 5th, 2017
+
+Introduction
+
+
+Coresight CPU debug module is defined in ARMv8-a architecture reference manual
+(ARM DDI 0487A.k) Chapter 'Part H: External debug', the CPU can integrate
+debug module and it is mainly used for two modes: self-hosted debug and
+external debug. Usually the external debug mode is well known as the external
+debugger connects with SoC from JTAG port; on the other hand the program can
+explore debugging method which rely on self-hosted debug mode, this document
+is to focus on this part.
+
+The debug module provides sample-based profiling extension, which can be used
+to sample CPU program counter, secure state and exception level, etc; usually
+every CPU has one dedicated debug module to be connected. Based on self-hosted
+debug mechanism, Linux kernel can access these related registers from mmio
+region when the kernel panic happens. The callback notifier for kernel panic
+will dump related registers for every CPU; finally this is good for assistant
+analysis for panic.
+
+
+Implementation
+--
+
+- During driver registration, use EDDEVID and EDDEVID1 two device ID
+  registers to decide if sample-based profiling is implemented or not. On some
+  platforms this hardware feature is fully or partialy implemented; and if
+  this feature is not supported then registration will fail.
+
+- When write this doc, the debug driver mainly relies on three sampling
+  registers. The kernel panic callback notifier gathers info from EDPCSR
+  EDVIDSR and EDCIDSR; from EDPCSR we can get program counter, EDVIDSR has
+  information for secure state, exception level, bit width, etc; EDCIDSR is
+  context ID value which contains the sampled value of CONTEXTIDR_EL1.
+
+- The driver supports CPU running mode with either AArch64 or AArch32. The
+  registers naming convention is a bit different between them, AArch64 uses
+  'ED' for register prefix (ARM DDI 0487A.k, chapter H9.1) and AArch32 uses
+  'DBG' as prefix (ARM DDI 0487A.k, chapter G5.1). The driver is unified to
+  use AArch64 naming convention.
+
+- ARMv8-a (ARM DDI 0487A.k) and ARMv7-a (ARM DDI 0406C.b) have different
+  register bits definition. So the driver consolidates two difference:
+
+  If PCSROffset=0b, on ARMv8-a the feature of EDPCSR is not implemented;
+  but ARMv7-a defines "PCSR samples are offset by a value that depends on the
+  instruction set state". For ARMv7-a, the driver checks furthermore if CPU
+  runs with ARM or thumb instruction set and calibrate PCSR value, the
+  detailed description for offset is in ARMv7-a ARM (ARM DDI 0406C.b) chapter
+  C11.11.34 "DBGPCSR, Program Counter Sampling Register".
+
+  If PCSROffset=0b0010, ARMv8-a defines "EDPCSR implemented, and samples have
+  no offset applied and do not sample the instruction set state in AArch32
+  state". So on ARMv8 if EDDEVID1.PCSROffset is 0b0010 and the CPU operates
+  in AArch32 state, EDPCSR is not sampled; when the CPU operates in AArch64
+  state EDPCSR is sampled and no offset are applied.
+
+
+Clock and power domain
+--
+
+Before accessing debug registe

[PATCH v8 0/7] coresight: enable debug module

2017-05-02 Thread Leo Yan
y.

Changes from v1:
* According to Mike Leach suggestion, removed the binding for debug
  module clocks which have been directly provided by CPU clocks.
* According to Mathieu Poirier suggestion, added function
  of_coresight_get_cpu() and some minor refactors for debug module
  driver.

Changes from RFC:
* According to Mike Leach suggestion, added check for EDPRSR to avoid
  lockup; added supporting EDVIDSR and EDCIDSR registers.
* According to Mark Rutland and Mathieu Poirier suggestion, rewrote
  the documentation for DT binding.
* According to Mark and Mathieu suggestion, refined debug driver.


Leo Yan (6):
  coresight: bindings for CPU debug module
  doc: Add documentation for Coresight CPU debug
  coresight: refactor with function of_coresight_get_cpu
  coresight: add support for CPU debug module
  arm64: dts: hi6220: register debug module
  arm64: dts: qcom: msm8916: Add debug unit

Suzuki K Poulose (1):
  coresight: of_get_coresight_platform_data: Add missing of_node_put

 Documentation/admin-guide/kernel-parameters.txt|   7 +
 .../bindings/arm/coresight-cpu-debug.txt   |  49 ++
 Documentation/trace/coresight-cpu-debug.txt| 174 ++
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |  64 ++
 arch/arm64/boot/dts/qcom/msm8916.dtsi  |  32 +
 drivers/hwtracing/coresight/Kconfig|  14 +
 drivers/hwtracing/coresight/Makefile   |   1 +
 drivers/hwtracing/coresight/coresight-cpu-debug.c  | 670 +
 drivers/hwtracing/coresight/of_coresight.c |  40 +-
 include/linux/coresight.h  |   2 +
 10 files changed, 1041 insertions(+), 12 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
 create mode 100644 Documentation/trace/coresight-cpu-debug.txt
 create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v8 3/7] coresight: of_get_coresight_platform_data: Add missing of_node_put

2017-05-02 Thread Leo Yan
From: Suzuki K Poulose <suzuki.poul...@arm.com>

The of_get_coresight_platform_data iterates over the possible CPU nodes
to find a given cpu phandle. However it does not drop the reference
to the node pointer returned by the of_get_coresight_platform_data.

This patch also introduces another minor fix is to use
of_cpu_device_node_get() to replace of_get_cpu_node().

Cc: Mathieu Poirier <mathieu.poir...@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poul...@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poul...@arm.com>
[Leo: minor tweaks for of_get_coresight_platform_data]
Signed-off-by: Leo Yan <leo@linaro.org>
---
 drivers/hwtracing/coresight/of_coresight.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/hwtracing/coresight/of_coresight.c 
b/drivers/hwtracing/coresight/of_coresight.c
index 859ad49..de7e8ce 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -108,7 +108,8 @@ struct coresight_platform_data 
*of_get_coresight_platform_data(
struct coresight_platform_data *pdata;
struct of_endpoint endpoint, rendpoint;
struct device *rdev;
-   struct device_node *dn;
+   bool found;
+   struct device_node *dn, *np;
struct device_node *ep = NULL;
struct device_node *rparent = NULL;
struct device_node *rport = NULL;
@@ -175,17 +176,19 @@ struct coresight_platform_data 
*of_get_coresight_platform_data(
} while (ep);
}
 
-   /* Affinity defaults to CPU0 */
-   pdata->cpu = 0;
dn = of_parse_phandle(node, "cpu", 0);
-   for (cpu = 0; dn && cpu < nr_cpu_ids; cpu++) {
-   if (dn == of_get_cpu_node(cpu, NULL)) {
-   pdata->cpu = cpu;
+   for_each_possible_cpu(cpu) {
+   np = of_cpu_device_node_get(cpu);
+   found = (dn == np);
+   of_node_put(np);
+   if (found)
break;
-   }
}
of_node_put(dn);
 
+   /* Affinity to CPU0 if no cpu nodes are found */
+   pdata->cpu = found ? cpu : 0;
+
return pdata;
 }
 EXPORT_SYMBOL_GPL(of_get_coresight_platform_data);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


  1   2   >