* [PATCH 6/9] ARM: dts: wheat: Drop MTD partitioning from DT
From: Simon Horman @ 2018-05-28 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7e1563c3-3e13-235b-3071-c3936502530f@gmail.com>
On Thu, May 24, 2018 at 04:52:59PM +0200, Marek Vasut wrote:
> On 05/23/2018 08:25 AM, Geert Uytterhoeven wrote:
> > Hi Marek,
> >
> > On Wed, May 23, 2018 at 12:01 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
> >> On 05/22/2018 04:43 PM, Geert Uytterhoeven wrote:
> >>> On Tue, May 22, 2018 at 2:02 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>> Drop the MTD partitioning from DT, since it does not describe HW
> >>>> and to give way to a more flexible kernel command line partition
> >>>> passing.
> >>>>
> >>>> To retain the original partitioning, assure you have enabled
> >>>> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
> >>>> following to your kernel command line:
> >>>>
> >>>> mtdparts=spi0.0:256k at 0(loader),4096k(user),-(flash)
> >>>
> >>> I think the "@0" can be dropped, as it's optional?
> >>> 4m?
> >>
> >> My take on this is that the loader is actually at offset 0x0 of the MTD
> >> device and we explicitly state that in the mtdparts to anchor the first
> >> partition within the MTD device and all the other partitions are at
> >> offset +(sum of the sizes of all partitions listed before the current
> >> one) relative to that first partition.
> >
> > Where is this explicitly states for the first partition?
> >
> >> Removing the @0 feels fragile at best and it seems to depend on the
> >> current behavior of the code.
> >
> > Better, it also depends on the documented behavior:
> >
> > Documentation/admin-guide/kernel-parameters.txt refers to
> > drivers/mtd/cmdlinepart.c, which states:
> >
> > * <offset> := standard linux memsize
> > * if omitted the part will immediately follow the previous part
> > * or 0 if the first part
> >
> > None of the examples listed there or under the MTD_CMDLINE_PARTS Kconfig
> > help text, or in a defconfig bundled with the kernel, use @0 for the first
> > partition.
>
> I think this is exceptionally fragile and dangerous to depend on this,
> but so be it.
Could you respin with this change?
I would also like to ask for another change, in light of recent
feedback from Olof Johansson ("Re: [GIT PULL] Renesas ARM64 Based SoC DT
Updates for v4.18").
Please consolidate the dts patches into a single patch?
I have applied the defconfig patch, so there is no need to repost that one.
^ permalink raw reply
* About the DRM Mediatek patches
From: Bibby Hsieh @ 2018-05-28 8:43 UTC (permalink / raw)
To: linux-arm-kernel
Hi, Ulrich,
I found two DRM-Mediatek related patches as below from you.
https://patchwork.kernel.org/patch/10009039/
https://patchwork.kernel.org/patch/10009049/
Did you have any plans to send the new version (There are some comments
from Philipp)? If not, may I send the new version?
Thanks.
--
Bibby
^ permalink raw reply
* [PATCH 06/15] arm: dts: sun: Add missing cooling device properties for CPUs
From: Maxime Ripard @ 2018-05-28 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <eded393f4b508a1f377f9af6859a3b82a6787e1c.1527244201.git.viresh.kumar@linaro.org>
Hi,
On Fri, May 25, 2018 at 04:01:52PM +0530, Viresh Kumar wrote:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
>
> Add such missing properties.
>
> Fix other missing properties (clocks, OPP, clock latency) as well to
> make it all work.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
The prefix should be sunxi and not sun, but it looks good to me
otherwise.
Let me know what your preferred merge method is.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180528/a2bdcdbe/attachment.sig>
^ permalink raw reply
* [RFT v3 0/4] Perf script: Add python script for CoreSight trace disassembler
From: Leo Yan @ 2018-05-28 8:44 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply
* [RFT v3 1/4] perf cs-etm: Generate branch sample for missed packets
From: Leo Yan @ 2018-05-28 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527497103-3593-1-git-send-email-leo.yan@linaro.org>
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.walker@arm.com>
Fixes: e573e978fb12 ("perf cs-etm: Inject capabilitity for CoreSight traces")
Signed-off-by: Leo Yan <leo.yan@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 = &bs->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_executed_instr(etmq->packet);
sample.id = etmq->etm->branches_id;
sample.stream_id = etmq->etm->branches_id;
sample.period = 1;
@@ -897,13 +923,28 @@ 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 ||
+ etmq->prev_packet->sample_type == CS_ETM_TRACE_ON)
+ 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 +963,16 @@ 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_auxtrace *etm = etmq->etm;
struct cs_etm_packet *tmp;
- if (etmq->etm->synth_opts.last_branch &&
- etmq->prev_packet &&
- etmq->prev_packet->sample_type == CS_ETM_RANGE) {
+ if (!etmq->prev_packet)
+ return 0;
+
+ if (etmq->prev_packet->sample_type != CS_ETM_RANGE)
+ return 0;
+
+ if (etmq->etm->synth_opts.last_branch) {
/*
* Generate a last branch event for the branches left in the
* circular buffer at the end of the trace.
@@ -939,18 +985,25 @@ static int cs_etm__flush(struct cs_etm_queue *etmq)
err = cs_etm__synth_instruction_sample(
etmq, addr,
etmq->period_instructions);
+ if (err)
+ return err;
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;
+ if (etm->sample_branches) {
+ err = cs_etm__synth_branch_sample(etmq);
+ if (err)
+ return err;
}
- return err;
+ /*
+ * 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 0;
}
static int cs_etm__run_decoder(struct cs_etm_queue *etmq)
--
2.7.4
^ permalink raw reply related
* [RFT v3 2/4] perf script python: Add addr into perf sample dict
From: Leo Yan @ 2018-05-28 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527497103-3593-1-git-send-email-leo.yan@linaro.org>
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.yan@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
^ permalink raw reply related
* [RFT v3 3/4] perf script python: Add script for CoreSight trace disassembler
From: Leo Yan @ 2018-05-28 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527497103-3593-1-git-send-email-leo.yan@linaro.org>
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 <tor@ti.com>
Co-authored-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Leo Yan <leo.yan@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 0000000..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 <tor@ti.com> is original author who wrote script
+# skeleton, Mathieu Poirier <mathieu.poirier@linaro.org> contributed
+# fixes for build-id and memory map; Leo Yan <leo.yan@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
+ build_ids[id_name] = build_ids[id_name].replace('//', '/', 1)
+
+ if ((options.vmlinux_name == None) and ("[kernel.kallsyms]" in build_ids)):
+ print "kallsyms cannot be used to dump assembler"
+
+ # Set vmlinux path to replace kallsyms file, if without buildid we still
+ # can use vmlinux to prase kernel symbols
+ if ((options.vmlinux_name != None)):
+ build_ids['[kernel.kallsyms]'] = options.vmlinux_name;
+
+def parse_mmap():
+ global mmaps
+
+ # Check mmap for PERF_RECORD_MMAP and PERF_RECORD_MMAP2
+ mmap_regex = "PERF_RECORD_MMAP.* -?[0-9]+/[0-9]+: \[(0x[0-9a-fA-F]+)\((0x[0-9a-fA-F]+)\).*:\s.*\s(\S*)"
+ mmap_re = re.compile(mmap_regex)
+
+ results = check_output("perf script --show-mmap-events | fgrep PERF_RECORD_MMAP", shell=True).split('\n')
+ for line in results:
+ m = mmap_re.search(line)
+ if (m != None):
+ if (m.group(3) == '[kernel.kallsyms]_text'):
+ dso = '[kernel.kallsyms]'
+ else:
+ dso = m.group(3)
+
+ start = int(m.group(1),0)
+ end = int(m.group(1),0) + int(m.group(2),0)
+ mmaps[dso] = [start, end]
+
+def find_dso_mmap(addr):
+ global mmaps
+
+ for key, value in mmaps.items():
+ if (addr >= value[0] and addr < value[1]):
+ return key
+
+ return None
+
+def read_disam(dso, start_addr, stop_addr):
+ global mmaps
+ global build_ids
+
+ addr_range = start_addr + ":" + stop_addr;
+
+ # Don't let the cache get too big, clear it when it hits max size
+ if (len(disasm_cache) > cache_size):
+ disasm_cache.clear();
+
+ try:
+ disasm_output = disasm_cache[addr_range];
+ except:
+ try:
+ fname = build_ids[dso];
+ except KeyError:
+ sys.exit("cannot find symbol file for " + dso)
+
+ disasm = [ options.objdump_name, "-d", "-z",
+ "--start-address="+start_addr,
+ "--stop-address="+stop_addr, fname ]
+
+ disasm_output = check_output(disasm).split('\n')
+ disasm_cache[addr_range] = disasm_output;
+
+ return disasm_output
+
+def dump_disam(dso, start_addr, stop_addr):
+ for line in read_disam(dso, start_addr, stop_addr):
+ m = disasm_func_re.search(line)
+ if (m != None):
+ print "\t",line
+ continue
+
+ m = disasm_re.search(line)
+ if (m == None):
+ continue;
+
+ print "\t",line
+
+def dump_packet(sample):
+ print "Packet = { cpu: 0x%d addr: 0x%x phys_addr: 0x%x ip: 0x%x " \
+ "pid: %d tid: %d period: %d time: %d }" % \
+ (sample['cpu'], sample['addr'], sample['phys_addr'], \
+ sample['ip'], sample['pid'], sample['tid'], \
+ sample['period'], sample['time'])
+
+def trace_begin():
+ print 'ARM CoreSight Trace Data Assembler Dump'
+ parse_buildid()
+ parse_mmap()
+
+def trace_end():
+ print 'End'
+
+def trace_unhandled(event_name, context, event_fields_dict):
+ print ' '.join(['%s=%s'%(k,str(v))for k,v in sorted(event_fields_dict.items())])
+
+def process_event(param_dict):
+ global cache_size
+ global options
+ global prev_cpu
+
+ sample = param_dict["sample"]
+
+ if (options.verbose == True):
+ dump_packet(sample)
+
+ # If period doesn't equal to 1, this packet is for instruction sample
+ # packet, we need drop this synthetic packet.
+ if (sample['period'] != 1):
+ print "Skip synthetic instruction sample"
+ return
+
+ cpu = format(sample['cpu'], "d");
+
+ # Initialize CPU data if it's empty, and directly return back
+ # if this is the first tracing event for this CPU.
+ if (cpu_data.get(str(cpu) + 'addr') == None):
+ cpu_data[str(cpu) + 'addr'] = format(sample['addr'], "#x")
+ prev_cpu = cpu
+ return
+
+ # The format for packet is:
+ #
+ # +------------+------------+------------+
+ # sample_prev: | addr | ip | cpu |
+ # +------------+------------+------------+
+ # sample_next: | addr | ip | cpu |
+ # +------------+------------+------------+
+ #
+ # We need to combine the two continuous packets to get the instruction
+ # range for sample_prev::cpu:
+ #
+ # [ sample_prev::addr .. sample_next::ip ]
+ #
+ # For this purose, sample_prev::addr is stored into cpu_data structure
+ # and read back for 'start_addr' when the new packet comes, and we need
+ # to use sample_next::ip to calculate 'stop_addr', plusing extra 4 for
+ # 'stop_addr' is for the sake of objdump so the final assembler dump can
+ # include last instruction for sample_next::ip.
+
+ start_addr = cpu_data[str(prev_cpu) + 'addr']
+ stop_addr = format(sample['ip'] + 4, "#x")
+
+ # Record for previous sample packet
+ cpu_data[str(cpu) + 'addr'] = format(sample['addr'], "#x")
+ prev_cpu = cpu
+
+ # Handle CS_ETM_TRACE_ON packet if start_addr=0 and stop_addr=4
+ if (int(start_addr, 0) == 0 and int(stop_addr, 0) == 4):
+ print "CPU%s: CS_ETM_TRACE_ON packet is inserted" % cpu
+ return
+
+ # Sanity checking dso for start_addr and stop_addr
+ prev_dso = find_dso_mmap(int(start_addr, 0))
+ next_dso = find_dso_mmap(int(stop_addr, 0))
+
+ # If cannot find dso so cannot dump assembler, bail out
+ if (prev_dso == None or next_dso == None):
+ print "Address range [ %s .. %s ]: failed to find dso" % (start_addr, stop_addr)
+ return
+ elif (prev_dso != next_dso):
+ print "Address range [ %s .. %s ]: isn't in same dso" % (start_addr, stop_addr)
+ return
+
+ dump_disam(prev_dso, start_addr, stop_addr)
--
2.7.4
^ permalink raw reply related
* [RFT v3 4/4] coresight: Document for CoreSight trace disassembler
From: Leo Yan @ 2018-05-28 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527497103-3593-1-git-send-email-leo.yan@linaro.org>
This commit documents CoreSight trace disassembler usage and gives
example for it.
Signed-off-by: Leo Yan <leo.yan@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 30000 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
+ ffff000008a5f2dc <etm4_enable_hw+0x344>:
+ ffff000008a5f2dc: 340000a0 cbz w0, ffff000008a5f2f0 <etm4_enable_hw+0x358>
+ ffff000008a5f2f0 <etm4_enable_hw+0x358>:
+ ffff000008a5f2f0: f9400260 ldr x0, [x19]
+ ffff000008a5f2f4: d5033f9f dsb sy
+ ffff000008a5f2f8: 913ec000 add x0, x0, #0xfb0
+ ffff000008a5f2fc: b900001f str wzr, [x0]
+ ffff000008a5f300: f9400bf3 ldr x19, [sp, #16]
+ ffff000008a5f304: a8c27bfd ldp x29, x30, [sp], #32
+ ffff000008a5f308: d65f03c0 ret
+ ffff000008a5fa18 <etm4_enable+0x1b0>:
+ ffff000008a5fa18: 14000025 b ffff000008a5faac <etm4_enable+0x244>
+ ffff000008a5faac <etm4_enable+0x244>:
+ ffff000008a5faac: b9406261 ldr w1, [x19, #96]
+ ffff000008a5fab0: 52800015 mov w21, #0x0 // #0
+ ffff000008a5fab4: f901ca61 str x1, [x19, #912]
+ ffff000008a5fab8: 2a1503e0 mov w0, w21
+ ffff000008a5fabc: 3940e261 ldrb w1, [x19, #56]
+ ffff000008a5fac0: f901ce61 str x1, [x19, #920]
+ ffff000008a5fac4: a94153f3 ldp x19, x20, [sp, #16]
+ ffff000008a5fac8: a9425bf5 ldp x21, x22, [sp, #32]
+ ffff000008a5facc: a94363f7 ldp x23, x24, [sp, #48]
+ ffff000008a5fad0: a8c47bfd ldp x29, x30, [sp], #64
+ ffff000008a5fad4: d65f03c0 ret
--
2.7.4
^ permalink raw reply related
* [PATCH 6/9] ARM: dts: wheat: Drop MTD partitioning from DT
From: Geert Uytterhoeven @ 2018-05-28 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528084135.q5xng5eaypprsypr@verge.net.au>
Hi Simon,
On Mon, May 28, 2018 at 10:41 AM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, May 24, 2018 at 04:52:59PM +0200, Marek Vasut wrote:
>> On 05/23/2018 08:25 AM, Geert Uytterhoeven wrote:
>> > On Wed, May 23, 2018 at 12:01 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
>> >> On 05/22/2018 04:43 PM, Geert Uytterhoeven wrote:
>> >>> On Tue, May 22, 2018 at 2:02 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
>> >>>> Drop the MTD partitioning from DT, since it does not describe HW
>> >>>> and to give way to a more flexible kernel command line partition
>> >>>> passing.
>> >>>>
>> >>>> To retain the original partitioning, assure you have enabled
>> >>>> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
>> >>>> following to your kernel command line:
>> >>>>
>> >>>> mtdparts=spi0.0:256k at 0(loader),4096k(user),-(flash)
>> >>>
>> >>> I think the "@0" can be dropped, as it's optional?
>> >>> 4m?
>> >>
>> >> My take on this is that the loader is actually at offset 0x0 of the MTD
>> >> device and we explicitly state that in the mtdparts to anchor the first
>> >> partition within the MTD device and all the other partitions are at
>> >> offset +(sum of the sizes of all partitions listed before the current
>> >> one) relative to that first partition.
>> >
>> > Where is this explicitly states for the first partition?
>> >
>> >> Removing the @0 feels fragile at best and it seems to depend on the
>> >> current behavior of the code.
>> >
>> > Better, it also depends on the documented behavior:
>> >
>> > Documentation/admin-guide/kernel-parameters.txt refers to
>> > drivers/mtd/cmdlinepart.c, which states:
>> >
>> > * <offset> := standard linux memsize
>> > * if omitted the part will immediately follow the previous part
>> > * or 0 if the first part
>> >
>> > None of the examples listed there or under the MTD_CMDLINE_PARTS Kconfig
>> > help text, or in a defconfig bundled with the kernel, use @0 for the first
>> > partition.
>>
>> I think this is exceptionally fragile and dangerous to depend on this,
>> but so be it.
>
> Could you respin with this change?
>
> I would also like to ask for another change, in light of recent
> feedback from Olof Johansson ("Re: [GIT PULL] Renesas ARM64 Based SoC DT
> Updates for v4.18").
>
> Please consolidate the dts patches into a single patch?
I think it's better to keep them split, as each commit description mentions
what needs to be passed on the kernel command line for the corresponding
board.
Combining it in a single patch makes it much harder to extract this information.
Unless you're fine with a list:
koelsch: ...
wheat: mtdparts=spi0.0:256k at 0(loader),4096k(user),-(flash)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v1 5/7] drm/mediatek: implement connection from BLS to DPI0
From: CK Hu @ 2018-05-28 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514075243.5442-6-bibby.hsieh@mediatek.com>
Hi, Bibby:
On Mon, 2018-05-14 at 15:52 +0800, Bibby Hsieh wrote:
> Modify display driver to support connection from BLS to DPI.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 8130f3dab661..289a68c6731f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -35,6 +35,7 @@
> #define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030
> #define DISP_REG_CONFIG_OUT_SEL 0x04c
> #define DISP_REG_CONFIG_DSI_SEL 0x050
> +#define DISP_REG_CONFIG_DPI_SEL 0x064
>
> #define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
> #define DISP_REG_MUTEX(n) (0x24 + 0x20 * (n))
> @@ -84,7 +85,10 @@
>
> #define OVL_MOUT_EN_RDMA 0x1
> #define BLS_TO_DSI_RDMA1_TO_DPI1 0x8
> +#define BLS_TO_DPI_RDMA1_TO_DSI 0x2
> #define DSI_SEL_IN_BLS 0x0
> +#define DPI_SEL_IN_BLS 0x0
> +#define DSI_SEL_IN_RDMA 0x1
>
> struct mtk_disp_mutex {
> int id;
> @@ -189,9 +193,17 @@ static void mtk_ddp_sout_sel(void __iomem *config_regs,
> enum mtk_ddp_comp_id cur,
> enum mtk_ddp_comp_id next)
> {
> - if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0)
> + if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
> writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
> config_regs + DISP_REG_CONFIG_OUT_SEL);
When BLS->DIP0, DISP_REG_CONFIG_DSI_SEL and DISP_REG_CONFIG_DPI_SEL are
configured. I think these two register should be configured when
BLS->DSI0.
Regards,
CK
> + } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
> + writel_relaxed(BLS_TO_DPI_RDMA1_TO_DSI,
> + config_regs + DISP_REG_CONFIG_OUT_SEL);
> + writel_relaxed(DSI_SEL_IN_RDMA,
> + config_regs + DISP_REG_CONFIG_DSI_SEL);
> + writel_relaxed(DPI_SEL_IN_BLS,
> + config_regs + DISP_REG_CONFIG_DPI_SEL);
> + }
> }
>
> void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
^ permalink raw reply
* [PATCH v2 10/11] arm64: dts: r8a77965-salvator-x: Enable DU external clocks and HDMI
From: Geert Uytterhoeven @ 2018-05-28 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180427165722.19445-11-kieran.bingham+renesas@ideasonboard.com>
Hi Kieran, Morimoto-san,
On Fri, Apr 27, 2018 at 6:57 PM, Kieran Bingham
<kieran.bingham+renesas@ideasonboard.com> wrote:
> The DU1 external dot clock is provided by the fixed frequency clock
> generator X21, while the DU0 and DU3 clocks are provided by the
> programmable Versaclock5 clock generator.
>
> Enable the clocks, and the HDMI encoder for the M3-N Salvator-X board
> and hook it up to the HDMI connector.
>
> Based on patches from Takeshi Kihara <takeshi.kihara.df@renesas.com>
>
> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
>
> ---
> v2:
> - Remove LVDS clocks from DU node
> - Merge DU Clocks and HDMI enablement
> ---
> .../boot/dts/renesas/r8a77965-salvator-x.dts | 28 +++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
> index 75d890d91df9..340a3c72b65a 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
> @@ -19,3 +19,31 @@
> reg = <0x0 0x48000000 0x0 0x78000000>;
> };
> };
> +
> +&du {
> + clocks = <&cpg CPG_MOD 724>,
> + <&cpg CPG_MOD 723>,
> + <&cpg CPG_MOD 721>,
> + <&versaclock5 1>,
> + <&x21_clk>,
> + <&versaclock5 2>;
> + clock-names = "du.0", "du.1", "du.3",
> + "dclkin.0", "dclkin.1", "dclkin.3";
> +};
> +
> +&hdmi0 {
> + status = "okay";
> +
> + ports {
> + port at 1 {
> + reg = <1>;
> + rcar_dw_hdmi0_out: endpoint {
> + remote-endpoint = <&hdmi0_con>;
> + };
> + };
> + };
> +};
> +
> +&hdmi0_con {
> + remote-endpoint = <&rcar_dw_hdmi0_out>;
> +};
I think the hdmi0 and hdmi0_con parts can be moved to salvator-common.dtsi.
Can we do that now (with stubs?), or does this have to wait until r8a77965 has
received HDMI sound support?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v1] ARM: multi_v7_defconfig: enable STM32 DMAv2, DMAMUX and MDMA
From: Pierre-Yves MORDRET @ 2018-05-28 9:08 UTC (permalink / raw)
To: linux-arm-kernel
This enables drivers for STM32:
- DMAv2
- DMMAUX
- MDMA
Signed-off-by: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
---
Version history:
v1:
* Initial
---
---
arch/arm/configs/multi_v7_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 89167cd..9f62957 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -887,6 +887,9 @@ CONFIG_QCOM_BAM_DMA=y
CONFIG_XILINX_DMA=y
CONFIG_DMA_SUN6I=y
CONFIG_ST_FDMA=m
+CONFIG_STM32_DMA=y
+CONFIG_STM32_DMAMUX=y
+CONFIG_STM32_MDMA=y
CONFIG_STAGING=y
CONFIG_SENSORS_ISL29018=y
CONFIG_SENSORS_ISL29028=y
--
2.7.4
^ permalink raw reply related
* [PATCH v1 3/7] drm/mediatek: add dpi driver for mt2701 and mt7623
From: CK Hu @ 2018-05-28 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514075243.5442-4-bibby.hsieh@mediatek.com>
Hi, Bibby:
On Mon, 2018-05-14 at 15:52 +0800, Bibby Hsieh wrote:
> From: chunhui dai <chunhui.dai@mediatek.com>
>
> This patch adds dpi driver suppot for both mt2701 and mt7623.
> And also support other (existing or future) chips that use
> the same binding and driver.
>
> Signed-off-by: chunhui dai <chunhui.dai@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 24 ++++++++++++++++++++++--
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
> 2 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 2b8b34c72697..e1af1d0d213d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -640,8 +640,7 @@ static int mtk_dpi_bind(struct device *dev, struct device *master, void *data)
> }
> drm_encoder_helper_add(&dpi->encoder, &mtk_dpi_encoder_helper_funcs);
>
> - /* Currently DPI0 is fixed to be driven by OVL1 */
> - dpi->encoder.possible_crtcs = BIT(1);
> + dpi->encoder.possible_crtcs = BIT(0) | BIT(1);
This modification influence not only mt2701, but also mt8173. So move
this to an independent patch.
Regards,
CK
> dpi->encoder.bridge->encoder = &dpi->encoder;
> ret = drm_bridge_attach(&dpi->encoder, dpi->encoder.bridge, NULL);
> if (ret) {
> @@ -690,12 +689,33 @@ static unsigned int mt8173_calculate_factor(int clock)
> return 2 * 3;
> }
>
> +static unsigned int mt2701_calculate_factor(int clock)
> +{
> + if (clock <= 64000)
> + return 16;
> + else if (clock <= 128000)
> + return 8;
> + else if (clock <= 256000)
> + return 4;
> + else
> + return 2;
> +}
> +
> static const struct mtk_dpi_conf mt8173_conf = {
> .cal_factor = mt8173_calculate_factor,
> .reg_h_fre_con = 0xe0,
> };
>
> +static const struct mtk_dpi_conf mt2701_conf = {
> + .cal_factor = mt2701_calculate_factor,
> + .reg_h_fre_con = 0xb0,
> + .edge_sel_en = true,
> +};
> +
> static const struct of_device_id mtk_dpi_of_ids[] = {
> + { .compatible = "mediatek,mt2701-dpi",
> + .data = &mt2701_conf,
> + },
> { .compatible = "mediatek,mt8173-dpi",
> .data = &mt8173_conf,
> },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index a2ca90fc403c..f4fb86ab7b8d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -372,6 +372,7 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
> { .compatible = "mediatek,mt8173-disp-ufoe", .data = (void *)MTK_DISP_UFOE },
> { .compatible = "mediatek,mt2701-dsi", .data = (void *)MTK_DSI },
> { .compatible = "mediatek,mt8173-dsi", .data = (void *)MTK_DSI },
> + { .compatible = "mediatek,mt2701-dpi", .data = (void *)MTK_DPI },
> { .compatible = "mediatek,mt8173-dpi", .data = (void *)MTK_DPI },
> { .compatible = "mediatek,mt2701-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
> { .compatible = "mediatek,mt8173-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
^ permalink raw reply
* [PATCH 5/5] MAINTAINERS: imx: add NXP linux team upstream maillist as reviewer
From: A.s. Dong @ 2018-05-28 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528080037.GC3143@dragon>
Hi Shawn,
> -----Original Message-----
> From: Shawn Guo [mailto:shawnguo at kernel.org]
> Sent: Monday, May 28, 2018 4:01 PM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: dongas86 at gmail.com; catalin.marinas at arm.com; will.deacon at arm.com;
> robh+dt at kernel.org; dl-linux-imx <linux-imx@nxp.com>;
> kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>; linux-
> arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 5/5] MAINTAINERS: imx: add NXP linux team upstream
> maillist as reviewer
>
> On Fri, May 25, 2018 at 02:14:07AM +0000, A.s. Dong wrote:
> > Hi Shawn,
> >
> > > -----Original Message-----
> > > From: A.s. Dong
> > > Sent: Saturday, April 28, 2018 3:06 AM
> > > To: linux-arm-kernel at lists.infradead.org
> > > Cc: dongas86 at gmail.com; kernel at pengutronix.de;
> shawnguo at kernel.org;
> > > Fabio Estevam <fabio.estevam@nxp.com>; robh+dt at kernel.org;
> > > catalin.marinas at arm.com; will.deacon at arm.com; dl-linux-imx <linux-
> > > imx at nxp.com>; A.s. Dong <aisheng.dong@nxp.com>
> > > Subject: [PATCH 5/5] MAINTAINERS: imx: add NXP linux team upstream
> > > maillist as reviewer
> > >
> > > Add NXP linux team upstream maillist as reviewer
> > >
> > > Cc: Shawn Guo <shawnguo@kernel.org>
> > > Cc: Sascha Hauer <kernel@pengutronix.de>
> > > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > > Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> >
> > Would you pick this one first?
>
> Okay. I changed patch subject a bit as below and applied the patch, since
> usually we do not have subsystem prefix for MAINTAINERS change.
>
> MAINTAINERS: add NXP linux team maillist as i.MX reviewer
>
Great. Thanks.
Regards
Dong Aisheng
> Shawn
^ permalink raw reply
* [PATCH v1 6/7] drm/mediatek: add a error return value when clock driver has been prepared
From: CK Hu @ 2018-05-28 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514075243.5442-7-bibby.hsieh@mediatek.com>
Hi, Bibby:
On Mon, 2018-05-14 at 15:52 +0800, Bibby Hsieh wrote:
> DRM driver get the comp->clk by of_clk_get(), we only
> assign NULL to comp->clk when error happened, but do
> not return the error number.
>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 4672317e3ad1..d38a5303f8fc 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -283,7 +283,7 @@ int mtk_ddp_comp_init(struct device *dev, struct device_node *node,
> comp->irq = of_irq_get(node, 0);
> comp->clk = of_clk_get(node, 0);
> if (IS_ERR(comp->clk))
> - comp->clk = NULL;
> + return PTR_ERR(comp->clk);
>
> /* Only DMA capable components need the LARB property */
> comp->larb_dev = NULL;
^ permalink raw reply
* [PATCH 1/8] drm/sun4i: mark PM functions as __maybe_unused
From: Maxime Ripard @ 2018-05-28 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525155030.3667352-1-arnd@arndb.de>
On Fri, May 25, 2018 at 05:50:08PM +0200, Arnd Bergmann wrote:
> Disabling CONFIG_PM produces a compile time warning when these
> functions are not referenced:
>
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1072:12: error: 'sun6i_dsi_runtime_suspend' defined but not used [-Werror=unused-function]
> static int sun6i_dsi_runtime_suspend(struct device *dev)
> ^~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1043:12: error: 'sun6i_dsi_runtime_resume' defined but not used [-Werror=unused-function]
> static int sun6i_dsi_runtime_resume(struct device *dev)
> ^~~~~~~~~~~~~~~~~~~~~~~~
>
> Fixes: 133add5b5ad4 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180528/a89240b5/attachment.sig>
^ permalink raw reply
* [PATCH 4/4] soc: imx: add SC firmware IPC and APIs
From: A.s. Dong @ 2018-05-28 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM0PR04MB421169E44830A17D8A52D3F4806A0@AM0PR04MB4211.eurprd04.prod.outlook.com>
Hi Sascha,
> -----Original Message-----
> From: A.s. Dong
> Sent: Thursday, May 24, 2018 4:56 PM
> To: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com; dl-linux-imx
> <linux-imx@nxp.com>; kernel at pengutronix.de; Fabio Estevam
> <fabio.estevam@nxp.com>; shawnguo at kernel.org
> Subject: RE: [PATCH 4/4] soc: imx: add SC firmware IPC and APIs
>
> Hi Sascha,
>
> > -----Original Message-----
> > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > Sent: Thursday, May 3, 2018 8:41 PM
> > To: A.s. Dong <aisheng.dong@nxp.com>
> > Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com;
> > dl-linux-imx <linux-imx@nxp.com>; kernel at pengutronix.de; Fabio
> Estevam
> > <fabio.estevam@nxp.com>; shawnguo at kernel.org
> > Subject: Re: [PATCH 4/4] soc: imx: add SC firmware IPC and APIs
> >
> > On Thu, May 03, 2018 at 12:29:40PM +0000, A.s. Dong wrote:
> > > > -----Original Message-----
> > > > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > > > Sent: Thursday, May 3, 2018 7:06 PM
> > > > To: A.s. Dong <aisheng.dong@nxp.com>
> > > > Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com;
> > > > dl-linux-imx <linux-imx@nxp.com>; kernel at pengutronix.de; Fabio
> > > > Estevam <fabio.estevam@nxp.com>; shawnguo at kernel.org
> > > > Subject: Re: [PATCH 4/4] soc: imx: add SC firmware IPC and APIs
> > > >
> > > > On Wed, May 02, 2018 at 06:40:03PM +0000, A.s. Dong wrote:
> > > > > > -----Original Message-----
> > > > > > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > > > > > Sent: Wednesday, May 2, 2018 6:04 PM
> > > > > > To: A.s. Dong <aisheng.dong@nxp.com>
> > > > > > Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com;
> > > > > > dl-linux-imx <linux-imx@nxp.com>; kernel at pengutronix.de; Fabio
> > > > > > Estevam <fabio.estevam@nxp.com>; shawnguo at kernel.org
> > > > > > Subject: Re: [PATCH 4/4] soc: imx: add SC firmware IPC and
> > > > > > APIs
> > > > > >
> > > > > > On Sat, Apr 28, 2018 at 02:46:16AM +0800, Dong Aisheng wrote:
> > > > > > > +/* Initialization of the MU code. */ int __init
> > > > > > > +imx8_scu_init(void) {
> > > > > > > + struct device_node *np, *mu_np;
> > > > > > > + struct resource mu_res;
> > > > > > > + sc_err_t sci_err;
> > > > > > > + int ret;
> > > > > > > +
> > > > > > > + if (!of_machine_is_compatible("fsl,imx8qxp"))
> > > > > > > + return 0;
> > > > > > > +
> > > > > > > + np = of_find_compatible_node(NULL, NULL, "nxp,imx8qxp-
> > scu");
> > > > > > > + if (!np)
> > > > > > > + return -ENODEV;
> > > > > > > +
> > > > > > > + mu_np = of_parse_phandle(np, "fsl,mu", 0);
> > > > > > > + if (WARN_ON(!mu_np))
> > > > > > > + return -EINVAL;
> > > > > > > +
> > > > > > > + ret = of_address_to_resource(mu_np, 0, &mu_res);
> > > > > > > + if (WARN_ON(ret))
> > > > > > > + return -EINVAL;
> > > > > > > +
> > > > > > > + /* we use mu physical address as IPC communication channel
> > ID */
> > > > > > > + sci_err = sc_ipc_open(&scu_ipc_handle,
> > (sc_ipc_id_t)(mu_res.start));
> > > > > > > + if (sci_err != SC_ERR_NONE) {
> > > > > > > + pr_err("Cannot open MU channel to SCU\n");
> > > > > > > + return sci_err;
> > > > > > > + };
> > > > > >
> > > > > > Introducing private error codes always has the risk of just
> > > > > > forwarding them as errno codes as done here.
> > > > > >
> > > > >
> > > > > Yes, you're right.
> > > > > We probably could do the same as scpi_to_linux_errno in
> > > > > drivers/firmware/arm_scpi.c.
> > > > > However, may can't fix the issue permanently.
> > > > >
> > > > > > > +
> > > > > > > + of_node_put(mu_np);
> > > > > > > +
> > > > > > > + pr_info("NXP i.MX SCU Initialized (scu_ipc %u)\n",
> > > > > > > +scu_ipc_handle);
> > > > > > > +
> > > > > > > + return 0;
> > > > > > > +}
> > > > > > > +early_initcall(imx8_scu_init);
> > > > > >
> > > > > > This code shows that the separate 'scu' device node shouldn't exist.
> > > > > > It is only used as a stepping stone to find the 'mu' node.
> > > > > > Instead of providing a proper driver for the 'mu' node the scu
> > > > > > code registers it
> > > > with its physical address.
> > > > > > I don't think it makes sense to separate mu and scu code in this way.
> > > > > >
> > > > >
> > > > > I agree that may not look quite well.
> > > > > It mainly because we want to use the MU physical address as a MU ID.
> > > > > (can't use virtual address as sc_ipc_id_t is u32 defined by SCU
> firmware.
> > > > >
> > > > > If you have any better suggestion please let me know.
> > > >
> > > > What I'm suggesting is a single node:
> > > >
> > > > scu at 5d1b0000 {
> > > > compatible = "fsl,imx8qxp-scu";
> > > > reg = <0x0 0x5d1b0000 0x0 0x10000>;
> > > > };
> > > >
> > > > Attach your code to this one, without any further separation
> > > > between mu and scu code.
> > > >
> > >
> > > A bit confused. You're suggesting a single node here without mu or
> > > mailbox node phandle in it? Then how SCU use MU?
> >
> > ioremap the address and mu_receive_msg()/mu_send_msg() on it, just
> > like you do already.
> >
> > >
> > > > We discussed this internally and came to the conclusion that the
> > > > SCU is not a generic user of a MU. The MU is designed to work
> > > > together with a piece of SRAM to form a mailbox system. Instead of
> > > > working as designed the SCU morses the messages through the
> > > > doorbell (what the MU really is). For anything that uses the MU in
> > > > the way it is designed I would suggest using the mailbox interface
> > > > from drivers/mailbox/ along with the binding from
> > Documentation/devicetree/bindings/mailbox/mailbox.txt.
> > > >
> > > > In the way I suggest there is no need for any MU ID.
> > > >
> > >
> > > So you're suggesting switch to use mailbox instead of private MU
> > > library function calls?
> > > Something like:
> > > scu {
> > > compatible = "nxp,imx8qxp-scu", "simple-bus";
> > > mboxes = <&mailbox 0>;
> > > }
> > > Then IPC is implemented based on mailbox?
> > >
> > > As I replied Oleksij Rempel in another mail in this thread, we've
> > > tried mailbox but got performance regression issue and need more
> > > time to investigate whether it's really quite suitable for i.MX SCU
> > > firmware as SCU handling message quite fast in micro seconds.
> > > (Mailbox polling method has much more latency than current MU sample
> > > polling we
> > > used) and we want to avoid the SCU firmware API changes.
> >
> > I am not suggesting to do mailboxing (using shared memory) for the SCU.
> > I am also not suggesting any API update for the SCU communication.
> > I am just mentioning that doing mailboxing is the way the MU was
> > originally designed for. Looking at the reference manual I see many MUs on
> the i.MX8.
> > I guess most of them are for communication between the different cores
> > on the system. For these it's probably worth writing some generic MU
> driver.
> > The way the MU is used for communication with the SCU though is so
> > special that it's not worth writing a generic driver, so just
> > integrate the MU access functions in the SCU code.
> >
>
> I understand it.
>
> One problem of the way you suggested may be that:
> If we doing like below, we may lose flexibility to change the MU used for SCU
> firmware communication.
> scu at 5d1b0000 {
> compatible = "fsl,imx8qxp-scu";
> reg = <0x0 0x5d1b0000 0x0 0x10000>;
> };
>
> And current design is that the system supports multiple MU channels used
> by various users at the same time, e.g. SCU, Power Domain, Clock and others.
> User can flexibly change it under their nodes: And each MU channel is
> protected by their private lock and not affect each others.
>
> e.g.
> scu {
> compatible = "nxp,imx8qxp-scu", "simple-bus";
> fsl,mu = <&lsio_mu0>;
>
> clk: clk {
> compatible = "fsl,imx8qxp-clk";
> #clock-cells = <1>;
> };
>
> iomuxc: iomuxc {
> compatible = "fsl,imx8qxp-iomuxc";
> fsl,mu = <&lsio_mu3>;
> };
>
> imx8qx-pm {
> #address-cells = <1>;
> #size-cells = <0>;
> fsl,mu = <&lsio_mu4>;
> .............
> }
>
> The default code only uses MU0 which is used by SCU.
>
> The change may affect this design. Any ideas?
> Do you think we can keep the current way?
>
Any comments about this?
Regards
Dong Aisheng
> Regards
> Dong Aisheng
>
> > Sascha
> >
> > --
> > Pengutronix e.K. | |
> > Industrial Linux Solutions |
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww
> >
> w.pengutronix.de%2F&data=02%7C01%7Caisheng.dong%40nxp.com%7C266
> > 24a5c38e5488a80b708d5b0f3107b%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> >
> 7C0%7C0%7C636609480354404338&sdata=XP%2BYdt9I7zURrQun2jRbempLhC
> > XrYtMVMb3dEWrZuro%3D&reserved=0 |
> > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH 6/9] ARM: dts: wheat: Drop MTD partitioning from DT
From: Simon Horman @ 2018-05-28 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXYyN=XY6nb9RVEE+t0NeoSPhTh6fUk-9YWdFzAE1FfPA@mail.gmail.com>
On Mon, May 28, 2018 at 10:54:57AM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Mon, May 28, 2018 at 10:41 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Thu, May 24, 2018 at 04:52:59PM +0200, Marek Vasut wrote:
> >> On 05/23/2018 08:25 AM, Geert Uytterhoeven wrote:
> >> > On Wed, May 23, 2018 at 12:01 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
> >> >> On 05/22/2018 04:43 PM, Geert Uytterhoeven wrote:
> >> >>> On Tue, May 22, 2018 at 2:02 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> >> >>>> Drop the MTD partitioning from DT, since it does not describe HW
> >> >>>> and to give way to a more flexible kernel command line partition
> >> >>>> passing.
> >> >>>>
> >> >>>> To retain the original partitioning, assure you have enabled
> >> >>>> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
> >> >>>> following to your kernel command line:
> >> >>>>
> >> >>>> mtdparts=spi0.0:256k at 0(loader),4096k(user),-(flash)
> >> >>>
> >> >>> I think the "@0" can be dropped, as it's optional?
> >> >>> 4m?
> >> >>
> >> >> My take on this is that the loader is actually at offset 0x0 of the MTD
> >> >> device and we explicitly state that in the mtdparts to anchor the first
> >> >> partition within the MTD device and all the other partitions are at
> >> >> offset +(sum of the sizes of all partitions listed before the current
> >> >> one) relative to that first partition.
> >> >
> >> > Where is this explicitly states for the first partition?
> >> >
> >> >> Removing the @0 feels fragile at best and it seems to depend on the
> >> >> current behavior of the code.
> >> >
> >> > Better, it also depends on the documented behavior:
> >> >
> >> > Documentation/admin-guide/kernel-parameters.txt refers to
> >> > drivers/mtd/cmdlinepart.c, which states:
> >> >
> >> > * <offset> := standard linux memsize
> >> > * if omitted the part will immediately follow the previous part
> >> > * or 0 if the first part
> >> >
> >> > None of the examples listed there or under the MTD_CMDLINE_PARTS Kconfig
> >> > help text, or in a defconfig bundled with the kernel, use @0 for the first
> >> > partition.
> >>
> >> I think this is exceptionally fragile and dangerous to depend on this,
> >> but so be it.
> >
> > Could you respin with this change?
> >
> > I would also like to ask for another change, in light of recent
> > feedback from Olof Johansson ("Re: [GIT PULL] Renesas ARM64 Based SoC DT
> > Updates for v4.18").
> >
> > Please consolidate the dts patches into a single patch?
>
> I think it's better to keep them split, as each commit description mentions
> what needs to be passed on the kernel command line for the corresponding
> board.
>
> Combining it in a single patch makes it much harder to extract this information.
> Unless you're fine with a list:
>
> koelsch: ...
> wheat: mtdparts=spi0.0:256k at 0(loader),4096k(user),-(flash)
Lets try a list.
^ permalink raw reply
* [PATCH 00/12] Add TOSHIBA TC358764 DSI/LVDS bridge driver
From: Maciej Purski @ 2018-05-28 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20180528094721eucas1p22b90fd838ce00f029fec7f5241cc06b5@eucas1p2.samsung.com>
Hi all,
this patchset is a next attempt to add the tc358764 driver.
The previous one can be found here:
https://lists.freedesktop.org/archives/dri-devel/2014-February/053705.html
Back then, TC358764 was added as a panel driver.
The bridge is supposed to be a DSI peripheral. Currently exynos_dsi accepts only panels
as its peripherals. Therefore, some logic in exynos_dsi had to be ammended. That is implemented
in first 4 patches.
Apart from the driver this patchset adds support for BOE HV070WSA-100 panel, which is used by
TC358764 and dts nodes to exynos5250.dtsi and exynos5250-arndale.dtsi.
Best regards,
Maciej Purski
Maciej Purski (12):
drm/exynos: rename "bridge_node" to "mic_bridge_node"
drm/exynos: move pm_runtime_get_sync() to exynos_dsi_init()
drm/exynos: move connector creation to attach callback
drm/exynos: add non-panel path to exynos_dsi_enable()
panel/hv070wsa-100: add DT bindings
drm/panel: add support for BOE HV070WSA-100 panel to simple-panel
dt-bindings: tc358754: add DT bindings
drm/bridge: tc358764: Add DSI to LVDS bridge driver
ARM: dts: exynos5250: add mipi-phy node
ARM: dts: exynos5250: add DSI node
ARM: dts: exynos5250-arndale: add display regulators
ARM: dts: exynos5250-arndale: add dsi and panel nodes
.../bindings/display/bridge/toshiba,tc358764.txt | 42 ++
.../bindings/display/panel/boe,hv070wsa-100.txt | 7 +
arch/arm/boot/dts/exynos5250-arndale.dts | 63 +++
arch/arm/boot/dts/exynos5250.dtsi | 20 +
drivers/gpu/drm/bridge/Kconfig | 7 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/tc358764.c | 547 +++++++++++++++++++++
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 84 ++--
drivers/gpu/drm/panel/panel-simple.c | 25 +
9 files changed, 756 insertions(+), 40 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
create mode 100644 Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt
create mode 100644 drivers/gpu/drm/bridge/tc358764.c
--
2.7.4
^ permalink raw reply
* [PATCH 01/12] drm/exynos: rename "bridge_node" to "mic_bridge_node"
From: Maciej Purski @ 2018-05-28 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-1-git-send-email-m.purski@samsung.com>
When adding support for peripheral out bridges, the "bridge" name
becomes imprecise as it refers to a different device than the
"out_bridge".
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index eae44fd..9599e6b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -279,7 +279,7 @@ struct exynos_dsi {
struct list_head transfer_list;
const struct exynos_dsi_driver_data *driver_data;
- struct device_node *bridge_node;
+ struct device_node *mic_bridge_node;
};
#define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
@@ -1631,7 +1631,7 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
if (ret < 0)
return ret;
- dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
+ dsi->mic_bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
return 0;
}
@@ -1642,7 +1642,7 @@ static int exynos_dsi_bind(struct device *dev, struct device *master,
struct drm_encoder *encoder = dev_get_drvdata(dev);
struct exynos_dsi *dsi = encoder_to_dsi(encoder);
struct drm_device *drm_dev = data;
- struct drm_bridge *bridge;
+ struct drm_bridge *mic_bridge;
int ret;
drm_encoder_init(drm_dev, encoder, &exynos_dsi_encoder_funcs,
@@ -1661,10 +1661,10 @@ static int exynos_dsi_bind(struct device *dev, struct device *master,
return ret;
}
- if (dsi->bridge_node) {
- bridge = of_drm_find_bridge(dsi->bridge_node);
- if (bridge)
- drm_bridge_attach(encoder, bridge, NULL);
+ if (dsi->mic_bridge_node) {
+ mic_bridge = of_drm_find_bridge(dsi->mic_bridge_node);
+ if (mic_bridge)
+ drm_bridge_attach(encoder, mic_bridge, NULL);
}
return mipi_dsi_host_register(&dsi->dsi_host);
@@ -1783,7 +1783,7 @@ static int exynos_dsi_remove(struct platform_device *pdev)
{
struct exynos_dsi *dsi = platform_get_drvdata(pdev);
- of_node_put(dsi->bridge_node);
+ of_node_put(dsi->mic_bridge_node);
pm_runtime_disable(&pdev->dev);
--
2.7.4
^ permalink raw reply related
* [PATCH 02/12] drm/exynos: move pm_runtime_get_sync() to exynos_dsi_init()
From: Maciej Purski @ 2018-05-28 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-1-git-send-email-m.purski@samsung.com>
In order to allow bridge drivers to use DSI transfers in their
pre_enable callbacks, pm_runtime_get_sync() should be performed before
exynos_dsi_enable(). DSIM_STATE_ENABLED flag now should not guard
from calling dsi_host_transfer() before enabling.
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 9599e6b..94460b0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1312,6 +1312,7 @@ static int exynos_dsi_init(struct exynos_dsi *dsi)
{
const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
+ pm_runtime_get_sync(dsi->dev);
exynos_dsi_reset(dsi);
exynos_dsi_enable_irq(dsi);
@@ -1388,7 +1389,6 @@ static void exynos_dsi_enable(struct drm_encoder *encoder)
ret = drm_panel_prepare(dsi->panel);
if (ret < 0) {
dsi->state &= ~DSIM_STATE_ENABLED;
- pm_runtime_put_sync(dsi->dev);
return;
}
@@ -1400,7 +1400,6 @@ static void exynos_dsi_enable(struct drm_encoder *encoder)
dsi->state &= ~DSIM_STATE_ENABLED;
exynos_dsi_set_display_enable(dsi, false);
drm_panel_unprepare(dsi->panel);
- pm_runtime_put_sync(dsi->dev);
return;
}
@@ -1566,9 +1565,6 @@ static ssize_t exynos_dsi_host_transfer(struct mipi_dsi_host *host,
struct exynos_dsi_transfer xfer;
int ret;
- if (!(dsi->state & DSIM_STATE_ENABLED))
- return -EINVAL;
-
if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
ret = exynos_dsi_init(dsi);
if (ret)
--
2.7.4
^ permalink raw reply related
* [PATCH 03/12] drm/exynos: move connector creation to attach callback
From: Maciej Purski @ 2018-05-28 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-1-git-send-email-m.purski@samsung.com>
The current implementation assumes that the only possible peripheral
device for DSIM is a panel. Using an output bridge should also be
possible.
If an output bridge in available, don't create a new connector.
Instead add bridge to DSIM encdoer in dsi_host_attach().
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 35 +++++++++++++++++++++------------
1 file changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 94460b0..8957faf 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1498,7 +1498,28 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
struct mipi_dsi_device *device)
{
struct exynos_dsi *dsi = host_to_dsi(host);
- struct drm_device *drm = dsi->connector.dev;
+ struct drm_encoder *encoder = &dsi->encoder;
+ struct drm_device *drm = encoder->dev;
+ struct drm_bridge *out_bridge;
+
+ out_bridge = of_drm_find_bridge(device->dev.of_node);
+ if (out_bridge) {
+ drm_bridge_attach(encoder, out_bridge, NULL);
+ } else {
+ int ret = exynos_dsi_create_connector(encoder);
+
+ if (ret) {
+ DRM_ERROR("failed to create connector ret = %d\n", ret);
+ drm_encoder_cleanup(encoder);
+ return ret;
+ }
+
+ dsi->panel = of_drm_find_panel(device->dev.of_node);
+ if (dsi->panel) {
+ drm_panel_attach(dsi->panel, &dsi->connector);
+ dsi->connector.status = connector_status_connected;
+ }
+ }
/*
* This is a temporary solution and should be made by more generic way.
@@ -1517,11 +1538,6 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
dsi->lanes = device->lanes;
dsi->format = device->format;
dsi->mode_flags = device->mode_flags;
- dsi->panel = of_drm_find_panel(device->dev.of_node);
- if (dsi->panel) {
- drm_panel_attach(dsi->panel, &dsi->connector);
- dsi->connector.status = connector_status_connected;
- }
exynos_drm_crtc_get_by_type(drm, EXYNOS_DISPLAY_TYPE_LCD)->i80_mode =
!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO);
@@ -1650,13 +1666,6 @@ static int exynos_dsi_bind(struct device *dev, struct device *master,
if (ret < 0)
return ret;
- ret = exynos_dsi_create_connector(encoder);
- if (ret) {
- DRM_ERROR("failed to create connector ret = %d\n", ret);
- drm_encoder_cleanup(encoder);
- return ret;
- }
-
if (dsi->mic_bridge_node) {
mic_bridge = of_drm_find_bridge(dsi->mic_bridge_node);
if (mic_bridge)
--
2.7.4
^ permalink raw reply related
* [PATCH 04/12] drm/exynos: add non-panel path to exynos_dsi_enable()
From: Maciej Purski @ 2018-05-28 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-1-git-send-email-m.purski@samsung.com>
As DSIM can now have a bridge connected as a peripheral, it should be
possible to successfully enable exynos_dsi, when there is no panel
provided.
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 27 +++++++++++++--------------
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 8957faf..7d92e50 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1382,27 +1382,26 @@ static void exynos_dsi_enable(struct drm_encoder *encoder)
if (dsi->state & DSIM_STATE_ENABLED)
return;
- pm_runtime_get_sync(dsi->dev);
-
- dsi->state |= DSIM_STATE_ENABLED;
-
- ret = drm_panel_prepare(dsi->panel);
- if (ret < 0) {
- dsi->state &= ~DSIM_STATE_ENABLED;
- return;
+ if (dsi->panel) {
+ ret = drm_panel_prepare(dsi->panel);
+ if (ret < 0) {
+ return;
+ }
}
exynos_dsi_set_display_mode(dsi);
exynos_dsi_set_display_enable(dsi, true);
- ret = drm_panel_enable(dsi->panel);
- if (ret < 0) {
- dsi->state &= ~DSIM_STATE_ENABLED;
- exynos_dsi_set_display_enable(dsi, false);
- drm_panel_unprepare(dsi->panel);
- return;
+ if (dsi->panel) {
+ ret = drm_panel_enable(dsi->panel);
+ if (ret < 0) {
+ exynos_dsi_set_display_enable(dsi, false);
+ drm_panel_unprepare(dsi->panel);
+ return;
+ }
}
+ dsi->state |= DSIM_STATE_ENABLED;
dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 05/12] panel/hv070wsa-100: add DT bindings
From: Maciej Purski @ 2018-05-28 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-1-git-send-email-m.purski@samsung.com>
The patch adds bindings to BOE HV070-WSA WSVGA panel.
Bindings are compatible with simple panel bindings.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
.../devicetree/bindings/display/panel/boe,hv070wsa-100.txt | 7 +++++++
1 file changed, 7 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt
diff --git a/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt b/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt
new file mode 100644
index 0000000..bfc20ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt
@@ -0,0 +1,7 @@
+BOE HV070WSA-100 7.01" WSVGA TFT LCD panel
+
+Required properties:
+- compatible: should be "boe,hv070wsa-100"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
--
2.7.4
^ permalink raw reply related
* [PATCH 06/12] drm/panel: add support for BOE HV070WSA-100 panel to simple-panel
From: Maciej Purski @ 2018-05-28 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-1-git-send-email-m.purski@samsung.com>
The patch adds support for BOE HV070WSA-100 WSVGA 7.01 inch panel
in panel-simple driver. The panel is used in Exynos5250-arndale boards.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
drivers/gpu/drm/panel/panel-simple.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab4..d5da58d 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = {
},
};
+static const struct drm_display_mode boe_hv070wsa_mode = {
+ .clock = 40800,
+ .hdisplay = 1024,
+ .hsync_start = 1024 + 90,
+ .hsync_end = 1024 + 90 + 90,
+ .htotal = 1024 + 90 + 90 + 90,
+ .vdisplay = 600,
+ .vsync_start = 600 + 3,
+ .vsync_end = 600 + 3 + 4,
+ .vtotal = 600 + 3 + 4 + 3,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc boe_hv070wsa = {
+ .modes = &boe_hv070wsa_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 154,
+ .height = 90,
+ },
+};
+
static const struct drm_display_mode boe_nv101wxmn51_modes[] = {
{
.clock = 71900,
@@ -2113,6 +2135,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = &avic_tm070ddh03,
}, {
+ .compatible = "boe,hv070wsa-100",
+ .data = &boe_hv070wsa
+ }, {
.compatible = "boe,nv101wxmn51",
.data = &boe_nv101wxmn51,
}, {
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox