* [PATCH 4/7] perf cs-etm: Fix indexing for decoder packet queue
From: Arnaldo Carvalho de Melo @ 2018-05-31 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531103220.24684-1-acme@kernel.org>
From: Mathieu Poirier <mathieu.poirier@linaro.org>
The tail of a queue is supposed to be pointing to the next available
slot in a queue. In this implementation the tail is incremented before
it is used and as such points to the last used element, something that
has the immense advantage of centralizing tail management at a single
location and eliminating a lot of redundant code.
But this needs to be taken into consideration on the dequeueing side
where the head also needs to be incremented before it is used, or the
first available element of the queue will be skipped.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Tested-by: Leo Yan <leo.yan@linaro.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Robert Walker <robert.walker@arm.com>
Cc: linux-arm-kernel at lists.infradead.org
Link: http://lkml.kernel.org/r/1527289854-10755-1-git-send-email-mathieu.poirier at linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index c8b98fa22997..4d5fc374e730 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -96,11 +96,19 @@ int cs_etm_decoder__get_packet(struct cs_etm_decoder *decoder,
/* Nothing to do, might as well just return */
if (decoder->packet_count == 0)
return 0;
+ /*
+ * The queueing process in function cs_etm_decoder__buffer_packet()
+ * increments the tail *before* using it. This is somewhat counter
+ * intuitive but it has the advantage of centralizing tail management
+ * at a single location. Because of that we need to follow the same
+ * heuristic with the head, i.e we increment it before using its
+ * value. Otherwise the first element of the packet queue is not
+ * used.
+ */
+ decoder->head = (decoder->head + 1) & (MAX_BUFFER - 1);
*packet = decoder->packet_buffer[decoder->head];
- decoder->head = (decoder->head + 1) & (MAX_BUFFER - 1);
-
decoder->packet_count--;
return 1;
--
2.14.3
^ permalink raw reply related
* [GIT PULL 0/7] perf/urgent fixes
From: Arnaldo Carvalho de Melo @ 2018-05-31 10:32 UTC (permalink / raw)
To: linux-arm-kernel
Hi Ingo,
Please consider pulling,
- Arnaldo
Test results at the end of this message, as usual.
The following changes since commit f3903c9161f0d636a7b0ff03841628928457e64c:
Merge tag 'perf-urgent-for-mingo-4.17-20180514' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent (2018-05-15 08:20:45 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-urgent-for-mingo-4.17-20180531
for you to fetch changes up to 18a7057420f8b67f15d17087bf5c0863db752c8b:
perf tools: Fix perf.data format description of NRCPUS header (2018-05-30 15:40:26 -0300)
----------------------------------------------------------------
perf/urgent fixes:
- Fix 'perf test Session topology' segfault on s390 (Thomas Richter)
- Fix NULL return handling in bpf__prepare_load() (YueHaibing)
- Fix indexing on Coresight ETM packet queue decoder (Mathieu Poirier)
- Fix perf.data format description of NRCPUS header (Arnaldo Carvalho de Melo)
- Update perf.data documentation section on cpu topology
- Handle uncore event aliases in small groups properly (Kan Liang)
- Add missing perf_sample.addr into python sample dictionary (Leo Yan)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
----------------------------------------------------------------
Arnaldo Carvalho de Melo (1):
perf tools: Fix perf.data format description of NRCPUS header
Kan Liang (1):
perf parse-events: Handle uncore event aliases in small groups properly
Leo Yan (1):
perf script python: Add addr into perf sample dict
Mathieu Poirier (1):
perf cs-etm: Fix indexing for decoder packet queue
Thomas Richter (2):
perf test: "Session topology" dumps core on s390
perf data: Update documentation section on cpu topology
YueHaibing (1):
perf bpf: Fix NULL return handling in bpf__prepare_load()
tools/perf/Documentation/perf.data-file-format.txt | 10 +-
tools/perf/tests/topology.c | 30 ++++-
tools/perf/util/bpf-loader.c | 6 +-
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 12 +-
tools/perf/util/evsel.h | 1 +
tools/perf/util/parse-events.c | 130 ++++++++++++++++++++-
tools/perf/util/parse-events.h | 7 +-
tools/perf/util/parse-events.y | 8 +-
.../util/scripting-engines/trace-event-python.c | 2 +
9 files changed, 185 insertions(+), 21 deletions(-)
Test results:
The first ones are container (docker) based builds of tools/perf with
and without libelf support. Where clang is available, it is also used
to build perf with/without libelf, and building with LIBCLANGLLVM=1
(built-in clang) with gcc and clang when clang and its devel libraries
are installed.
The objtool and samples/bpf/ builds are disabled now that I'm switching from
using the sources in a local volume to fetching them from a http server to
build it inside the container, to make it easier to build in a container cluster.
Those will come back later.
Several are cross builds, the ones with -x-ARCH and the android one, and those
may not have all the features built, due to lack of multi-arch devel packages,
available and being used so far on just a few, like
debian:experimental-x-{arm64,mipsel}.
The 'perf test' one will perform a variety of tests exercising
tools/perf/util/, tools/lib/{bpf,traceevent,etc}, as well as run perf commands
with a variety of command line event specifications to then intercept the
sys_perf_event syscall to check that the perf_event_attr fields are set up as
expected, among a variety of other unit tests.
Then there is the 'make -C tools/perf build-test' ones, that build tools/perf/
with a variety of feature sets, exercising the build with an incomplete set of
features as well as with a complete one. It is planned to have it run on each
of the containers mentioned above, using some container orchestration
infrastructure. Get in contact if interested in helping having this in place.
1 alpine:3.4 : Ok gcc (Alpine 5.3.0) 5.3.0
2 alpine:3.5 : Ok gcc (Alpine 6.2.1) 6.2.1 20160822
3 alpine:3.6 : Ok gcc (Alpine 6.3.0) 6.3.0
4 alpine:3.7 : Ok gcc (Alpine 6.4.0) 6.4.0
5 alpine:edge : Ok gcc (Alpine 6.4.0) 6.4.0
6 amazonlinux:1 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
7 amazonlinux:2 : Ok gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
8 android-ndk:r12b-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
9 android-ndk:r15c-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
10 centos:5 : Ok gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)
11 centos:6 : Ok gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18)
12 centos:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16)
13 debian:7 : Ok gcc (Debian 4.7.2-5) 4.7.2
14 debian:8 : Ok gcc (Debian 4.9.2-10+deb8u1) 4.9.2
15 debian:9 : Ok gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
16 debian:experimental : Ok gcc (Debian 7.3.0-19) 7.3.0
17 debian:experimental-x-arm64 : Ok aarch64-linux-gnu-gcc (Debian 7.3.0-19) 7.3.0
18 debian:experimental-x-mips : Ok mips-linux-gnu-gcc (Debian 7.3.0-19) 7.3.0
19 debian:experimental-x-mips64 : Ok mips64-linux-gnuabi64-gcc (Debian 7.3.0-18) 7.3.0
20 debian:experimental-x-mipsel : Ok mipsel-linux-gnu-gcc (Debian 7.3.0-19) 7.3.0
21 fedora:20 : Ok gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
22 fedora:21 : Ok gcc (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)
23 fedora:22 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
24 fedora:23 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
25 fedora:24 : Ok gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)
26 fedora:24-x-ARC-uClibc : Ok arc-linux-gcc (ARCompact ISA Linux uClibc toolchain 2017.09-rc2) 7.1.1 20170710
27 fedora:25 : Ok gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1)
28 fedora:26 : Ok gcc (GCC) 7.3.1 20180130 (Red Hat 7.3.1-2)
29 fedora:27 : Ok gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
30 fedora:28 : Ok gcc (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1)
31 fedora:rawhide : Ok gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20)
32 gentoo-stage3-amd64:latest : Ok gcc (Gentoo 6.4.0-r1 p1.3) 6.4.0
33 mageia:5 : Ok gcc (GCC) 4.9.2
34 mageia:6 : Ok gcc (Mageia 5.5.0-1.mga6) 5.5.0
35 opensuse:42.1 : Ok gcc (SUSE Linux) 4.8.5
36 opensuse:42.2 : Ok gcc (SUSE Linux) 4.8.5
37 opensuse:42.3 : Ok gcc (SUSE Linux) 4.8.5
38 opensuse:tumbleweed : Ok gcc (SUSE Linux) 7.3.1 20180323 [gcc-7-branch revision 258812]
39 oraclelinux:6 : Ok gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18.0.7)
40 oraclelinux:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28.0.1)
41 ubuntu:12.04.5 : Ok gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
42 ubuntu:14.04.4 : Ok gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
43 ubuntu:14.04.4-x-linaro-arm64 : Ok aarch64-linux-gnu-gcc (Linaro GCC 5.5-2017.10) 5.5.0
44 ubuntu:16.04 : Ok gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
45 ubuntu:16.04-x-arm : Ok arm-linux-gnueabihf-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
46 ubuntu:16.04-x-arm64 : Ok aarch64-linux-gnu-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
47 ubuntu:16.04-x-powerpc : Ok powerpc-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
48 ubuntu:16.04-x-powerpc64 : Ok powerpc64-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
49 ubuntu:16.04-x-powerpc64el : Ok powerpc64le-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
50 ubuntu:16.04-x-s390 : Ok s390x-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
51 ubuntu:16.10 : Ok gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
52 ubuntu:17.04 : Ok gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406
53 ubuntu:17.10 : Ok gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
54 ubuntu:18.04 : Ok gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
# git log --oneline -1
18a7057420f8 (HEAD -> perf/urgent) perf tools: Fix perf.data format description of NRCPUS header
# perf --version
perf version 4.17.rc5.g18a7057
# uname -a
Linux jouet 4.17.0-rc5 #21 SMP Mon May 14 15:35:35 -03 2018 x86_64 x86_64 x86_64 GNU/Linux
# perf test
1: vmlinux symtab matches kallsyms : Ok
2: Detect openat syscall event : Ok
3: Detect openat syscall event on all cpus : Ok
4: Read samples using the mmap interface : Ok
5: Test data source output : Ok
6: Parse event definition strings : Ok
7: Simple expression parser : Ok
8: PERF_RECORD_* events & perf_sample fields : Ok
9: Parse perf pmu format : Ok
10: DSO data read : Ok
11: DSO data cache : Ok
12: DSO data reopen : Ok
13: Roundtrip evsel->name : Ok
14: Parse sched tracepoints fields : Ok
15: syscalls:sys_enter_openat event fields : Ok
16: Setup struct perf_event_attr : Ok
17: Match and link multiple hists : Ok
18: 'import perf' in python : Ok
19: Breakpoint overflow signal handler : Ok
20: Breakpoint overflow sampling : Ok
21: Breakpoint accounting : Ok
22: Number of exit events of a simple workload : Ok
23: Software clock events period values : Ok
24: Object code reading : Ok
25: Sample parsing : Ok
26: Use a dummy software event to keep tracking : Ok
27: Parse with no sample_id_all bit set : Ok
28: Filter hist entries : Ok
29: Lookup mmap thread : Ok
30: Share thread mg : Ok
31: Sort output of hist entries : Ok
32: Cumulate child hist entries : Ok
33: Track with sched_switch : Ok
34: Filter fds with revents mask in a fdarray : Ok
35: Add fd to a fdarray, making it autogrow : Ok
36: kmod_path__parse : Ok
37: Thread map : Ok
38: LLVM search and compile :
38.1: Basic BPF llvm compile : Ok
38.2: kbuild searching : Ok
38.3: Compile source for BPF prologue generation : Ok
38.4: Compile source for BPF relocation : Ok
39: Session topology : Ok
40: BPF filter :
40.1: Basic BPF filtering : Ok
40.2: BPF pinning : Ok
40.3: BPF prologue generation : Ok
40.4: BPF relocation checker : Ok
41: Synthesize thread map : Ok
42: Remove thread map : Ok
43: Synthesize cpu map : Ok
44: Synthesize stat config : Ok
45: Synthesize stat : Ok
46: Synthesize stat round : Ok
47: Synthesize attr update : Ok
48: Event times : Ok
49: Read backward ring buffer : Ok
50: Print cpu map : Ok
51: Probe SDT events : Ok
52: is_printable_array : Ok
53: Print bitmap : Ok
54: perf hooks : Ok
55: builtin clang support : Skip (not compiled in)
56: unit_number__scnprintf : Ok
57: mem2node : Ok
58: x86 rdpmc : Ok
59: Convert perf time to TSC : Ok
60: DWARF unwind : Ok
61: x86 instruction decoder - new instructions : Ok
62: Use vfs_getname probe to get syscall args filenames : Ok
63: Check open filename arg using perf trace + vfs_getname: Ok
64: probe libc's inet_pton & backtrace it with ping : Ok
65: Add vfs_getname probe to get syscall args filenames : Ok
#
$ make -C tools/perf build-test
make: Entering directory '/home/acme/git/perf/tools/perf'
- tarpkg: ./tests/perf-targz-src-pkg .
make_pure_O: make
make_static_O: make LDFLAGS=-static
make_no_libpython_O: make NO_LIBPYTHON=1
make_doc_O: make doc
make_no_libdw_dwarf_unwind_O: make NO_LIBDW_DWARF_UNWIND=1
make_no_libbpf_O: make NO_LIBBPF=1
make_no_backtrace_O: make NO_BACKTRACE=1
make_install_bin_O: make install-bin
make_no_auxtrace_O: make NO_AUXTRACE=1
make_no_ui_O: make NO_NEWT=1 NO_SLANG=1 NO_GTK2=1
make_tags_O: make tags
make_install_prefix_O: make install prefix=/tmp/krava
make_clean_all_O: make clean all
make_no_libperl_O: make NO_LIBPERL=1
make_util_map_o_O: make util/map.o
make_with_babeltrace_O: make LIBBABELTRACE=1
make_perf_o_O: make perf.o
make_no_libunwind_O: make NO_LIBUNWIND=1
make_no_newt_O: make NO_NEWT=1
make_no_libaudit_O: make NO_LIBAUDIT=1
make_no_gtk2_O: make NO_GTK2=1
make_minimal_O: make NO_LIBPERL=1 NO_LIBPYTHON=1 NO_NEWT=1 NO_GTK2=1 NO_DEMANGLE=1 NO_LIBELF=1 NO_LIBUNWIND=1 NO_BACKTRACE=1 NO_LIBNUMA=1 NO_LIBAUDIT=1 NO_LIBBIONIC=1 NO_LIBDW_DWARF_UNWIND=1 NO_AUXTRACE=1 NO_LIBBPF=1 NO_LIBCRYPTO=1 NO_SDT=1 NO_JVMTI=1
make_no_scripts_O: make NO_LIBPYTHON=1 NO_LIBPERL=1
make_no_libbionic_O: make NO_LIBBIONIC=1
make_with_clangllvm_O: make LIBCLANGLLVM=1
make_install_prefix_slash_O: make install prefix=/tmp/krava/
make_no_libnuma_O: make NO_LIBNUMA=1
make_no_slang_O: make NO_SLANG=1
make_install_O: make install
make_no_libelf_O: make NO_LIBELF=1
make_util_pmu_bison_o_O: make util/pmu-bison.o
make_help_O: make help
make_debug_O: make DEBUG=1
make_no_demangle_O: make NO_DEMANGLE=1
OK
make: Leaving directory '/home/acme/git/perf/tools/perf'
$
^ permalink raw reply
* [PATCH v2 2/2] arm64/mm: make tramp_pg_dir read-only
From: Jun Yao @ 2018-05-31 10:31 UTC (permalink / raw)
To: linux-arm-kernel
Make tramp_pg_dir read-only.
Signed-off-by: Jun Yao <yaojun8558363@gmail.com>
---
arch/arm64/mm/mmu.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index a675fb88914e..2c6e6433090c 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -542,6 +542,7 @@ static int __init map_entry_trampoline(void)
{
pgprot_t prot = rodata_enabled ? PAGE_KERNEL_ROX : PAGE_KERNEL_EXEC;
phys_addr_t pa_start = __pa_symbol(__entry_tramp_text_start);
+ int segment_size;
/* The trampoline is always mapped and can therefore be global */
pgprot_val(prot) &= ~PTE_NG;
@@ -551,6 +552,11 @@ static int __init map_entry_trampoline(void)
__create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
prot, pgd_pgtable_alloc, 0);
+ segment_size = __tramp_pgdir_segment_end - __tramp_pgdir_segment_start;
+ update_mapping_prot(__pa_symbol(__tramp_pgdir_segment_start),
+ (unsigned long)__tramp_pgdir_segment_start,
+ segment_size, PAGE_KERNEL_RO);
+
/* Map both the text and data into the kernel page table */
__set_fixmap(FIX_ENTRY_TRAMP_TEXT, pa_start, prot);
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
--
2.17.0
^ permalink raw reply related
* [PATCH v2 1/2] arm64/mm: split tramp_pg_dir off from the data segment
From: Jun Yao @ 2018-05-31 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In order to make tramp_pg_dir read-only, split it off from the data
segment and create a dedicated pgdir segment for it.
Signed-off-by: Jun Yao <yaojun8558363@gmail.com>
---
arch/arm64/include/asm/sections.h | 1 +
arch/arm64/kernel/vmlinux.lds.S | 3 +++
arch/arm64/mm/mmu.c | 13 +++++++++++++
3 files changed, 17 insertions(+)
diff --git a/arch/arm64/include/asm/sections.h b/arch/arm64/include/asm/sections.h
index caab039d6305..46a6646e886b 100644
--- a/arch/arm64/include/asm/sections.h
+++ b/arch/arm64/include/asm/sections.h
@@ -29,5 +29,6 @@ extern char __inittext_begin[], __inittext_end[];
extern char __irqentry_text_start[], __irqentry_text_end[];
extern char __mmuoff_data_start[], __mmuoff_data_end[];
extern char __entry_tramp_text_start[], __entry_tramp_text_end[];
+extern char __tramp_pgdir_segment_start[], __tramp_pgdir_segment_end[];
#endif /* __ASM_SECTIONS_H */
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 605d1b60469c..c3368782171d 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -220,8 +220,11 @@ SECTIONS
. += IDMAP_DIR_SIZE;
#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
+ . = ALIGN(SEGMENT_ALIGN);
+ __tramp_pgdir_segment_start = .;
tramp_pg_dir = .;
. += PAGE_SIZE;
+ __tramp_pgdir_segment_end = .;
#endif
#ifdef CONFIG_ARM64_SW_TTBR0_PAN
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 2dbb2c9f1ec1..a675fb88914e 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -573,6 +573,9 @@ static void __init map_kernel(pgd_t *pgdp)
{
static struct vm_struct vmlinux_text, vmlinux_rodata, vmlinux_inittext,
vmlinux_initdata, vmlinux_data;
+#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
+ static struct vm_struct vmlinux_tramp_pgdir, vmlinux_data_end;
+#endif
/*
* External debuggers may need to write directly to the text
@@ -593,7 +596,17 @@ static void __init map_kernel(pgd_t *pgdp)
&vmlinux_inittext, 0, VM_NO_GUARD);
map_kernel_segment(pgdp, __initdata_begin, __initdata_end, PAGE_KERNEL,
&vmlinux_initdata, 0, VM_NO_GUARD);
+#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
+ map_kernel_segment(pgdp, _data, __tramp_pgdir_segment_start,
+ PAGE_KERNEL, &vmlinux_data, 0, VM_NO_GUARD);
+ map_kernel_segment(pgdp, __tramp_pgdir_segment_start,
+ __tramp_pgdir_segment_end, PAGE_KERNEL,
+ &vmlinux_tramp_pgdir, NO_CONT_MAPPINGS, VM_NO_GUARD);
+ map_kernel_segment(pgdp, __tramp_pgdir_segment_end, _end, PAGE_KERNEL,
+ &vmlinux_data_end, 0, 0);
+#else
map_kernel_segment(pgdp, _data, _end, PAGE_KERNEL, &vmlinux_data, 0, 0);
+#endif
if (!READ_ONCE(pgd_val(*pgd_offset_raw(pgdp, FIXADDR_START)))) {
/*
--
2.17.0
^ permalink raw reply related
* [PATCH v2 0/2] mark tramp_pg_dir read-only
From: Jun Yao @ 2018-05-31 10:30 UTC (permalink / raw)
To: linux-arm-kernel
Version 2 changes:
split tramp_pg_dir off from the data segment and create
a dedicated pgdir segment for it.
Jun Yao (2):
arm64/mm: split tramp_pg_dir off from the data segment
arm64/mm: make tramp_pg_dir read-only
arch/arm64/include/asm/sections.h | 1 +
arch/arm64/kernel/vmlinux.lds.S | 3 +++
arch/arm64/mm/mmu.c | 19 +++++++++++++++++++
3 files changed, 23 insertions(+)
--
2.17.0
^ permalink raw reply
* [PATCH v4 1/7] dt-bindings: clk: at91: add an I2S mux clock
From: Codrin Ciubotariu @ 2018-05-31 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531005827.GA17203@rob-hp-laptop>
On 31.05.2018 03:58, Rob Herring wrote:
> On Fri, May 25, 2018 at 03:34:22PM +0300, Codrin Ciubotariu wrote:
>> The I2S mux clock can be used to select the I2S input clock. The
>> available parents are the peripheral and the generated clocks.
>>
>> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
>> ---
>> .../devicetree/bindings/clock/at91-clock.txt | 34 ++++++++++++++++++++++
>> 1 file changed, 34 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt b/Documentation/devicetree/bindings/clock/at91-clock.txt
>> index 51c259a..1c46b3c 100644
>> --- a/Documentation/devicetree/bindings/clock/at91-clock.txt
>> +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
>> @@ -90,6 +90,8 @@ Required properties:
>> "atmel,sama5d2-clk-audio-pll-pmc"
>> at91 audio pll output on AUDIOPLLCLK that feeds the PMC
>> and can be used by peripheral clock or generic clock
>> + "atmel,sama5d2-clk-i2s-mux":
>> + at91 I2S clock source selection
>
> Is this boolean or takes some values. If latter, what are valid values?
This is the compatible string of the clock driver.
>
>>
>> Required properties for SCKC node:
>> - reg : defines the IO memory reserved for the SCKC.
>> @@ -507,3 +509,35 @@ For example:
>> atmel,clk-output-range = <0 83000000>;
>> };
>> };
>> +
>> +Required properties for I2S mux clocks:
>> +- #size-cells : shall be 0 (reg is used to encode I2S bus id).
>> +- #address-cells : shall be 1 (reg is used to encode I2S bus id).
>> +- name: device tree node describing a specific mux clock.
>> + * #clock-cells : from common clock binding; shall be set to 0.
>> + * clocks : shall be the mux clock parent phandles; shall be 2 phandles:
>> + peripheral and generated clock; the first phandle shall belong to the
>> + peripheral clock and the second one shall belong to the generated
>> + clock; "clock-indices" property can be user to specify
>> + the correct order.
>> + * reg: I2S bus id of the corresponding mux clock.
>> + e.g. reg = <0>; for i2s0, reg = <1>; for i2s1
>> +
>> +For example:
>> + i2s_clkmux {
>
> What is this a child of?
It is a child of PMC node, since both parent clocks are generated by PMC.
>
>> + compatible = "atmel,sama5d2-clk-i2s-mux";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>
> How do you address this block? My guess is you don't because it is just
> part of some other block and you are just creating this node to
> instantiate a driver. Just make the node for the actual h/w block a
> clock provider and define the clock ids (0 and 1).
This block is not addressed, but its children are. The register we
access in this driver is not part of other block. It's a SFR register,
accessed through syscon and it has nothing to do with the I2S IP (see
SAMA5D2 DS, page 1256, fig. 44-1: I2SC Block Diagram) that is the
consumer of this clock. Adding a clock-id property in the I2S node would
be just like v3 of this series, with the difference that we use clock-id
instead of alias id to set the clock parent, which is not how you
suggested back then.
Thank you for your review.
Best regards,
Codrin
[...]
^ permalink raw reply
* [PATCH v2 5/6] ARM: dts: Add generic interconnect target module node for MCAN
From: Faiz Abbas @ 2018-05-31 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530150402.GE5705@atomide.com>
Hi,
On Wednesday 30 May 2018 08:34 PM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180530 14:12]:
>> The ti-sysc driver provides support for manipulating the idlemodes
>> and interconnect level resets.
> ...
>> --- a/arch/arm/boot/dts/dra76x.dtsi
>> +++ b/arch/arm/boot/dts/dra76x.dtsi
>> @@ -11,6 +11,25 @@
>> / {
>> compatible = "ti,dra762", "ti,dra7";
>>
>> + ocp {
>> +
>> + target-module at 0x42c00000 {
>> + compatible = "ti,sysc-dra7-mcan";
>> + ranges = <0x0 0x42c00000 0x2000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + reg = <0x42c01900 0x4>,
>> + <0x42c01904 0x4>,
>> + <0x42c01908 0x4>;
>> + reg-names = "rev", "sysc", "syss";
>> + ti,sysc-mask = <(SYSC_OMAP4_SOFTRESET |
>> + SYSC_DRA7_MCAN_ENAWAKEUP)>;
>> + ti,syss-mask = <1>;
>> + clocks = <&wkupaon_clkctrl DRA7_ADC_CLKCTRL 0>;
>> + clock-names = "fck";
>> + };
>> + };
>> +
>> };
>
> Looks good to me except I think the reset won't do anything currently
> with ti-sysc.c unless you specfify also "ti,hwmods" for the module?
>
> Can you please check? It might be worth adding the reset function to
> ti-sysc.c for non "ti,hwmods" case and that just might remove the
> need for any hwmod code for this module.
>
If I understand correctly, this involves adding a (*reset_module) in
ti_sysc_platform_data and defining a ti_sysc_reset_module() in ti-sysc.c
similar to ti_sysc_idle_module(). Right?
Thanks,
Faiz
^ permalink raw reply
* [PATCH v2 4/6] bus: ti-sysc: Add support for using ti-sysc for MCAN on dra76x
From: Faiz Abbas @ 2018-05-31 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530145726.GD5705@atomide.com>
Hi,
On Wednesday 30 May 2018 08:27 PM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180530 14:12]:
>> The dra76x MCAN generic interconnect module has a its own
>> format for the bits in the control registers.
...
>> static int sysc_init_pdata(struct sysc *ddata)
>> {
>> struct ti_sysc_platform_data *pdata = dev_get_platdata(ddata->dev);
>> @@ -1441,6 +1457,7 @@ static const struct of_device_id sysc_match[] = {
>> { .compatible = "ti,sysc-mcasp", .data = &sysc_omap4_mcasp, },
>> { .compatible = "ti,sysc-usb-host-fs",
>> .data = &sysc_omap4_usb_host_fs, },
>> + { .compatible = "ti,sysc-dra7-mcan", .data = &sysc_dra7_mcan, },
>> { },
>> };
>
> Looks good to me. And presumably you checked that no other dra7 modules
> use sysconfig register bit layout like this?
>
As far as I could see, Yes.
Thanks,
Faiz
^ permalink raw reply
* [PATCH v2 3/6] clk: ti: dra7: Add clkctrl clock data for the mcan clocks
From: Faiz Abbas @ 2018-05-31 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531040350.GA25132@rob-hp-laptop>
Hi,
On Thursday 31 May 2018 09:33 AM, Rob Herring wrote:
> On Wed, May 30, 2018 at 07:41:30PM +0530, Faiz Abbas wrote:
>> Add clkctrl data for the m_can clocks and register it within the
...
>>
>> diff --git a/include/dt-bindings/clock/dra7.h b/include/dt-bindings/clock/dra7.h
>> index 5e1061b15aed..d7549c57cac3 100644
>> --- a/include/dt-bindings/clock/dra7.h
>> +++ b/include/dt-bindings/clock/dra7.h
>> @@ -168,5 +168,6 @@
>> #define DRA7_COUNTER_32K_CLKCTRL DRA7_CLKCTRL_INDEX(0x50)
>> #define DRA7_UART10_CLKCTRL DRA7_CLKCTRL_INDEX(0x80)
>> #define DRA7_DCAN1_CLKCTRL DRA7_CLKCTRL_INDEX(0x88)
>> +#define DRA7_ADC_CLKCTRL DRA7_CLKCTRL_INDEX(0xa0)
>
> ADC and mcan are the same thing?
>
The register to control MCAN clocks is called ADC_CLKCTRL, Yes.
Thanks,
Faiz
^ permalink raw reply
* [PATCH v5 10/15] ARM: spectre-v2: warn about incorrect context switching functions
From: Russell King - ARM Linux @ 2018-05-31 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b91753a0-7c47-1e46-6884-4643a90afdc7@arm.com>
On Thu, May 31, 2018 at 11:07:18AM +0100, Marc Zyngier wrote:
> > I notice that you haven't replied to some of the patches (7 and 8),
> > which makes me think that you have an issue with them - and as tonight
> > is likely the last linux-next before the merge window, we're basically
> > out of time to do another respin if there's something you don't like
> > there and if we want to get them in during the next merge window.
> Patches 7 and 8 didn't compile for me, and I had to fix-up things
> manually in order to test it. Not that it should hold you back from
> merging it.
As noted in a reply to the cover, I made a mistake merging some changes
in that resulted in a simple-to-fix build error (a 'void' instead of a
'bool' return type.) I wasn't going to send the series out for a third
time on the same day just because of that.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v5 10/15] ARM: spectre-v2: warn about incorrect context switching functions
From: Marc Zyngier @ 2018-05-31 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531094922.GQ17671@n2100.armlinux.org.uk>
On 31/05/18 10:49, Russell King - ARM Linux wrote:
> On Tue, May 29, 2018 at 06:02:28PM +0100, Marc Zyngier wrote:
>> On Tue, 29 May 2018 15:55:01 +0100,
>> Russell King wrote:
>>>
>>> Warn at error level if the context switching function is not what we
>>> are expecting. This can happen with big.Little systems, which we
>>> currently do not support.
>>>
>>> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>>> Boot-tested-by: Tony Lindgren <tony@atomide.com>
>>> Reviewed-by: Tony Lindgren <tony@atomide.com>
>>
>> I assume this is a temporary situation until the ARM port grows the
>> necessary infrastructure to support this mitigation on heterogeneous
>> systems.
>
> As I've said, I think that is going to be a very difficult problem to
> resolve. I detailed why in previous emails, but it seems each time I
> do that, no one bothers to respond (presumably because no one has any
> ideas how to sort that problem either.)
>
> I believe that it's better to get some of the mitigations in the kernel
> and warn about non-supported setups than it is to hold it back.
I agree with you that it is better to get this merged quickly, and then
address exotic configurations (which are unfortunately quite common
these days) separately. I haven't had the time to try and understand how
to fix it though.
> I notice that you haven't replied to some of the patches (7 and 8),
> which makes me think that you have an issue with them - and as tonight
> is likely the last linux-next before the merge window, we're basically
> out of time to do another respin if there's something you don't like
> there and if we want to get them in during the next merge window.
Patches 7 and 8 didn't compile for me, and I had to fix-up things
manually in order to test it. Not that it should hold you back from
merging it.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v5 10/15] ARM: spectre-v2: warn about incorrect context switching functions
From: Russell King - ARM Linux @ 2018-05-31 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <86r2lu9yzf.wl-marc.zyngier@arm.com>
On Tue, May 29, 2018 at 06:02:28PM +0100, Marc Zyngier wrote:
> On Tue, 29 May 2018 15:55:01 +0100,
> Russell King wrote:
> >
> > Warn at error level if the context switching function is not what we
> > are expecting. This can happen with big.Little systems, which we
> > currently do not support.
> >
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > Boot-tested-by: Tony Lindgren <tony@atomide.com>
> > Reviewed-by: Tony Lindgren <tony@atomide.com>
>
> I assume this is a temporary situation until the ARM port grows the
> necessary infrastructure to support this mitigation on heterogeneous
> systems.
As I've said, I think that is going to be a very difficult problem to
resolve. I detailed why in previous emails, but it seems each time I
do that, no one bothers to respond (presumably because no one has any
ideas how to sort that problem either.)
I believe that it's better to get some of the mitigations in the kernel
and warn about non-supported setups than it is to hold it back.
I notice that you haven't replied to some of the patches (7 and 8),
which makes me think that you have an issue with them - and as tonight
is likely the last linux-next before the merge window, we're basically
out of time to do another respin if there's something you don't like
there and if we want to get them in during the next merge window.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] arm64: allwinner: a64-amarula-relic: Enable AP6330 WiFi support
From: Maxime Ripard @ 2018-05-31 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529172238.9718-1-jagan@amarulasolutions.com>
Hi,
On Tue, May 29, 2018 at 10:52:38PM +0530, Jagan Teki wrote:
> +&rtc {
> + clock-output-names = "rtc-osc32k", "rtc-osc32k-out";
> + clocks = <&osc32k>;
> + #clock-cells = <1>;
> +};
It should be in the DTSI
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/20180531/51f74d7b/attachment.sig>
^ permalink raw reply
* [PATCH v4] rtc: sun6i: Fix bit_idx value for clk_register_gate
From: Alexandre Belloni @ 2018-05-31 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530182744.27611-1-jagan@amarulasolutions.com>
On 30/05/2018 23:57:44+0530, Jagan Teki wrote:
> From: Michael Trimarchi <michael@amarulasolutions.com>
>
> clk-gate core will take bit_idx through clk_register_gate
> and then do clk_gate_ops by using BIT(bit_idx), but rtc-sun6i
> is passing bit_idx as BIT(bit_idx) it becomes BIT(BIT(bit_idx)
> which is wrong and eventually external gate clock is not enabling.
>
> This patch fixed by passing bit index and the original change
> introduced from below commit.
> "rtc: sun6i: Add support for the external oscillator gate"
> (sha1: 17ecd246414b3a0fe0cb248c86977a8bda465b7b)
>
> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> Fixes: 17ecd246414b ("rtc: sun6i: Add support for the external oscillator gate")
> Cc: stable at vger.kernel.org
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v4:
> - Cc to stable tree
> Changes for v3:
> - add fixes tag
> - Cced stable ML
> Changes for v2:
> - add suffix _OFFSET with macro name to distinguish b/w
> register actual values vs offset.
>
> drivers/rtc/rtc-sun6i.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH 06/15] drm/sun4i: tcon: Add support for tcon-top
From: Maxime Ripard @ 2018-05-31 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65whE-qW++cg+gu_o2O1dDdCWkumQB41nt3Aqa75Wp3dg@mail.gmail.com>
On Thu, May 24, 2018 at 03:01:09PM -0700, Chen-Yu Tsai wrote:
> >> > > + if (tcon->quirks->needs_tcon_top) {
> >> > > + struct device_node *np;
> >> > > +
> >> > > + np = of_parse_phandle(dev->of_node, "allwinner,tcon-top", 0);
> >> > > + if (np) {
> >> > > + struct platform_device *pdev;
> >> > > +
> >> > > + pdev = of_find_device_by_node(np);
> >> > > + if (pdev)
> >> > > + tcon->tcon_top = platform_get_drvdata(pdev);
> >> > > + of_node_put(np);
> >> > > +
> >> > > + if (!tcon->tcon_top)
> >> > > + return -EPROBE_DEFER;
> >> > > + }
> >> > > + }
> >> > > +
> >> >
> >> > I might have missed it, but I've not seen the bindings additions for
> >> > that property. This shouldn't really be done that way anyway, instead
> >> > of using a direct phandle, you should be using the of-graph, with the
> >> > TCON-top sitting where it belongs in the flow of data.
> >>
> >> Just to answer to the first question, it did describe it in "[PATCH 07/15] dt-
> >> bindings: display: sun4i-drm: Add R40 HDMI pipeline".
> >>
> >> As why I designed it that way - HW representation could be described that way
> >> (ASCII art makes sense when fixed width font is used to view it):
> >>
> >> / LCD0/LVDS0
> >> / TCON-LCD0
> >> | \ MIPI DSI
> >> mixer0 |
> >> \ / TCON-LCD1 - LCD1/LVDS1
> >> TCON-TOP
> >> / \ TCON-TV0 - TVE0/RGB
> >> mixer1 | \
> >> | TCON-TOP - HDMI
> >> | /
> >> \ TCON-TV1 - TVE1/RGB
> >>
> >> This is a bit simplified, since there is also TVE-TOP, which is responsible
> >> for sharing 4 DACs between both TVE encoders. You can have two TV outs (PAL/
> >> NTSC) or TVE0 as TV out and TVE1 as RGB or vice versa. It even seems that you
> >> can arbitrarly choose which DAC is responsible for which signal, so there is a
> >> ton of possible end combinations, but I'm not 100% sure.
> >>
> >> Even though I wrote TCON-TOP twice, this is same unit in HW. R40 manual
> >> suggest more possibilities, although some of them seem wrong, like RGB feeding
> >> from LCD TCON. That is confirmed to be wrong when checking BSP code.
> >>
> >> Additionally, TCON-TOP comes in the middle of TVE0 and LCD0, TVE1 and LCD1 for
> >> pin muxing, although I'm not sure why is that needed at all, since according
> >> to R40 datasheet, TVE0 and TVE1 pins are dedicated and not on PORT D and PORT
> >> H, respectively, as TCON-TOP documentation suggest. However, HSYNC and PSYNC
> >> lines might be shared between TVE (when it works in RGB mode) and LCD. But
> >> that is just my guess since I'm not really familiar with RGB and LCD
> >> interfaces.
> >>
> >> I'm really not sure what would be the best representation in OF-graph. Can you
> >> suggest one?
> >
> > Rob might disagree on this one, but I don't see anything wrong with
> > having loops in the graph. If the TCON-TOP can be both the input and
> > output of the TCONs, then so be it, and have it described that way in
> > the graph.
> >
> > The code is already able to filter out nodes that have already been
> > added to the list of devices we need to wait for in the component
> > framework, so that should work as well.
> >
> > And we'd need to describe TVE-TOP as well, even though we don't have a
> > driver for it yet. That will simplify the backward compatibility later
> > on.
>
> I'm getting the feeling that TCON-TOP / TVE-TOP is the glue layer that
> binds everything together, and provides signal routing, kind of like
> DE-TOP on A64. So the signal mux controls that were originally found
> in TCON0 and TVE0 were moved out.
>
> The driver needs to know about that, but the graph about doesn't make
> much sense directly. Without looking at the manual, I understand it to
> likely be one mux between the mixers and TCONs, and one between the
> TCON-TVs and HDMI. Would it make more sense to just have the graph
> connections between the muxed components, and remove TCON-TOP from
> it, like we had in the past? A phandle could be used to reference
> the TCON-TOP for mux controls, in addition to the clocks and resets.
>
> For TVE, we would need something to represent each of the output pins,
> so the device tree can actually describe what kind of signal, be it
> each component of RGB/YUV or composite video, is wanted on each pin,
> if any. This is also needed on the A20 for the Cubietruck, so we can
> describe which pins are tied to the VGA connector, and which one does
> R, G, or B.
I guess we'll see how the DT maintainers feel about this, but my
impression is that the OF graph should model the flow of data between
the devices. If there's a mux somewhere, then the data is definitely
going through it, and as such it should be part of the graph.
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/20180531/7ee82b7f/attachment-0001.sig>
^ permalink raw reply
* [PATCH] usb: chipidea: Fix ULPI on imx51
From: Nikita Yushchenko @ 2018-05-31 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530173414.6121-1-andrew.smirnov@gmail.com>
> Workaround introduced for i.MX53 in be9cae2479f48 ("usb: chipidea:
> imx: Fix ULPI on imx53") seems to be applicable in case of i.MX51 as
> well. Running latest kernel on ZII RDU1 Board (imx51-zii-rdu1.dts)
> exhibits a kernel frozen on PORTSC access and applying the workaround
> resolves the issue.
Confirmed on 8.9'' RDU1
Tested-By: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
^ permalink raw reply
* usb: host: ohci: fix sfr kernel warning in ohci-at91 driver
From: Nicolas Ferre @ 2018-05-31 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527285896-12811-1-git-send-email-Prasanthi.Chellakumar@microchip.com>
On 26/05/2018 at 00:04, Prasanthi Chellakumar wrote:
> The USB Host Controller driver 'ohci-at91.c' reads a Special Function
> Register - OHCI Interrupt Configuration Register (AT91_SFR_OHCIICR)
> for bits SUSPEND_A/B/C. These bits are defined in sama5d2 alone, so
> sfr register mapping is done with compatible string "atmel,sama5d2-sfr".
> This gives a kernel warning 'failed to find sfr node' with non sama5d2
> cpus which is removed here, thus leaving it up to having a proper DTS.
>
> Signed-off-by: Prasanthi Chellakumar <prasanthi.chellakumar@microchip.com>
> Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Thanks Prasanthi. Best regards,
Nicolas
> ---
>
> The AT91_SFR_OHCIIR register is read for USB suspend and wake
> up control. The OHCI driver has a sfr register mapping for sama5d2
> alone. The USB suspend proceeds only when there is valid sfr regmap.
> So SFR access in boards that it is absent is not required. In such
> boards, USB suspend control requests is processed by usb_hub_control().
> But there is a kernel warning with non sama5d2 cpus. This patch fixes
> the kernel warning, changing to debug message(dev_dbg).
> ---
> drivers/usb/host/ohci-at91.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
> index af0566d..ce11c47 100644
> --- a/drivers/usb/host/ohci-at91.c
> +++ b/drivers/usb/host/ohci-at91.c
> @@ -214,7 +214,7 @@ static int usb_hcd_at91_probe(const struct hc_driver *driver,
>
> ohci_at91->sfr_regmap = at91_dt_syscon_sfr();
> if (!ohci_at91->sfr_regmap)
> - dev_warn(dev, "failed to find sfr node\n");
> + dev_dbg(dev, "failed to find sfr node\n");
>
> board = hcd->self.controller->platform_data;
> ohci = hcd_to_ohci(hcd);
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v2 0/9] PM / Domains: Add support for multi PM domains per device
From: Viresh Kumar @ 2018-05-31 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529100421.31022-1-ulf.hansson@linaro.org>
On 29-05-18, 12:04, Ulf Hansson wrote:
> Changes in v2:
> - Addressed comments from Geert around DT doc.
> - Addressed comments from Jon around clarification of how to use this
> and changes to returned error codes.
> - Fixed build error in case CONFIG_PM was unset.
>
> There are devices that are partitioned across multiple PM domains. Currently
> these can't be supported well by the available PM infrastructures we have in
> the kernel. This series is an attempt to address this.
>
> The interesting parts happens from patch 5 an onwards, including a minor DT
> update to the existing power-domain bindings, the 4 earlier are just trivial
> clean-ups of some related code in genpd, which I happened to stumble over.
>
> Some additional background:
>
> One existing case where devices are partitioned across multiple PM domains, is
> the Nvida Tegra 124/210 X-USB subsystem. A while ago Jon Hunter (Nvidia) sent a
> series, trying to address these issues, however this is a new approach, while
> it re-uses the same concepts from DT point of view.
>
> The Tegra 124/210 X-USB subsystem contains of a host controller and a device
> controller. Each controller have its own independent PM domain, but are being
> partitioned across another shared PM domain for the USB super-speed logic.
>
> Currently to make the drivers work, either the related PM domains needs to stay
> powered on always or the PM domain topology needs to be in-correctly modelled
> through sub-domains. In both cases PM domains may be powered on while they
> don't need to be, so in the end this means - wasting power -.
>
> As stated above, this series intends to address these problem from a PM
> infrastructure point of view. More details are available in each changelog.
>
> It should be noted that this series has been tested on HW, however only by using
> a home-cooked test PM domain driver for genpd and together with a test driver.
> This allowed me to play with PM domain (genpd), runtime PM and device links.
>
> Any further deployment for real use cases are greatly appreciated. I am happy to
> to help, if needed!
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH v2] ARM: dts: imx51-zii-rdu1: Make sure SD1_WP is low
From: Nikita Yushchenko @ 2018-05-31 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180526021238.30753-1-andrew.smirnov@gmail.com>
> Make sure that MX51_PAD_GPIO1_1 does not remain configure as
> ALT0/SD1_WP (it is out of reset). This is needed because of external
> pull-up resistor attached to that pad that, when left unchanged, will
> drive SD1_WP high preventing eSDHC1/eMMC from working correctly.
>
> To fix that add a pinmux configuration line configureing the pad to
> function as a GPIO. While we are at it, add a corresponding
> output-high GPIO hog in an effort to minimize current consumption.
>
> Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Chris Healy <cphealy@gmail.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: devicetree at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Tested-By: Nikita Yushchenko <nikita.yoush@cogentembedded.com
Tested on 8.9'' RDU1. Without this patch, eMMC does not work, get
[ 40.801367] mmc0: Timeout waiting for hardware interrupt.
[ 40.806789] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
... <dump follows>
With this patch, eMMC works correctly.
Nikita
^ permalink raw reply
* [PATCH v4 5/5] ARM: dts: imx6qdl: add missing compatible and clock properties for EPIT
From: Vladimir Zapolskiy @ 2018-05-31 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJiuCcefvMg6r=06O8m1TYa0hat_dHydcoJ7PN58qUru1K8zMQ@mail.gmail.com>
Hi Cl?ment,
On 05/31/2018 11:41 AM, Cl?ment P?ron wrote:
> Hi Vladimir,
>
> On Thu, 31 May 2018 at 10:33, Vladimir Zapolskiy
> <vladimir_zapolskiy@mentor.com> wrote:
>>
>> On 05/30/2018 03:03 PM, Cl?ment P?ron wrote:
>>> From: Colin Didier <colin.didier@devialet.com>
>>>
>>> Add missing compatible and clock properties for EPIT node.
>>>
>>> Signed-off-by: Colin Didier <colin.didier@devialet.com>
>>> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
>>> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
>>> ---
>>> arch/arm/boot/dts/imx6qdl.dtsi | 10 ++++++++++
>>> 1 file changed, 10 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
>>> index c003e62bf290..0feec516847a 100644
>>> --- a/arch/arm/boot/dts/imx6qdl.dtsi
>>> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
>>> @@ -844,13 +844,23 @@
>>> };
>>>
>>> epit1: epit at 20d0000 { /* EPIT1 */
>>
>> epit1: timer at 20d0000 { ...
>>
>> And /* EPIT1 */ comment can be removed, it is quite clear from the same
>> line context.
>>
>> Formally it is a subject to another patch, but I think this can be
>> accepted as a part of this one.
>
> Should I also update other boards ?
> I only did it for imx6qdl.dtsi, but the EPIT is present in other boards
> but i can't test it myself.
>
Sure, please do it, why not, it is quite a safe modification.
One change per one dtsi file will suffice, and I see that imx25.dtsi
already contains the requested change, however probably you may
want to update its compatible = "fsl,imx25-epit" line.
Regarding compatibles for other imx6* SoCs, I think all of them should
be documented in fsl,imxepit.txt and then added to the correspondent
dtsi files one per SoC.
And I forgot the outcome of one former discussion with Uwe Kleine-K?nig,
but if my bad memory serves me, we agreed that i.MX25 was released later
than i.MX31, so the most generic (the last value in the list) compatible
should be a compatible with i.MX31 like in
imx25.dtsi:367: compatible = "fsl,imx25-gpt", "fsl,imx31-gpt";
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH] media: helene: fix tuning frequency of satellite
From: Katsuhiro Suzuki @ 2018-05-31 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK3bHNW8=z2WH6xCijAP2XCX94iE5z-HwHRYNhbJwZvbOav10A@mail.gmail.com>
Hello Abylay,
I got a mistake in this patch.
DTV_FREQUENCY for satellite delivery systems, the frequency is in 'kHz' not 'Hz',
so original code is correct. Sorry for confusing...
Regards,
--
Katsuhiro Suzuki
> -----Original Message-----
> From: Abylay Ospan <aospan@netup.ru>
> Sent: Wednesday, May 16, 2018 7:58 PM
> To: Suzuki, Katsuhiro/?? ?? <suzuki.katsuhiro@socionext.com>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>; linux-media
> <linux-media@vger.kernel.org>; Masami Hiramatsu <masami.hiramatsu@linaro.org>;
> Jassi Brar <jaswinder.singh@linaro.org>; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org
> Subject: Re: [PATCH] media: helene: fix tuning frequency of satellite
>
> True.
> I'm curious but how did it worked before ...
> Which hardware (dvb adapter) are you using ?
>
> 2018-05-16 4:41 GMT-04:00 Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>:
> > This patch fixes tuning frequency of satellite to kHz. That as same
> > as terrestrial one.
> >
> > Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
> > ---
> > drivers/media/dvb-frontends/helene.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/dvb-frontends/helene.c
> b/drivers/media/dvb-frontends/helene.c
> > index 04033f0c278b..0a4f312c4368 100644
> > --- a/drivers/media/dvb-frontends/helene.c
> > +++ b/drivers/media/dvb-frontends/helene.c
> > @@ -523,7 +523,7 @@ static int helene_set_params_s(struct dvb_frontend *fe)
> > enum helene_tv_system_t tv_system;
> > struct dtv_frontend_properties *p = &fe->dtv_property_cache;
> > struct helene_priv *priv = fe->tuner_priv;
> > - int frequencykHz = p->frequency;
> > + int frequencykHz = p->frequency / 1000;
> > uint32_t frequency4kHz = 0;
> > u32 symbol_rate = p->symbol_rate/1000;
> >
> > --
> > 2.17.0
> >
>
>
>
> --
> Abylay Ospan,
> NetUP Inc.
> http://www.netup.tv
^ permalink raw reply
* [PATCH v4 5/5] ARM: dts: imx6qdl: add missing compatible and clock properties for EPIT
From: Clément Péron @ 2018-05-31 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a4042956-24e1-6132-4606-b5b8f4e30023@mentor.com>
Hi Vladimir,
On Thu, 31 May 2018 at 10:33, Vladimir Zapolskiy
<vladimir_zapolskiy@mentor.com> wrote:
>
> On 05/30/2018 03:03 PM, Cl?ment P?ron wrote:
> > From: Colin Didier <colin.didier@devialet.com>
> >
> > Add missing compatible and clock properties for EPIT node.
> >
> > Signed-off-by: Colin Didier <colin.didier@devialet.com>
> > Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
> > Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
> > ---
> > arch/arm/boot/dts/imx6qdl.dtsi | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> > index c003e62bf290..0feec516847a 100644
> > --- a/arch/arm/boot/dts/imx6qdl.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> > @@ -844,13 +844,23 @@
> > };
> >
> > epit1: epit at 20d0000 { /* EPIT1 */
>
> epit1: timer at 20d0000 { ...
>
> And /* EPIT1 */ comment can be removed, it is quite clear from the same
> line context.
>
> Formally it is a subject to another patch, but I think this can be
> accepted as a part of this one.
Should I also update other boards ?
I only did it for imx6qdl.dtsi, but the EPIT is present in other boards
but i can't test it myself.
>
> > + compatible = "fsl,imx6q-epit", "fsl,imx31-epit";
> > reg = <0x020d0000 0x4000>;
> > interrupts = <0 56 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6QDL_CLK_IPG_PER>,
> > + <&clks IMX6QDL_CLK_EPIT1>;
> > + clock-names = "ipg", "per";
> > + status = "disabled";
> > };
> >
> > epit2: epit at 20d4000 { /* EPIT2 */
>
> Same as above.
>
> > + compatible = "fsl,imx6q-epit", "fsl,imx31-epit";
> > reg = <0x020d4000 0x4000>;
> > interrupts = <0 57 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6QDL_CLK_IPG_PER>,
> > + <&clks IMX6QDL_CLK_EPIT2>;
> > + clock-names = "ipg", "per";
> > + status = "disabled";
> > };
> >
> > src: src at 20d8000 {
> >
>
> --
> With best wishes,
> Vladimir
^ permalink raw reply
* [PATCH] kbuild: add machine size to CHEKCFLAGS
From: Daniel Thompson @ 2018-05-31 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530204838.22079-1-luc.vanoostenryck@gmail.com>
On Wed, May 30, 2018 at 10:48:38PM +0200, Luc Van Oostenryck wrote:
> By default, sparse assumes a 64bit machine when compiled on x86-64
> and 32bit when compiled on anything else.
>
> This can of course create all sort of problems for the other archs, like
> issuing false warnings ('shift too big (32) for type unsigned long'), or
> worse, failing to emit legitimate warnings.
>
> Fix this by adding the -m32/-m64 flag, depending on CONFIG_64BIT,
> to CHECKFLAGS in the main Makefile (and so for all archs).
> Also, remove the now unneeded -m32/-m64 in arch specific Makefiles.
>
> Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Looks like a good clean up to me. However the typo in the Subject: line
did attract my attention.
Daniel.
> ---
> Makefile | 3 +++
> arch/alpha/Makefile | 2 +-
> arch/arm/Makefile | 2 +-
> arch/arm64/Makefile | 2 +-
> arch/ia64/Makefile | 2 +-
> arch/mips/Makefile | 3 ---
> arch/parisc/Makefile | 2 +-
> arch/sparc/Makefile | 2 +-
> arch/x86/Makefile | 2 +-
> 9 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 6c6610913..18379987c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -881,6 +881,9 @@ endif
> # insure the checker run with the right endianness
> CHECKFLAGS += $(if $(CONFIG_CPU_BIG_ENDIAN),-mbig-endian,-mlittle-endian)
>
> +# the checker needs the correct machine size
> +CHECKFLAGS += $(if $(CONFIG_64BIT),-m64,-m32)
> +
> # Default kernel image to build when no specific target is given.
> # KBUILD_IMAGE may be overruled on the command line or
> # set in the environment
> diff --git a/arch/alpha/Makefile b/arch/alpha/Makefile
> index 2cc3cc519..c5ec8c09c 100644
> --- a/arch/alpha/Makefile
> +++ b/arch/alpha/Makefile
> @@ -11,7 +11,7 @@
> NM := $(NM) -B
>
> LDFLAGS_vmlinux := -static -N #-relax
> -CHECKFLAGS += -D__alpha__ -m64
> +CHECKFLAGS += -D__alpha__
> cflags-y := -pipe -mno-fp-regs -ffixed-8
> cflags-y += $(call cc-option, -fno-jump-tables)
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index e4e537f27..f32a5468d 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -135,7 +135,7 @@ endif
> KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
> KBUILD_AFLAGS +=$(CFLAGS_ABI) $(AFLAGS_ISA) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
>
> -CHECKFLAGS += -D__arm__ -m32
> +CHECKFLAGS += -D__arm__
>
> #Default value
> head-y := arch/arm/kernel/head$(MMUEXT).o
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 87f7d2f9f..3c353b471 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -78,7 +78,7 @@ LDFLAGS += -maarch64linux
> UTS_MACHINE := aarch64
> endif
>
> -CHECKFLAGS += -D__aarch64__ -m64
> +CHECKFLAGS += -D__aarch64__
>
> ifeq ($(CONFIG_ARM64_MODULE_PLTS),y)
> KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/arm64/kernel/module.lds
> diff --git a/arch/ia64/Makefile b/arch/ia64/Makefile
> index 2dd7f519a..45f59808b 100644
> --- a/arch/ia64/Makefile
> +++ b/arch/ia64/Makefile
> @@ -18,7 +18,7 @@ READELF := $(CROSS_COMPILE)readelf
>
> export AWK
>
> -CHECKFLAGS += -m64 -D__ia64=1 -D__ia64__=1 -D_LP64 -D__LP64__
> +CHECKFLAGS += -D__ia64=1 -D__ia64__=1 -D_LP64 -D__LP64__
>
> OBJCOPYFLAGS := --strip-all
> LDFLAGS_vmlinux := -static
> diff --git a/arch/mips/Makefile b/arch/mips/Makefile
> index 5e9fce076..e2122cca4 100644
> --- a/arch/mips/Makefile
> +++ b/arch/mips/Makefile
> @@ -309,9 +309,6 @@ ifdef CONFIG_MIPS
> CHECKFLAGS += $(shell $(CC) $(KBUILD_CFLAGS) -dM -E -x c /dev/null | \
> egrep -vw '__GNUC_(|MINOR_|PATCHLEVEL_)_' | \
> sed -e "s/^\#define /-D'/" -e "s/ /'='/" -e "s/$$/'/" -e 's/\$$/&&/g')
> -ifdef CONFIG_64BIT
> -CHECKFLAGS += -m64
> -endif
> endif
>
> OBJCOPYFLAGS += --remove-section=.reginfo
> diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile
> index 348ae4779..714284ea6 100644
> --- a/arch/parisc/Makefile
> +++ b/arch/parisc/Makefile
> @@ -28,7 +28,7 @@ export LIBGCC
>
> ifdef CONFIG_64BIT
> UTS_MACHINE := parisc64
> -CHECKFLAGS += -D__LP64__=1 -m64
> +CHECKFLAGS += -D__LP64__=1
> CC_ARCHES = hppa64
> LD_BFD := elf64-hppa-linux
> else # 32-bit
> diff --git a/arch/sparc/Makefile b/arch/sparc/Makefile
> index edac927e4..966a13d2b 100644
> --- a/arch/sparc/Makefile
> +++ b/arch/sparc/Makefile
> @@ -39,7 +39,7 @@ else
> # sparc64
> #
>
> -CHECKFLAGS += -D__sparc__ -D__sparc_v9__ -D__arch64__ -m64
> +CHECKFLAGS += -D__sparc__ -D__sparc_v9__ -D__arch64__
> LDFLAGS := -m elf64_sparc
> export BITS := 64
> UTS_MACHINE := sparc64
> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> index 60135cbd9..f0a6ea224 100644
> --- a/arch/x86/Makefile
> +++ b/arch/x86/Makefile
> @@ -94,7 +94,7 @@ ifeq ($(CONFIG_X86_32),y)
> else
> BITS := 64
> UTS_MACHINE := x86_64
> - CHECKFLAGS += -D__x86_64__ -m64
> + CHECKFLAGS += -D__x86_64__
>
> biarch := -m64
> KBUILD_AFLAGS += -m64
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH v4 4/5] clocksource: add driver for i.MX EPIT timer
From: Vladimir Zapolskiy @ 2018-05-31 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530120327.27681-5-peron.clem@gmail.com>
Hi Cl?ment,
On 05/30/2018 03:03 PM, Cl?ment P?ron wrote:
> From: Colin Didier <colin.didier@devialet.com>
>
> Add driver for NXP's EPIT timer used in i.MX 6 family of SoC.
>
> Signed-off-by: Colin Didier <colin.didier@devialet.com>
> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
> ---
[snip]
> +++ b/drivers/clocksource/timer-imx-epit.c
> @@ -0,0 +1,281 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * i.MX EPIT Timer
> + *
> + * Copyright (C) 2010 Sascha Hauer <s.hauer@pengutronix.de>
> + * Copyright (C) 2018 Colin Didier <colin.didier@devialet.com>
> + * Copyright (C) 2018 Cl?ment P?ron <clement.peron@devialet.com>
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clockchips.h>
> +#include <linux/err.h>
The included header above still can be removed.
I have no more comments about the code, I will try to find time to
test the driver, but please don't take it as a promise.
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v4 5/5] ARM: dts: imx6qdl: add missing compatible and clock properties for EPIT
From: Vladimir Zapolskiy @ 2018-05-31 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530120327.27681-6-peron.clem@gmail.com>
On 05/30/2018 03:03 PM, Cl?ment P?ron wrote:
> From: Colin Didier <colin.didier@devialet.com>
>
> Add missing compatible and clock properties for EPIT node.
>
> Signed-off-by: Colin Didier <colin.didier@devialet.com>
> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> arch/arm/boot/dts/imx6qdl.dtsi | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index c003e62bf290..0feec516847a 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -844,13 +844,23 @@
> };
>
> epit1: epit at 20d0000 { /* EPIT1 */
epit1: timer at 20d0000 { ...
And /* EPIT1 */ comment can be removed, it is quite clear from the same
line context.
Formally it is a subject to another patch, but I think this can be
accepted as a part of this one.
> + compatible = "fsl,imx6q-epit", "fsl,imx31-epit";
> reg = <0x020d0000 0x4000>;
> interrupts = <0 56 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX6QDL_CLK_IPG_PER>,
> + <&clks IMX6QDL_CLK_EPIT1>;
> + clock-names = "ipg", "per";
> + status = "disabled";
> };
>
> epit2: epit at 20d4000 { /* EPIT2 */
Same as above.
> + compatible = "fsl,imx6q-epit", "fsl,imx31-epit";
> reg = <0x020d4000 0x4000>;
> interrupts = <0 57 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX6QDL_CLK_IPG_PER>,
> + <&clks IMX6QDL_CLK_EPIT2>;
> + clock-names = "ipg", "per";
> + status = "disabled";
> };
>
> src: src at 20d8000 {
>
--
With best wishes,
Vladimir
^ permalink raw reply
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