* [PATCH V3 1/5] hw_breakpoint: Allow watchpoint of length 3,5,6 and 7
From: Pratyush Anand @ 2016-11-14 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479130617.git.panand@redhat.com>
We only support breakpoint/watchpoint of length 1, 2, 4 and 8. If we can
support other length as well, then user may watch more data with less
number of watchpoints (provided hardware supports it). For example: if we
have to watch only 4th, 5th and 6th byte from a 64 bit aligned address, we
will have to use two slots to implement it currently. One slot will watch a
half word at offset 4 and other a byte at offset 6. If we can have a
watchpoint of length 3 then we can watch it with single slot as well.
ARM64 hardware does support such functionality, therefore adding these new
definitions in generic layer.
Signed-off-by: Pratyush Anand <panand@redhat.com>
---
include/uapi/linux/hw_breakpoint.h | 4 ++++
tools/include/uapi/linux/hw_breakpoint.h | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/include/uapi/linux/hw_breakpoint.h b/include/uapi/linux/hw_breakpoint.h
index b04000a2296a..2b65efd19a46 100644
--- a/include/uapi/linux/hw_breakpoint.h
+++ b/include/uapi/linux/hw_breakpoint.h
@@ -4,7 +4,11 @@
enum {
HW_BREAKPOINT_LEN_1 = 1,
HW_BREAKPOINT_LEN_2 = 2,
+ HW_BREAKPOINT_LEN_3 = 3,
HW_BREAKPOINT_LEN_4 = 4,
+ HW_BREAKPOINT_LEN_5 = 5,
+ HW_BREAKPOINT_LEN_6 = 6,
+ HW_BREAKPOINT_LEN_7 = 7,
HW_BREAKPOINT_LEN_8 = 8,
};
diff --git a/tools/include/uapi/linux/hw_breakpoint.h b/tools/include/uapi/linux/hw_breakpoint.h
index b04000a2296a..2b65efd19a46 100644
--- a/tools/include/uapi/linux/hw_breakpoint.h
+++ b/tools/include/uapi/linux/hw_breakpoint.h
@@ -4,7 +4,11 @@
enum {
HW_BREAKPOINT_LEN_1 = 1,
HW_BREAKPOINT_LEN_2 = 2,
+ HW_BREAKPOINT_LEN_3 = 3,
HW_BREAKPOINT_LEN_4 = 4,
+ HW_BREAKPOINT_LEN_5 = 5,
+ HW_BREAKPOINT_LEN_6 = 6,
+ HW_BREAKPOINT_LEN_7 = 7,
HW_BREAKPOINT_LEN_8 = 8,
};
--
2.7.4
^ permalink raw reply related
* [PATCH V3 2/5] arm64: Allow hw watchpoint at varied offset from base address
From: Pratyush Anand @ 2016-11-14 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479130617.git.panand@redhat.com>
ARM64 hardware supports watchpoint at any double word aligned address.
However, it can select any consecutive bytes from offset 0 to 7 from that
base address. For example, if base address is programmed as 0x420030 and
byte select is 0x1C, then access of 0x420032,0x420033 and 0x420034 will
generate a watchpoint exception.
Currently, we do not have such modularity. We can only program byte,
halfword, word and double word access exception from any base address.
This patch adds support to overcome above limitations.
Signed-off-by: Pratyush Anand <panand@redhat.com>
---
arch/arm64/include/asm/hw_breakpoint.h | 2 +-
arch/arm64/kernel/hw_breakpoint.c | 47 +++++++++++++++++-----------------
arch/arm64/kernel/ptrace.c | 7 ++---
3 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/arch/arm64/include/asm/hw_breakpoint.h b/arch/arm64/include/asm/hw_breakpoint.h
index 9510ace570e2..d1c3b06ad307 100644
--- a/arch/arm64/include/asm/hw_breakpoint.h
+++ b/arch/arm64/include/asm/hw_breakpoint.h
@@ -119,7 +119,7 @@ struct perf_event;
struct pmu;
extern int arch_bp_generic_fields(struct arch_hw_breakpoint_ctrl ctrl,
- int *gen_len, int *gen_type);
+ int *gen_len, int *gen_type, int *offset);
extern int arch_check_bp_in_kernelspace(struct perf_event *bp);
extern int arch_validate_hwbkpt_settings(struct perf_event *bp);
extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused,
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index 948b73148d56..3f7bc65e7ef6 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -349,7 +349,7 @@ int arch_check_bp_in_kernelspace(struct perf_event *bp)
* to generic breakpoint descriptions.
*/
int arch_bp_generic_fields(struct arch_hw_breakpoint_ctrl ctrl,
- int *gen_len, int *gen_type)
+ int *gen_len, int *gen_type, int *offset)
{
/* Type */
switch (ctrl.type) {
@@ -369,8 +369,12 @@ int arch_bp_generic_fields(struct arch_hw_breakpoint_ctrl ctrl,
return -EINVAL;
}
+ if (!ctrl.len)
+ return -EINVAL;
+ *offset = __ffs(ctrl.len);
+
/* Len */
- switch (ctrl.len) {
+ switch (ctrl.len >> *offset) {
case ARM_BREAKPOINT_LEN_1:
*gen_len = HW_BREAKPOINT_LEN_1;
break;
@@ -517,18 +521,17 @@ int arch_validate_hwbkpt_settings(struct perf_event *bp)
default:
return -EINVAL;
}
-
- info->address &= ~alignment_mask;
- info->ctrl.len <<= offset;
} else {
if (info->ctrl.type == ARM_BREAKPOINT_EXECUTE)
alignment_mask = 0x3;
else
alignment_mask = 0x7;
- if (info->address & alignment_mask)
- return -EINVAL;
+ offset = info->address & alignment_mask;
}
+ info->address &= ~alignment_mask;
+ info->ctrl.len <<= offset;
+
/*
* Disallow per-task kernel breakpoints since these would
* complicate the stepping code.
@@ -665,8 +668,8 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
{
int i, step = 0, *kernel_step, access;
- u32 ctrl_reg;
- u64 val, alignment_mask;
+ u32 ctrl_reg, lens, lene;
+ u64 val;
struct perf_event *wp, **slots;
struct debug_info *debug_info;
struct arch_hw_breakpoint *info;
@@ -684,25 +687,21 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
goto unlock;
info = counter_arch_bp(wp);
- /* AArch32 watchpoints are either 4 or 8 bytes aligned. */
- if (is_compat_task()) {
- if (info->ctrl.len == ARM_BREAKPOINT_LEN_8)
- alignment_mask = 0x7;
- else
- alignment_mask = 0x3;
- } else {
- alignment_mask = 0x7;
- }
- /* Check if the watchpoint value matches. */
+ /* Check if the watchpoint value and byte select match. */
val = read_wb_reg(AARCH64_DBG_REG_WVR, i);
- if (val != (addr & ~alignment_mask))
- goto unlock;
-
- /* Possible match, check the byte address select to confirm. */
ctrl_reg = read_wb_reg(AARCH64_DBG_REG_WCR, i);
decode_ctrl_reg(ctrl_reg, &ctrl);
- if (!((1 << (addr & alignment_mask)) & ctrl.len))
+ lens = ffs(ctrl.len) - 1;
+ lene = fls(ctrl.len) - 1;
+ /*
+ * FIXME: reported address can be anywhere between "the
+ * lowest address accessed by the memory access that
+ * triggered the watchpoint" and "the highest watchpointed
+ * address accessed by the memory access". So, it may not
+ * lie in the interval of watchpoint address range.
+ */
+ if (addr < val + lens || addr > val + lene)
goto unlock;
/*
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index e0c81da60f76..fc35e06ccaac 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -327,13 +327,13 @@ static int ptrace_hbp_fill_attr_ctrl(unsigned int note_type,
struct arch_hw_breakpoint_ctrl ctrl,
struct perf_event_attr *attr)
{
- int err, len, type, disabled = !ctrl.enabled;
+ int err, len, type, offset, disabled = !ctrl.enabled;
attr->disabled = disabled;
if (disabled)
return 0;
- err = arch_bp_generic_fields(ctrl, &len, &type);
+ err = arch_bp_generic_fields(ctrl, &len, &type, &offset);
if (err)
return err;
@@ -352,6 +352,7 @@ static int ptrace_hbp_fill_attr_ctrl(unsigned int note_type,
attr->bp_len = len;
attr->bp_type = type;
+ attr->bp_addr += offset;
return 0;
}
@@ -404,7 +405,7 @@ static int ptrace_hbp_get_addr(unsigned int note_type,
if (IS_ERR(bp))
return PTR_ERR(bp);
- *addr = bp ? bp->attr.bp_addr : 0;
+ *addr = bp ? counter_arch_bp(bp)->address : 0;
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH V3 3/5] arm64: hw_breakpoint: Handle inexact watchpoint addresses
From: Pratyush Anand @ 2016-11-14 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479130617.git.panand@redhat.com>
From: Pavel Labath <test.tberghammer@gmail.com>
Arm64 hardware does not always report a watchpoint hit address that
matches one of the watchpoints set. It can also report an address
"near" the watchpoint if a single instruction access both watched and
unwatched addresses. There is no straight-forward way, short of
disassembling the offending instruction, to map that address back to
the watchpoint.
Previously, when the hardware reported a watchpoint hit on an address
that did not match our watchpoint (this happens in case of instructions
which access large chunks of memory such as "stp") the process would
enter a loop where we would be continually resuming it (because we did
not recognise that watchpoint hit) and it would keep hitting the
watchpoint again and again. The tracing process would never get
notified of the watchpoint hit.
This commit fixes the problem by looking at the watchpoints near the
address reported by the hardware. If the address does not exactly match
one of the watchpoints we have set, it attributes the hit to the
nearest watchpoint we have. This heuristic is a bit dodgy, but I don't
think we can do much more, given the hardware limitations.
[panand: reworked to rebase on his patches]
Signed-off-by: Pavel Labath <labath@google.com>
Signed-off-by: Pratyush Anand <panand@redhat.com>
---
arch/arm64/kernel/hw_breakpoint.c | 96 ++++++++++++++++++++++++++++-----------
1 file changed, 69 insertions(+), 27 deletions(-)
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index 3f7bc65e7ef6..f69bf368d916 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -664,11 +664,46 @@ static int breakpoint_handler(unsigned long unused, unsigned int esr,
}
NOKPROBE_SYMBOL(breakpoint_handler);
+/*
+ * Arm64 hardware does not always report a watchpoint hit address that matches
+ * one of the watchpoints set. It can also report an address "near" the
+ * watchpoint if a single instruction access both watched and unwatched
+ * addresses. There is no straight-forward way, short of disassembling the
+ * offending instruction, to map that address back to the watchpoint. This
+ * function computes the distance of the memory access from the watchpoint as a
+ * heuristic for the likelyhood that a given access triggered the watchpoint.
+ *
+ * See Section D2.10.5 "Determining the memory location that caused a Watchpoint
+ * exception" of ARMv8 Architecture Reference Manual for details.
+ *
+ * The function returns the distance of the address from the bytes watched by
+ * the watchpoint. In case of an exact match, it returns 0.
+ */
+static u64 get_distance_from_watchpoint(unsigned long addr, u64 val,
+ struct arch_hw_breakpoint_ctrl *ctrl)
+{
+ u64 wp_low, wp_high;
+ u32 lens, lene;
+
+ lens = ffs(ctrl->len) - 1;
+ lene = fls(ctrl->len) - 1;
+
+ wp_low = val + lens;
+ wp_high = val + lene;
+ if (addr < wp_low)
+ return wp_low - addr;
+ else if (addr > wp_high)
+ return addr - wp_high;
+ else
+ return 0;
+}
+
static int watchpoint_handler(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
{
- int i, step = 0, *kernel_step, access;
- u32 ctrl_reg, lens, lene;
+ int i, step = 0, *kernel_step, access, closest_match = 0;
+ u64 min_dist = -1, dist;
+ u32 ctrl_reg;
u64 val;
struct perf_event *wp, **slots;
struct debug_info *debug_info;
@@ -678,31 +713,15 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
slots = this_cpu_ptr(wp_on_reg);
debug_info = ¤t->thread.debug;
+ /*
+ * Find all watchpoints that match the reported address. If no exact
+ * match is found. Attribute the hit to the closest watchpoint.
+ */
+ rcu_read_lock();
for (i = 0; i < core_num_wrps; ++i) {
- rcu_read_lock();
-
wp = slots[i];
-
if (wp == NULL)
- goto unlock;
-
- info = counter_arch_bp(wp);
-
- /* Check if the watchpoint value and byte select match. */
- val = read_wb_reg(AARCH64_DBG_REG_WVR, i);
- ctrl_reg = read_wb_reg(AARCH64_DBG_REG_WCR, i);
- decode_ctrl_reg(ctrl_reg, &ctrl);
- lens = ffs(ctrl.len) - 1;
- lene = fls(ctrl.len) - 1;
- /*
- * FIXME: reported address can be anywhere between "the
- * lowest address accessed by the memory access that
- * triggered the watchpoint" and "the highest watchpointed
- * address accessed by the memory access". So, it may not
- * lie in the interval of watchpoint address range.
- */
- if (addr < val + lens || addr > val + lene)
- goto unlock;
+ continue;
/*
* Check that the access type matches.
@@ -711,18 +730,41 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
access = (esr & AARCH64_ESR_ACCESS_MASK) ? HW_BREAKPOINT_W :
HW_BREAKPOINT_R;
if (!(access & hw_breakpoint_type(wp)))
- goto unlock;
+ continue;
+ /* Check if the watchpoint value and byte select match. */
+ val = read_wb_reg(AARCH64_DBG_REG_WVR, i);
+ ctrl_reg = read_wb_reg(AARCH64_DBG_REG_WCR, i);
+ decode_ctrl_reg(ctrl_reg, &ctrl);
+ dist = get_distance_from_watchpoint(addr, val, &ctrl);
+ if (dist < min_dist) {
+ min_dist = dist;
+ closest_match = i;
+ }
+ /* Is this an exact match? */
+ if (dist != 0)
+ continue;
+
+ info = counter_arch_bp(wp);
info->trigger = addr;
perf_bp_event(wp, regs);
/* Do we need to handle the stepping? */
if (is_default_overflow_handler(wp))
step = 1;
+ }
+ if (min_dist > 0 && min_dist != -1) {
+ /* No exact match found. */
+ wp = slots[closest_match];
+ info = counter_arch_bp(wp);
+ info->trigger = addr;
+ perf_bp_event(wp, regs);
-unlock:
- rcu_read_unlock();
+ /* Do we need to handle the stepping? */
+ if (is_default_overflow_handler(wp))
+ step = 1;
}
+ rcu_read_unlock();
if (!step)
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH V3 4/5] arm64: Allow hw watchpoint of length 3,5,6 and 7
From: Pratyush Anand @ 2016-11-14 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479130617.git.panand@redhat.com>
Since, arm64 can support all offset within a double word limit. Therefore,
now support other lengths within that range as well.
Signed-off-by: Pratyush Anand <panand@redhat.com>
---
arch/arm64/include/asm/hw_breakpoint.h | 4 ++++
arch/arm64/kernel/hw_breakpoint.c | 36 ++++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
diff --git a/arch/arm64/include/asm/hw_breakpoint.h b/arch/arm64/include/asm/hw_breakpoint.h
index d1c3b06ad307..b6b167ac082b 100644
--- a/arch/arm64/include/asm/hw_breakpoint.h
+++ b/arch/arm64/include/asm/hw_breakpoint.h
@@ -77,7 +77,11 @@ static inline void decode_ctrl_reg(u32 reg,
/* Lengths */
#define ARM_BREAKPOINT_LEN_1 0x1
#define ARM_BREAKPOINT_LEN_2 0x3
+#define ARM_BREAKPOINT_LEN_3 0x7
#define ARM_BREAKPOINT_LEN_4 0xf
+#define ARM_BREAKPOINT_LEN_5 0x1f
+#define ARM_BREAKPOINT_LEN_6 0x3f
+#define ARM_BREAKPOINT_LEN_7 0x7f
#define ARM_BREAKPOINT_LEN_8 0xff
/* Kernel stepping */
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index f69bf368d916..504d075a1351 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -317,9 +317,21 @@ static int get_hbp_len(u8 hbp_len)
case ARM_BREAKPOINT_LEN_2:
len_in_bytes = 2;
break;
+ case ARM_BREAKPOINT_LEN_3:
+ len_in_bytes = 3;
+ break;
case ARM_BREAKPOINT_LEN_4:
len_in_bytes = 4;
break;
+ case ARM_BREAKPOINT_LEN_5:
+ len_in_bytes = 5;
+ break;
+ case ARM_BREAKPOINT_LEN_6:
+ len_in_bytes = 6;
+ break;
+ case ARM_BREAKPOINT_LEN_7:
+ len_in_bytes = 7;
+ break;
case ARM_BREAKPOINT_LEN_8:
len_in_bytes = 8;
break;
@@ -381,9 +393,21 @@ int arch_bp_generic_fields(struct arch_hw_breakpoint_ctrl ctrl,
case ARM_BREAKPOINT_LEN_2:
*gen_len = HW_BREAKPOINT_LEN_2;
break;
+ case ARM_BREAKPOINT_LEN_3:
+ *gen_len = HW_BREAKPOINT_LEN_3;
+ break;
case ARM_BREAKPOINT_LEN_4:
*gen_len = HW_BREAKPOINT_LEN_4;
break;
+ case ARM_BREAKPOINT_LEN_5:
+ *gen_len = HW_BREAKPOINT_LEN_5;
+ break;
+ case ARM_BREAKPOINT_LEN_6:
+ *gen_len = HW_BREAKPOINT_LEN_6;
+ break;
+ case ARM_BREAKPOINT_LEN_7:
+ *gen_len = HW_BREAKPOINT_LEN_7;
+ break;
case ARM_BREAKPOINT_LEN_8:
*gen_len = HW_BREAKPOINT_LEN_8;
break;
@@ -427,9 +451,21 @@ static int arch_build_bp_info(struct perf_event *bp)
case HW_BREAKPOINT_LEN_2:
info->ctrl.len = ARM_BREAKPOINT_LEN_2;
break;
+ case HW_BREAKPOINT_LEN_3:
+ info->ctrl.len = ARM_BREAKPOINT_LEN_3;
+ break;
case HW_BREAKPOINT_LEN_4:
info->ctrl.len = ARM_BREAKPOINT_LEN_4;
break;
+ case HW_BREAKPOINT_LEN_5:
+ info->ctrl.len = ARM_BREAKPOINT_LEN_5;
+ break;
+ case HW_BREAKPOINT_LEN_6:
+ info->ctrl.len = ARM_BREAKPOINT_LEN_6;
+ break;
+ case HW_BREAKPOINT_LEN_7:
+ info->ctrl.len = ARM_BREAKPOINT_LEN_7;
+ break;
case HW_BREAKPOINT_LEN_8:
info->ctrl.len = ARM_BREAKPOINT_LEN_8;
break;
--
2.7.4
^ permalink raw reply related
* [PATCH V3 5/5] selftests: arm64: add test for unaligned/inexact watchpoint handling
From: Pratyush Anand @ 2016-11-14 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479130617.git.panand@redhat.com>
ARM64 hardware expects 64bit aligned address for watchpoint invocation.
However, it provides byte selection method to select any number of
consecutive byte set within the range of 1-8.
This patch adds support to test all such byte selection option for
different memory write sizes.
Patch also adds a test for handling the case when the cpu does not
report an address which exactly matches one of the regions we have
been watching (which is a situation permitted by the spec if an
instruction accesses both watched and unwatched regions). The test
was failing on a MSM8996pro before this patch series and is
passing now.
Signed-off-by: Pavel Labath <labath@google.com>
Signed-off-by: Pratyush Anand <panand@redhat.com>
---
tools/testing/selftests/breakpoints/Makefile | 5 +-
.../selftests/breakpoints/breakpoint_test_arm64.c | 236 +++++++++++++++++++++
2 files changed, 240 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
diff --git a/tools/testing/selftests/breakpoints/Makefile b/tools/testing/selftests/breakpoints/Makefile
index 74e533fd4bc5..61b79e8df1f4 100644
--- a/tools/testing/selftests/breakpoints/Makefile
+++ b/tools/testing/selftests/breakpoints/Makefile
@@ -5,6 +5,9 @@ ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/x86/ -e s/x86_64/x86/)
ifeq ($(ARCH),x86)
TEST_PROGS := breakpoint_test
endif
+ifeq ($(ARCH),aarch64)
+TEST_PROGS := breakpoint_test_arm64
+endif
TEST_PROGS += step_after_suspend_test
@@ -13,4 +16,4 @@ all: $(TEST_PROGS)
include ../lib.mk
clean:
- rm -fr breakpoint_test step_after_suspend_test
+ rm -fr breakpoint_test breakpoint_test_arm64 step_after_suspend_test
diff --git a/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c b/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
new file mode 100644
index 000000000000..3897e996541e
--- /dev/null
+++ b/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
@@ -0,0 +1,236 @@
+/*
+ * Copyright (C) 2016 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Original Code by Pavel Labath <labath@google.com>
+ *
+ * Code modified by Pratyush Anand <panand@redhat.com>
+ * for testing different byte select for each access size.
+ *
+ */
+
+#define _GNU_SOURCE
+
+#include <sys/types.h>
+#include <sys/wait.h>
+#include <sys/ptrace.h>
+#include <sys/param.h>
+#include <sys/uio.h>
+#include <stdint.h>
+#include <stdbool.h>
+#include <stddef.h>
+#include <string.h>
+#include <stdio.h>
+#include <unistd.h>
+#include <elf.h>
+#include <errno.h>
+#include <signal.h>
+
+#include "../kselftest.h"
+
+static volatile uint8_t var[96] __attribute__((__aligned__(32)));
+
+static void child(int size, int wr)
+{
+ volatile uint8_t *addr = &var[32 + wr];
+
+ if (ptrace(PTRACE_TRACEME, 0, NULL, NULL) != 0) {
+ perror("ptrace(PTRACE_TRACEME) failed");
+ _exit(1);
+ }
+
+ if (raise(SIGSTOP) != 0) {
+ perror("raise(SIGSTOP) failed");
+ _exit(1);
+ }
+
+ if ((uintptr_t) addr % size) {
+ perror("Wrong address write for the given size\n");
+ _exit(1);
+ }
+ switch (size) {
+ case 1:
+ *addr = 47;
+ break;
+ case 2:
+ *(uint16_t *)addr = 47;
+ break;
+ case 4:
+ *(uint32_t *)addr = 47;
+ break;
+ case 8:
+ *(uint64_t *)addr = 47;
+ break;
+ case 16:
+ __asm__ volatile ("stp x29, x30, %0" : "=m" (addr[0]));
+ break;
+ case 32:
+ __asm__ volatile ("stp q29, q30, %0" : "=m" (addr[0]));
+ break;
+ }
+
+ _exit(0);
+}
+
+static bool set_watchpoint(pid_t pid, int size, int wp)
+{
+ const volatile uint8_t *addr = &var[32 + wp];
+ const int offset = (uintptr_t)addr % 8;
+ const unsigned int byte_mask = ((1 << size) - 1) << offset;
+ const unsigned int type = 2; /* Write */
+ const unsigned int enable = 1;
+ const unsigned int control = byte_mask << 5 | type << 3 | enable;
+ struct user_hwdebug_state dreg_state;
+ struct iovec iov;
+
+ memset(&dreg_state, 0, sizeof(dreg_state));
+ dreg_state.dbg_regs[0].addr = (uintptr_t)(addr - offset);
+ dreg_state.dbg_regs[0].ctrl = control;
+ iov.iov_base = &dreg_state;
+ iov.iov_len = offsetof(struct user_hwdebug_state, dbg_regs) +
+ sizeof(dreg_state.dbg_regs[0]);
+ if (ptrace(PTRACE_SETREGSET, pid, NT_ARM_HW_WATCH, &iov) == 0)
+ return true;
+
+ if (errno == EIO) {
+ printf("ptrace(PTRACE_SETREGSET, NT_ARM_HW_WATCH) "
+ "not supported on this hardware\n");
+ ksft_exit_skip();
+ }
+ perror("ptrace(PTRACE_SETREGSET, NT_ARM_HW_WATCH) failed");
+ return false;
+}
+
+static bool run_test(int wr_size, int wp_size, int wr, int wp)
+{
+ int status;
+ siginfo_t siginfo;
+ pid_t pid = fork();
+ pid_t wpid;
+
+ if (pid < 0) {
+ perror("fork() failed");
+ return false;
+ }
+ if (pid == 0)
+ child(wr_size, wr);
+
+ wpid = waitpid(pid, &status, __WALL);
+ if (wpid != pid) {
+ perror("waitpid() failed");
+ return false;
+ }
+ if (!WIFSTOPPED(status)) {
+ printf("child did not stop\n");
+ return false;
+ }
+ if (WSTOPSIG(status) != SIGSTOP) {
+ printf("child did not stop with SIGSTOP\n");
+ return false;
+ }
+
+ if (!set_watchpoint(pid, wp_size, wp))
+ return false;
+
+ if (ptrace(PTRACE_CONT, pid, NULL, NULL) < 0) {
+ perror("ptrace(PTRACE_SINGLESTEP) failed");
+ return false;
+ }
+
+ alarm(3);
+ wpid = waitpid(pid, &status, __WALL);
+ if (wpid != pid) {
+ perror("waitpid() failed");
+ return false;
+ }
+ alarm(0);
+ if (WIFEXITED(status)) {
+ printf("child did not single-step\t");
+ return false;
+ }
+ if (!WIFSTOPPED(status)) {
+ printf("child did not stop\n");
+ return false;
+ }
+ if (WSTOPSIG(status) != SIGTRAP) {
+ printf("child did not stop with SIGTRAP\n");
+ return false;
+ }
+ if (ptrace(PTRACE_GETSIGINFO, pid, NULL, &siginfo) != 0) {
+ perror("ptrace(PTRACE_GETSIGINFO)");
+ return false;
+ }
+ if (siginfo.si_code != TRAP_HWBKPT) {
+ printf("Unexpected si_code %d\n", siginfo.si_code);
+ return false;
+ }
+
+ kill(pid, SIGKILL);
+ wpid = waitpid(pid, &status, 0);
+ if (wpid != pid) {
+ perror("waitpid() failed");
+ return false;
+ }
+ return true;
+}
+
+static void sigalrm(int sig)
+{
+}
+
+int main(int argc, char **argv)
+{
+ int opt;
+ bool succeeded = true;
+ struct sigaction act;
+ int wr, wp, size;
+ bool result;
+
+ act.sa_handler = sigalrm;
+ sigemptyset(&act.sa_mask);
+ act.sa_flags = 0;
+ sigaction(SIGALRM, &act, NULL);
+ for (size = 1; size <= 32; size = size*2) {
+ for (wr = 0; wr <= 32; wr = wr + size) {
+ for (wp = wr - size; wp <= wr + size; wp = wp + size) {
+ printf("Test size = %d write offset = %d watchpoint offset = %d\t", size, wr, wp);
+ result = run_test(size, MIN(size, 8), wr, wp);
+ if ((result && wr == wp) || (!result && wr != wp)) {
+ printf("[OK]\n");
+ ksft_inc_pass_cnt();
+ } else {
+ printf("[FAILED]\n");
+ ksft_inc_fail_cnt();
+ succeeded = false;
+ }
+ }
+ }
+ }
+
+ for (size = 1; size <= 32; size = size*2) {
+ printf("Test size = %d write offset = %d watchpoint offset = -8\t", size, -size);
+
+ if (run_test(size, 8, -size, -8)) {
+ printf("[OK]\n");
+ ksft_inc_pass_cnt();
+ } else {
+ printf("[FAILED]\n");
+ ksft_inc_fail_cnt();
+ succeeded = false;
+ }
+ }
+
+ ksft_print_cnts();
+ if (succeeded)
+ ksft_exit_pass();
+ else
+ ksft_exit_fail();
+}
--
2.7.4
^ permalink raw reply related
* [PATCH 1/4] fpga mgr: Introduce FPGA capabilities
From: atull @ 2016-11-14 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107001326.7395-2-moritz.fischer@ettus.com>
On Mon, 7 Nov 2016, Moritz Fischer wrote:
> Add FPGA capabilities as a way to express the capabilities
> of a given FPGA manager.
>
> Removes code duplication by comparing the low-level driver's
> capabilities at the framework level rather than having each driver
> check for supported operations in the write_init() callback.
>
> This allows for extending with additional capabilities, similar
> to the the dmaengine framework's implementation.
>
> Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
> Cc: Alan Tull <atull@opensource.altera.com>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: S?ren Brinkmann <soren.brinkmann@xilinx.com>
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> ---
>
> Changes from RFC:
> * in the RFC the caps weren't actually stored into the struct fpga_mgr
>
> Note:
>
> If people disagree on the typedef being a 'false positive' I can fix
> that in a future rev of the patchset.
>
> Thanks,
>
> Moritz
>
> ---
> drivers/fpga/fpga-mgr.c | 15 ++++++++++++++
> drivers/fpga/socfpga.c | 10 +++++-----
> drivers/fpga/zynq-fpga.c | 7 ++++++-
> include/linux/fpga/fpga-mgr.h | 46 ++++++++++++++++++++++++++++++++++++++++++-
> 4 files changed, 71 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> index 953dc91..ed57c17 100644
> --- a/drivers/fpga/fpga-mgr.c
> +++ b/drivers/fpga/fpga-mgr.c
> @@ -49,6 +49,18 @@ int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, const char *buf,
> struct device *dev = &mgr->dev;
> int ret;
>
> + if (flags & FPGA_MGR_PARTIAL_RECONFIG &&
> + !fpga_mgr_has_cap(FPGA_MGR_CAP_PARTIAL_RECONF, mgr->caps)) {
> + dev_err(dev, "Partial reconfiguration not supported\n");
> + return -ENOTSUPP;
> + }
> +
> + if (flags & FPGA_MGR_FULL_RECONFIG &&
> + !fpga_mgr_has_cap(FPGA_MGR_CAP_FULL_RECONF, mgr->caps)) {
> + dev_err(dev, "Full reconfiguration not supported\n");
> + return -ENOTSUPP;
> + }
> +
Could you move the checks to their own function like
'fpga_mgr_check_caps()' or something? I really like it if we can keep
the functions short, like a screen or so where it's practicle to do
so and I could see the number of caps growing here. The only
counter argument I could think of is if a cap affects the sequence
in this function. Hmmm...
Alan
^ permalink raw reply
* [PATCH v6 7/9] drm/hisilicon/hibmc: Add connector for VDAC
From: Rongrong Zou @ 2016-11-14 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOw6vbJA3Oe3GmRZBZjF24wtu_5hyTdVL2HK-1p3BLbiY1G7Tw@mail.gmail.com>
? 2016/11/11 9:45, Sean Paul ??:
> On Fri, Oct 28, 2016 at 3:28 AM, Rongrong Zou <zourongrong@gmail.com> wrote:
>> Add connector funcs and helper funcs for VDAC.
>>
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>> ---
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 8 +++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 +
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 76 ++++++++++++++++++++++++
>> 3 files changed, 86 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> index ba191e1..4253603 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> @@ -131,6 +131,14 @@ static int hibmc_kms_init(struct hibmc_drm_device *hidev)
>> return ret;
>> }
>>
>> + ret = hibmc_connector_init(hidev);
>> + if (ret) {
>> + DRM_ERROR("failed to init connector\n");
>> + return ret;
>> + }
>> +
>> + drm_mode_connector_attach_encoder(&hidev->connector,
>> + &hidev->encoder);
>
> The connector should be initialized in the vdac driver with the
> encoder, not in the drv file (same as plane/crtc)
applied, thanks.
>
>> return 0;
>> }
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> index 401cea4..450247d 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> @@ -48,6 +48,7 @@ struct hibmc_drm_device {
>> struct drm_plane plane;
>> struct drm_crtc crtc;
>> struct drm_encoder encoder;
>> + struct drm_connector connector;
>
> No need to keep track here
will allocate with devm_kzalloc(), thanks.
>
>> bool mode_config_initialized;
>>
>> /* ttm */
>> @@ -89,6 +90,7 @@ static inline struct hibmc_bo *gem_to_hibmc_bo(struct drm_gem_object *gem)
>> int hibmc_plane_init(struct hibmc_drm_device *hidev);
>> int hibmc_crtc_init(struct hibmc_drm_device *hidev);
>> int hibmc_encoder_init(struct hibmc_drm_device *hidev);
>> +int hibmc_connector_init(struct hibmc_drm_device *hidev);
>> int hibmc_fbdev_init(struct hibmc_drm_device *hidev);
>> void hibmc_fbdev_fini(struct hibmc_drm_device *hidev);
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
>> index 953f659..ebefcd1 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
>> @@ -87,3 +87,79 @@ int hibmc_encoder_init(struct hibmc_drm_device *hidev)
>> drm_encoder_helper_add(encoder, &hibmc_encoder_helper_funcs);
>> return 0;
>> }
>> +
>> +static int hibmc_connector_get_modes(struct drm_connector *connector)
>> +{
>> + int count;
>> +
>> + count = drm_add_modes_noedid(connector, 800, 600);
>> + drm_set_preferred_mode(connector, defx, defy);
>
> So you have defx/defy as module parameters, but then hardcode the
> 800x600 mode. If defx/defy is anything other than 800/600, this won't
> work. I think you should just remove the defx/defy module params and
> rely on userspace adding modes as appropriate.
will remove them, thanks.
>
>> + return count;
>> +}
>> +
>> +static int hibmc_connector_mode_valid(struct drm_connector *connector,
>> + struct drm_display_mode *mode)
>> +{
>> + struct hibmc_drm_device *hiprivate =
>> + container_of(connector, struct hibmc_drm_device, connector);
>> + unsigned long size = mode->hdisplay * mode->vdisplay * 4;
>
> Why * 4 here and why * 2 below? You support formats less than 32 bpp,
> so the * 4 isn't necessarily correct for all formats. Is the * 2 to
> account for front & back buffer?
>
it is from bochs, the original comments below:
/*
* Make sure we can fit two framebuffers into video memory.
* This allows up to 1600x1200 with 16 MB (default size).
* If you want more try this:
* 'qemu -vga std -global VGA.vgamem_mb=32 $otherargs'
*/
i think it is not necessary for hibmc, so will remove it and return
MODE_OK, thanks.
>
>> +
>> + if (size * 2 > hiprivate->fb_size)
>> + return MODE_BAD;
>> +
>> + return MODE_OK;
>> +}
>> +
>> +static struct drm_encoder *
>> +hibmc_connector_best_encoder(struct drm_connector *connector)
>> +{
>> + int enc_id = connector->encoder_ids[0];
>> +
>> + /* pick the encoder ids */
>> + if (enc_id)
>> + return drm_encoder_find(connector->dev, enc_id);
>
> Can't you just do return drm_encoder_find(connector->dev,
> connector->encoder_ids[0]); ?
>
> ie: won't drm_encoder_find do the right thing if you pass in id == 0?
hibmc_connector_best_encoder(struct drm_connector *connector)
{
return drm_encoder_find(connector->dev, connector->encoder_ids[0]);
}
looks more simple, i like it, thanks:)
>
>> +
>> + return NULL;
>> +}
>> +
>> +static enum drm_connector_status hibmc_connector_detect(struct drm_connector
>> + *connector, bool force)
>> +{
>> + return connector_status_connected;
>
> Perhaps this should be connector_status_unknown, since you don't
> necessarily know it's connected.
it is always connected in hibmc's scenario, usually it is used as a
management chip on server, we use KVM(keyboard, mouse, video) rather than
a directly connected monitor. I will modify if a phisical monitor
is connected later.
>
>> +}
>> +
>> +static const struct drm_connector_helper_funcs
>> + hibmc_connector_connector_helper_funcs = {
>> + .get_modes = hibmc_connector_get_modes,
>> + .mode_valid = hibmc_connector_mode_valid,
>> + .best_encoder = hibmc_connector_best_encoder,
>> +};
>> +
>> +static const struct drm_connector_funcs hibmc_connector_connector_funcs = {
>> + .dpms = drm_atomic_helper_connector_dpms,
>> + .detect = hibmc_connector_detect,
>> + .fill_modes = drm_helper_probe_single_connector_modes,
>> + .destroy = drm_connector_cleanup,
>> + .reset = drm_atomic_helper_connector_reset,
>> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
>> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>> +};
>> +
>> +int hibmc_connector_init(struct hibmc_drm_device *hidev)
>> +{
>> + struct drm_device *dev = hidev->dev;
>> + struct drm_connector *connector = &hidev->connector;
>> + int ret;
>> +
>> + ret = drm_connector_init(dev, connector,
>> + &hibmc_connector_connector_funcs,
>> + DRM_MODE_CONNECTOR_VGA);
>> + if (ret) {
>> + DRM_ERROR("failed to init connector\n");
>> + return ret;
>> + }
>> + drm_connector_helper_add(connector,
>> + &hibmc_connector_connector_helper_funcs);
>> +
>> + return 0;
>> +}
>> --
>> 1.9.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> _______________________________________________
> linuxarm mailing list
> linuxarm at huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>
> .
>
--
Regards, Rongrong
^ permalink raw reply
* [PATCH v6 8/9] drm/hisilicon/hibmc: Add vblank interruput
From: Rongrong Zou @ 2016-11-14 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOw6vbKx88Bz4RcD3a0K7m-uomHx9wOGN6y7eOuq+yeUdRjZ5Q@mail.gmail.com>
? 2016/11/11 9:49, Sean Paul ??:
> On Fri, Oct 28, 2016 at 3:28 AM, Rongrong Zou <zourongrong@gmail.com> wrote:
>> Add vblank interrupt.
>>
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>> ---
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 56 ++++++++++++++++++++++++-
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 +
>> 2 files changed, 56 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> index 4253603..b668e3e 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> @@ -40,16 +40,46 @@
>>
>> static int hibmc_enable_vblank(struct drm_device *dev, unsigned int pipe)
>> {
>> + struct hibmc_drm_device *hidev =
>> + (struct hibmc_drm_device *)dev->dev_private;
>> +
>> + writel(HIBMC_RAW_INTERRUPT_EN_VBLANK(1),
>> + hidev->mmio + HIBMC_RAW_INTERRUPT_EN);
>> +
>> return 0;
>> }
>>
>> static void hibmc_disable_vblank(struct drm_device *dev, unsigned int pipe)
>> {
>> + struct hibmc_drm_device *hidev =
>> + (struct hibmc_drm_device *)dev->dev_private;
>> +
>> + writel(HIBMC_RAW_INTERRUPT_EN_VBLANK(0),
>> + hidev->mmio + HIBMC_RAW_INTERRUPT_EN);
>> +}
>> +
>> +irqreturn_t hibmc_drm_interrupt(int irq, void *arg)
>> +{
>> + struct drm_device *dev = (struct drm_device *)arg;
>> + struct hibmc_drm_device *hidev =
>> + (struct hibmc_drm_device *)dev->dev_private;
>> + struct drm_crtc *crtc = &hidev->crtc;
>> + u32 status;
>> +
>> + status = readl(hidev->mmio + HIBMC_RAW_INTERRUPT);
>> +
>> + if (status & HIBMC_RAW_INTERRUPT_VBLANK(1)) {
>> + writel(HIBMC_RAW_INTERRUPT_VBLANK(1),
>> + hidev->mmio + HIBMC_RAW_INTERRUPT);
>> + drm_crtc_handle_vblank(crtc);
>> + }
>> +
>> + return IRQ_HANDLED;
>> }
>>
>> static struct drm_driver hibmc_driver = {
>> .driver_features = DRIVER_GEM | DRIVER_MODESET |
>> - DRIVER_ATOMIC,
>> + DRIVER_ATOMIC | DRIVER_HAVE_IRQ,
>> .fops = &hibmc_fops,
>> .name = "hibmc",
>> .date = "20160828",
>> @@ -63,6 +93,7 @@ static void hibmc_disable_vblank(struct drm_device *dev, unsigned int pipe)
>> .dumb_create = hibmc_dumb_create,
>> .dumb_map_offset = hibmc_dumb_mmap_offset,
>> .dumb_destroy = drm_gem_dumb_destroy,
>> + .irq_handler = hibmc_drm_interrupt,
>> };
>>
>> static int hibmc_pm_suspend(struct device *dev)
>> @@ -242,6 +273,13 @@ static int hibmc_unload(struct drm_device *dev)
>> struct hibmc_drm_device *hidev = dev->dev_private;
>>
>> hibmc_fbdev_fini(hidev);
>> +
>> + if (dev->irq_enabled)
>> + drm_irq_uninstall(dev);
>> + if (hidev->msi_enabled)
>> + pci_disable_msi(dev->pdev);
>> + drm_vblank_cleanup(dev);
>> +
>> hibmc_kms_fini(hidev);
>> hibmc_mm_fini(hidev);
>> hibmc_hw_fini(hidev);
>> @@ -272,6 +310,22 @@ static int hibmc_load(struct drm_device *dev, unsigned long flags)
>> if (ret)
>> goto err;
>>
>> + ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
>> + if (ret) {
>> + DRM_ERROR("failed to initialize vblank.\n");
>> + goto err;
>> + }
>> +
>> + hidev->msi_enabled = 0;
>> + if (pci_enable_msi(dev->pdev)) {
>
> It would be useful to check and print the return value of this.
agreed, thanks.
>
>> + DRM_ERROR("Enabling MSI failed!\n");
>> + } else {
>> + hidev->msi_enabled = 1;
>> + ret = drm_irq_install(dev, dev->pdev->irq);
>> + if (ret)
>> + DRM_ERROR("install irq failed , ret = %d\n", ret);
>
> DRM_WARN might be more appropriate, given that this isn't considered fatal.
agreed, thanks.
>
>> + }
>> +
>> /* reset all the states of crtc/plane/encoder/connector */
>> drm_mode_config_reset(dev);
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> index 450247d..f1706fb 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> @@ -42,6 +42,7 @@ struct hibmc_drm_device {
>> void __iomem *fb_map;
>> unsigned long fb_base;
>> unsigned long fb_size;
>> + int msi_enabled;
>
> Why not bool?
agreed, thanks.
Regards,
Rongrong.
>
>>
>> /* drm */
>> struct drm_device *dev;
>> --
>> 1.9.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> _______________________________________________
> linuxarm mailing list
> linuxarm at huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>
> .
>
^ permalink raw reply
* [PATCH v4 1/2] iommu/dma: Implement dma_{map,unmap}_resource()
From: Catalin Marinas @ 2016-11-14 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d1cbd5ce714ce3c978aa8bfcb31def87d7919198.1479125555.git.robin.murphy@arm.com>
On Mon, Nov 14, 2016 at 12:16:26PM +0000, Robin Murphy wrote:
> With the new dma_{map,unmap}_resource() functions added to the DMA API
> for the benefit of cases like slave DMA, add suitable implementations to
> the arsenal of our generic layer. Since cache maintenance should not be
> a concern, these can both be standalone callback implementations without
> the need for arch code wrappers.
>
> CC: Joerg Roedel <joro@8bytes.org>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
FWIW:
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH 12/16] ARM: imx: use generic API for enabling SCU
From: Shawn Guo @ 2016-11-14 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-13-git-send-email-pankaj.dubey@samsung.com>
On Mon, Nov 14, 2016 at 10:32:07AM +0530, Pankaj Dubey wrote:
> Now as we have of_scu_enable which takes care of mapping
> scu base from DT, lets use it.
>
> At the same time this patch cleans up mach-imx platform files by
> removing static mapping of SCU and dropping imx_scu_map_io function.
I remember that the static mapping of SCU is necessary because SCU is
being accessed at very early boot stage where dynamic mapping hasn't
been set up.
> CC: Shawn Guo <shawnguo@kernel.org>
> CC: Sascha Hauer <kernel@pengutronix.de>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> arch/arm/mach-imx/common.h | 5 -----
> arch/arm/mach-imx/mach-imx6q.c | 8 +-------
> arch/arm/mach-imx/platsmp.c | 32 +++++---------------------------
> arch/arm/mach-imx/pm-imx6.c | 3 ++-
> 4 files changed, 8 insertions(+), 40 deletions(-)
I tested it and saw that the booting of imx6q is broken like below.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.9.0-rc5-00002-g3e5aac418b91 (r65073 at dragon) (gcc version 4.9.3 20150413 (prerelease) (Linaro GCC 4.9-2015.04-1) ) #5 SMP Mon Nov 14 22:17:36 CST 2016
[ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt:Machine model: Freescale i.MX6 Quad SABRE Smart Device Board
[ 0.000000] earlycon: ec_imx21 at MMIO 0x02020000 (options '')
[ 0.000000] bootconsole [ec_imx21] enabled
[ 0.000000] cma: Reserved 16 MiB at 0x4f000000
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000004
[ 0.000000] pgd = c0004000
[ 0.000000] [00000004] *pgd=00000000
[ 0.000000] Internal error: Oops: 5 [#1] SMP ARM
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-rc5-00002-g3e5aac418b91 #5
[ 0.000000] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 0.000000] task: c0e086c0 task.stack: c0e00000
[ 0.000000] PC is at scu_get_core_count+0xc/0x1c
[ 0.000000] LR is at imx_smp_init_cpus+0x20/0x4c
[ 0.000000] pc : [<c0d05438>] lr : [<c0d0df2c>] psr: 000000d3
[ 0.000000] sp : c0e01f10 ip : c0e01f20 fp : c0e01f1c
[ 0.000000] r10: c0bed850 r9 : c0e051c0 r8 : c0e75140
[ 0.000000] r7 : c164c5f0 r6 : c0e09f08 r5 : c0d5d6fc r4 : c0e08340
[ 0.000000] r3 : c0e755f8 r2 : 00000000 r1 : c0120d3c r0 : 00000000
[ 0.000000] Flags: nzcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none
[ 0.000000] Control: 10c5387d Table: 1000404a DAC: 00000051
[ 0.000000] Process swapper (pid: 0, stack limit = 0xc0e00210)
[ 0.000000] Stack: (0xc0e01f10 to 0xc0e02000)
[ 0.000000] 1f00: c0e01f34 c0e01f20 c0d0df2c c0d05438
[ 0.000000] 1f20: c0e08340 c0d5d6fc c0e01f44 c0e01f38 c0d052b8 c0d0df18 c0e01fac c0e01f48
[ 0.000000] 1f40: c0d0457c c0d052a4 ffffffff 10c5387d c0e050c0 1000406a 4fffffff efffeec0
[ 0.000000] 1f60: c0e01f84 c0e01f70 c017b614 c017af04 c0bebc44 c0e01fa4 c0e01f9c c0e01f88
[ 0.000000] 1f80: c01cf6dc c0e75294 c0e050d8 c0d5fa44 c0e050c0 1000406a 412fc09a 00000000
[ 0.000000] 1fa0: c0e01ff4 c0e01fb0 c0d009b0 c0d03d24 00000000 00000000 00000000 00000000
[ 0.000000] 1fc0: 00000000 c0d5fa48 00000000 c0e75294 c0e050d8 c0d5fa44 c0e0a070 1000406a
[ 0.000000] 1fe0: 412fc09a 00000000 00000000 c0e01ff8 1000807c c0d0096c 00000000 00000000
[ 0.000000] Backtrace:
[ 0.000000] [<c0d0542c>] (scu_get_core_count) from [<c0d0df2c>] (imx_smp_init_cpus+0x20/0x4c)
[ 0.000000] [<c0d0df0c>] (imx_smp_init_cpus) from [<c0d052b8>] (smp_init_cpus+0x20/0x28)
[ 0.000000] r5:c0d5d6fc[ 0.000000] r4:c0e08340
[ 0.000000]
[ 0.000000] [<c0d05298>] (smp_init_cpus) from [<c0d0457c>] (setup_arch+0x864/0xc50)
[ 0.000000] [<c0d03d18>] (setup_arch) from [<c0d009b0>] (start_kernel+0x50/0x398)
[ 0.000000] r10:00000000[ 0.000000] r9:412fc09a
r8:1000406a[ 0.000000] r7:c0e050c0
r6:c0d5fa44[ 0.000000] r5:c0e050d8
[ 0.000000] r4:c0e75294[ 0.000000]
[ 0.000000] [<c0d00960>] (start_kernel) from [<1000807c>] (0x1000807c)
[ 0.000000] r10:00000000[ 0.000000] r9:412fc09a
r8:1000406a[ 0.000000] r7:c0e0a070
r6:c0d5fa44[ 0.000000] r5:c0e050d8
[ 0.000000] r4:c0e75294[ 0.000000]
[ 0.000000] Code: c0e75338 e1a0c00d e92dd800 e24cb004 (e5900004)
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
^ permalink raw reply
* [PATCH 04/16] ARM: realview: use generic API for enabling SCU
From: Arnd Bergmann @ 2016-11-14 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <95b10b29-2d51-9e96-c628-232f081e09f4@samsung.com>
On Monday, November 14, 2016 5:36:43 PM CET pankaj.dubey wrote:
> On Monday 14 November 2016 05:26 PM, Arnd Bergmann wrote:
> > On Monday, November 14, 2016 10:31:59 AM CET Pankaj Dubey wrote:
> >
> > The only difference here seems to be that realview also needs to handle
> > "arm,arm11mp-scu". Why not move that into the generic implementation?
> >
>
> Do you mean "arm,arm11mp-scu" this is generic SCU specific to ARM?
Yes.
> If it's generic then it can be moved on the same line I moved a5-scu and
> a9-scu.
>
> I left it here in same file, as I understood it might be related with
> very specific to realview platform.
The reason why only realview has it is that this is currently the
only platform we support that uses SMP on an ARM11MPcore.
cns3xxx in is also SMP hardware, but we only support the first core.
ARnd
^ permalink raw reply
* [PATCH 2/4] fpga mgr: Expose FPGA capabilities to userland via sysfs
From: atull @ 2016-11-14 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107001326.7395-3-moritz.fischer@ettus.com>
On Mon, 7 Nov 2016, Moritz Fischer wrote:
Hi Moritz,
One nit below. Otherwise,
Acked-by: Alan Tull <atull@opensource.altera.com>
Alan
> Expose FPGA capabilities to userland via sysfs.
>
> Add Documentation for currently supported capabilities
> that get exported via sysfs.
>
> Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
> Cc: Alan Tull <atull@opensource.altera.com>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: S?ren Brinkmann <soren.brinkmann@xilinx.com>
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> ---
> Documentation/ABI/testing/sysfs-class-fpga-manager | 16 ++++++++++++++++
> drivers/fpga/fpga-mgr.c | 20 ++++++++++++++++++++
> include/linux/fpga/fpga-mgr.h | 2 ++
> 3 files changed, 38 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-class-fpga-manager b/Documentation/ABI/testing/sysfs-class-fpga-manager
> index 23056c5..d9aee21 100644
> --- a/Documentation/ABI/testing/sysfs-class-fpga-manager
> +++ b/Documentation/ABI/testing/sysfs-class-fpga-manager
> @@ -35,3 +35,19 @@ Description: Read fpga manager state as a string.
> * write complete = Doing post programming steps
> * write complete error = Error while doing post programming
> * operating = FPGA is programmed and operating
> +
> +What: /sys/class/fpga_manager/fpga/capabilities
> +Date: November 2016
> +KernelVersion: 4.9
> +Contact: Moritz Fischer <moritz.fischer@ettus.com>
> +Description: Read fpga manager capabilities as a string.
> + The intent is to provide userspace with information on what
> + operations the particular instance can execute.
> +
> + Each line expresses a capability that is available on the
> + particular instance of an fpga manager.
> + Supported so far:
> +
> + * Full reconfiguration
> + * Partial reconfiguration
> + * Decrypt bitstream on the fly
Decrypt gets added in a later patch.
> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> index ed57c17..98230b7 100644
> --- a/drivers/fpga/fpga-mgr.c
> +++ b/drivers/fpga/fpga-mgr.c
> @@ -167,6 +167,11 @@ static const char * const state_str[] = {
> [FPGA_MGR_STATE_OPERATING] = "operating",
> };
>
> +static const char * const cap_str[] = {
> + [FPGA_MGR_CAP_FULL_RECONF] = "Full reconfiguration",
> + [FPGA_MGR_CAP_PARTIAL_RECONF] = "Partial reconfiguration",
> +};
> +
> static ssize_t name_show(struct device *dev,
> struct device_attribute *attr, char *buf)
> {
> @@ -183,10 +188,25 @@ static ssize_t state_show(struct device *dev,
> return sprintf(buf, "%s\n", state_str[mgr->state]);
> }
>
> +static ssize_t capabilities_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct fpga_manager *mgr = to_fpga_manager(dev);
> + char *start = buf;
> + enum fpga_mgr_capability cap;
> +
> + for_each_fpga_mgr_cap_mask(cap, mgr->caps)
> + buf += sprintf(buf, "%s\n", cap_str[cap]);
> +
> + return buf - start;
> +}
> +
> +static DEVICE_ATTR_RO(capabilities);
> static DEVICE_ATTR_RO(name);
> static DEVICE_ATTR_RO(state);
>
> static struct attribute *fpga_mgr_attrs[] = {
> + &dev_attr_capabilities.attr,
> &dev_attr_name.attr,
> &dev_attr_state.attr,
> NULL,
> diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
> index e73429c..9bb96a5 100644
> --- a/include/linux/fpga/fpga-mgr.h
> +++ b/include/linux/fpga/fpga-mgr.h
> @@ -108,6 +108,8 @@ static inline void __fpga_mgr_cap_set(enum fpga_mgr_capability cap,
> set_bit(cap, mask->bits);
> }
>
> +#define for_each_fpga_mgr_cap_mask(cap, mask) \
> + for_each_set_bit(cap, mask.bits, FPGA_MGR_CAP_END)
>
> /**
> * struct fpga_manager_ops - ops for low level fpga manager drivers
> --
> 2.10.0
>
>
^ permalink raw reply
* [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU
From: Arnd Bergmann @ 2016-11-14 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114135018.GL1041@n2100.armlinux.org.uk>
On Monday, November 14, 2016 1:50:18 PM CET Russell King - ARM Linux wrote:
> On Mon, Nov 14, 2016 at 01:03:09PM +0100, Arnd Bergmann wrote:
> > On Monday, November 14, 2016 2:10:16 PM CET pankaj.dubey wrote:
> > > >> + scu_base = of_iomap(np, 0);
> > > >> + of_node_put(np);
> > > >> + if (!scu_base) {
> > > >> + pr_err("%s failed to map scu_base via DT\n", __func__);
> > > >
> > > > For non-ca5, non-ca9 based SoCs, we'll see this error msg. We understand
> > > > what does it mean, but it may confuse normal users. In current version,
> > > > berlin doesn't complain like this for non-ca9 SoCs
> > > >
> > >
> > > OK, let me see other reviewer's comment on this. Then we will decide if
> > > this error message is required or can be omitted.
> >
> > We need to look at all callers here, to see if the function ever gets
> > called for a CPU that doesn't have an SCU. I'd say we should warn if
> > we know there is an SCU but we cannot map it, but never warn on
> > any of the CPU cores that don't support an SCU.
>
> Maybe there should be two helpers:
>
> of_scu_enable() which _only_ looks up the SCU address in DT and enables
> it if it finds it, otherwise returning failure.
>
> a9_scu_enable() which tries to use the A9 provided SCU address and
> enables it if it finds it, otherwise returning failure.
>
> Then callers can decide which of these to call, and what error messages
> to print on their failures.
Splitting the function in two is probably simpler overall, but
we may still have to look at all the callers: Any platform that
currently tries to map it on any CPU and doesn't warn about the
absence of the device node (or about scu_a9_has_base() == false)
should really continue not to warn about that.
If all platforms only call these on SMP machines with an
ARM11MPcore, Cortex-A5 or Cortex-A9, everything should be
fine here, otherwise we can leave the warning in the caller
after checking the return code of the new APIs.
Arnd
^ permalink raw reply
* [PATCH] staging: vc04_services: Remove explicit NULL pointer
From: Greg Kroah-Hartman @ 2016-11-14 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478866605-1561-1-git-send-email-maninder.s2@samsung.com>
On Fri, Nov 11, 2016 at 05:46:45PM +0530, Maninder Singh wrote:
> Replace direct comparisons to NULL i.e.
> 'x == NULL' with '!x'
> 'x != NULL' with 'x'
>
> Signed-off-by: Maninder Singh <maninder.s2@samsung.com>
A patch that was sent right before yours causes this patch to now have
conflicts. Can you refresh it against my staging-testing branch and
resend?
thanks,
greg k-h
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: add gmac needed clk for rk3399 pd
From: Heiko Stuebner @ 2016-11-14 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479098199-20170-1-git-send-email-wxt@rock-chips.com>
Am Montag, 14. November 2016, 12:36:39 CET schrieb Caesar Wang:
> From: Jeffy Chen <jeffy.chen@rock-chips.com>
>
> This patch fixes that sometimes hang at start-up time of the system.
> As the below log:
> ...
> [ 11.136543] calling pm_genpd_debug_init+0x0/0x60 @ 1
> [ 11.141602] initcall pm_genpd_debug_init+0x0/0x60 returned 0 after 11
> usecs [ 11.148558] calling genpd_poweroff_unused+0x0/0x84 @ 1
> <hang>
>
> In some cases, the rk3399 should turn off the gmac power domain to save
> power if some boards didn't register the gmac device node for rk3399.
> Then, rk3399 need to make sure the gmac's pclk enabled if we need
> operate the gmac power domain. (Due to the NOC had enabled always)
>
> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
applied to my dts64 branch
Thanks
Heiko
^ permalink raw reply
* [PATCH resend 0/1] input: touchscreen: silead: Add regulator support
From: Hans de Goede @ 2016-11-14 14:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi Dmitri,
This one seems to have fallen through the cracks, can you pick it up
please ?
Regards,
Hans
^ permalink raw reply
* [PATCH resend] input: touchscreen: silead: Add regulator support
From: Hans de Goede @ 2016-11-14 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114144502.10595-1-hdegoede@redhat.com>
On some tablets the touchscreen controller is powered by seperate
regulators, add support for this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../bindings/input/touchscreen/silead_gsl1680.txt | 2 +
drivers/input/touchscreen/silead.c | 51 ++++++++++++++++++++--
2 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt b/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
index e844c3f..b726823 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
@@ -22,6 +22,8 @@ Optional properties:
- touchscreen-inverted-y : See touchscreen.txt
- touchscreen-swapped-x-y : See touchscreen.txt
- silead,max-fingers : maximum number of fingers the touchscreen can detect
+- vddio-supply : regulator phandle for controller VDDIO
+- avdd-supply : regulator phandle for controller AVDD
Example:
diff --git a/drivers/input/touchscreen/silead.c b/drivers/input/touchscreen/silead.c
index f502c84..c6a1ae9 100644
--- a/drivers/input/touchscreen/silead.c
+++ b/drivers/input/touchscreen/silead.c
@@ -29,6 +29,7 @@
#include <linux/input/touchscreen.h>
#include <linux/pm.h>
#include <linux/irq.h>
+#include <linux/regulator/consumer.h>
#include <asm/unaligned.h>
@@ -72,6 +73,8 @@ enum silead_ts_power {
struct silead_ts_data {
struct i2c_client *client;
struct gpio_desc *gpio_power;
+ struct regulator *vddio;
+ struct regulator *avdd;
struct input_dev *input;
char fw_name[64];
struct touchscreen_properties prop;
@@ -465,21 +468,52 @@ static int silead_ts_probe(struct i2c_client *client,
if (client->irq <= 0)
return -ENODEV;
+ data->vddio = devm_regulator_get_optional(dev, "vddio");
+ if (IS_ERR(data->vddio)) {
+ if (PTR_ERR(data->vddio) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ data->vddio = NULL;
+ }
+
+ data->avdd = devm_regulator_get_optional(dev, "avdd");
+ if (IS_ERR(data->avdd)) {
+ if (PTR_ERR(data->avdd) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ data->avdd = NULL;
+ }
+
+ /*
+ * Enable regulators at probe and disable them at remove, we need
+ * to keep the chip powered otherwise it forgets its firmware.
+ */
+ if (data->vddio) {
+ error = regulator_enable(data->vddio);
+ if (error)
+ return error;
+ }
+
+ if (data->avdd) {
+ error = regulator_enable(data->avdd);
+ if (error)
+ goto disable_vddio;
+ }
+
/* Power GPIO pin */
data->gpio_power = devm_gpiod_get_optional(dev, "power", GPIOD_OUT_LOW);
if (IS_ERR(data->gpio_power)) {
if (PTR_ERR(data->gpio_power) != -EPROBE_DEFER)
dev_err(dev, "Shutdown GPIO request failed\n");
- return PTR_ERR(data->gpio_power);
+ error = PTR_ERR(data->gpio_power);
+ goto disable_avdd;
}
error = silead_ts_setup(client);
if (error)
- return error;
+ goto disable_avdd;
error = silead_ts_request_input_dev(data);
if (error)
- return error;
+ goto disable_avdd;
error = devm_request_threaded_irq(dev, client->irq,
NULL, silead_ts_threaded_irq_handler,
@@ -487,10 +521,19 @@ static int silead_ts_probe(struct i2c_client *client,
if (error) {
if (error != -EPROBE_DEFER)
dev_err(dev, "IRQ request failed %d\n", error);
- return error;
+ goto disable_avdd;
}
return 0;
+
+disable_avdd:
+ if (data->avdd)
+ regulator_disable(data->avdd);
+disable_vddio:
+ if (data->vddio)
+ regulator_disable(data->vddio);
+
+ return error;
}
static int __maybe_unused silead_ts_suspend(struct device *dev)
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/9] arm64: dts: rockchip: add eMMC's power domain support for rk3399
From: Heiko Stuebner @ 2016-11-14 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-2-git-send-email-wxt@rock-chips.com>
Am Mittwoch, 9. November 2016, 21:21:53 CET schrieb Caesar Wang:
> From: Ziyuan Xu <xzy.xu@rock-chips.com>
>
> Control power domain for eMMC via genpd to reduce power consumption.
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Authorship / Signed-off mismatch. From above suggest Ziyuan is the author
while first Signed-off-by indicates Elaine as author. Please clarify.
Thanks
Heiko
> ---
>
> Changes in v2:
> - Reviewed-on: https://chromium-review.googlesource.com/376558
> - Verified on ChromeOS kernel4.4
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index cbb7f8b..b401176 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -269,6 +269,7 @@
> #clock-cells = <0>;
> phys = <&emmc_phy>;
> phy-names = "phy_arasan";
> + power-domains = <&power RK3399_PD_EMMC>;
> status = "disabled";
> };
>
> @@ -690,6 +691,11 @@
> status = "disabled";
> };
>
> + qos_emmc: qos at ffa58000 {
> + compatible = "syscon";
> + reg = <0x0 0xffa58000 0x0 0x20>;
> + };
> +
> qos_gmac: qos at ffa5c000 {
> compatible = "syscon";
> reg = <0x0 0xffa5c000 0x0 0x20>;
> @@ -823,6 +829,11 @@
> };
>
> /* These power domains are grouped by VD_LOGIC */
> + pd_emmc at RK3399_PD_EMMC {
> + reg = <RK3399_PD_EMMC>;
> + clocks = <&cru ACLK_EMMC>;
> + pm_qos = <&qos_emmc>;
> + };
> pd_gmac at RK3399_PD_GMAC {
> reg = <RK3399_PD_GMAC>;
> clocks = <&cru ACLK_GMAC>;
^ permalink raw reply
* [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU
From: Russell King - ARM Linux @ 2016-11-14 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6787744.7DRFf7p3US@wuerfel>
On Mon, Nov 14, 2016 at 03:37:44PM +0100, Arnd Bergmann wrote:
> On Monday, November 14, 2016 1:50:18 PM CET Russell King - ARM Linux wrote:
> > On Mon, Nov 14, 2016 at 01:03:09PM +0100, Arnd Bergmann wrote:
> > > On Monday, November 14, 2016 2:10:16 PM CET pankaj.dubey wrote:
> > > > >> + scu_base = of_iomap(np, 0);
> > > > >> + of_node_put(np);
> > > > >> + if (!scu_base) {
> > > > >> + pr_err("%s failed to map scu_base via DT\n", __func__);
> > > > >
> > > > > For non-ca5, non-ca9 based SoCs, we'll see this error msg. We understand
> > > > > what does it mean, but it may confuse normal users. In current version,
> > > > > berlin doesn't complain like this for non-ca9 SoCs
> > > > >
> > > >
> > > > OK, let me see other reviewer's comment on this. Then we will decide if
> > > > this error message is required or can be omitted.
> > >
> > > We need to look at all callers here, to see if the function ever gets
> > > called for a CPU that doesn't have an SCU. I'd say we should warn if
> > > we know there is an SCU but we cannot map it, but never warn on
> > > any of the CPU cores that don't support an SCU.
> >
> > Maybe there should be two helpers:
> >
> > of_scu_enable() which _only_ looks up the SCU address in DT and enables
> > it if it finds it, otherwise returning failure.
> >
> > a9_scu_enable() which tries to use the A9 provided SCU address and
> > enables it if it finds it, otherwise returning failure.
> >
> > Then callers can decide which of these to call, and what error messages
> > to print on their failures.
>
> Splitting the function in two is probably simpler overall, but
> we may still have to look at all the callers: Any platform that
> currently tries to map it on any CPU and doesn't warn about the
> absence of the device node (or about scu_a9_has_base() == false)
> should really continue not to warn about that.
Did you miss the bit where none of of_scu_enable() or a9_scu_enable()
should produce any warnings or errors to be printed. It's up to the
caller to report the failure, otherwise doing this doesn't make sense:
if (of_scu_enable() < 0 && a9_scu_enable() < 0)
pr_err("Failed to map and enable the SCU\n");
because if of_scu_enable() prints a warning/error, then it's patently
misleading.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently@9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [GIT PULL] ARM: OXNAS SoC updates for 4.10
From: Neil Armstrong @ 2016-11-14 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0b12c093-4be4-8f1c-2b46-ffaa54c5520b@baylibre.com>
On 11/08/2016 12:21 PM, Neil Armstrong wrote:
> On 11/07/2016 10:26 PM, Olof Johansson wrote:
>> On Mon, Oct 31, 2016 at 10:52:53AM +0100, Neil Armstrong wrote:
[...]
>> Hi Neil,
> Hi Olof,
>
>>
>> Sorry for being picky here, please be patient with us. :-)
> Seems legit !
>
>>
>> Overall comments on this patch set:
>>
>> 1) Copyrights seem to be a bit varied. All 3 new source files have
>> different copyright holders. Only one has yours, one is from 2003, one
>> is also from 2013. Is this expected? Seems like it's worth mentioning
>> in commit messages at least.
>
> Yes, the files comes from various places :
> - hotplug.c was taken from versatile by Ma Haijun and left verbatim, so I left the original header
> - headsmp.S was taken from the versatile code and adapted by Ma Haijun
> - platsmp.c is a mix from versatile code, Ma Haijun code and my code for DT
>
> The two first file were only modified in order to build and pass checkpatch actually.
>
> I tried to find the *real* copyright holders, but it was not easy...
>
>>
>> 2) Please remove the linux/arch/... lines from the top of the files. It's
>> something we've been trying to remove for a while and don't want to
>> introduce more occurrances of.
>>
>> I'd say (2) is fine to do incremental, but please provide clarification on (1).
>> I could just add that to the merge commit message so don't respin the branch
>> yet, depending on what we hear back!
>>
>
> Ok, please tell me if/when I need to send a new pull for the (2) fix.
>
>>> arch/arm/Makefile | 1 +
>>> arch/arm/mach-oxnas/Kconfig | 30 +++++++++++++++++++---------
>>> arch/arm/mach-oxnas/Makefile | 2 ++
>>> arch/arm/mach-oxnas/headsmp.S | 28 ++++++++++++++++++++++++++
>>> arch/arm/mach-oxnas/hotplug.c | 111 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> arch/arm/mach-oxnas/platsmp.c | 104 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>> Git tip: If you redirect the output to a file (or pipe through cat), the
>> diffstat will be limited to 80 characters and look better in email.
>>
>>
>> Thanks,
>>
>> -Olof
>>
>
> Thanks,
> Neil
>
Hi Olof,
Is a new pull request needed finally ?
Best regards,
Neil
^ permalink raw reply
* [PATCH v2 5/9] arm64: dts: rockchip: add backlight support for rk3399 evb board
From: Heiko Stuebner @ 2016-11-14 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-6-git-send-email-wxt@rock-chips.com>
Am Mittwoch, 9. November 2016, 21:21:57 CET schrieb Caesar Wang:
> From: Yakir Yang <ykk@rock-chips.com>
>
> Add backlight node for evb board, perpare for panel device node.
>
> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
applied to my dts64 branch
Thanks
Heiko
^ permalink raw reply
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: tomas.hlavacek at nic.cz @ 2016-11-14 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114131010.GC26710@lunn.ch>
Hi Andrew!
(Sorry for re-posting the previous e-mail, that most likely didn't get
through.)
On Mon, Nov 14, 2016 at 2:10 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> Actually SFP is connected to SGMII interface of eth1, which is
>> routed through SERDES 5.
>
> You say eth1 here. Yet lower down you say got eth0 and eth1 are
> connected to the switch?
Oh sorry, this was a NIC name based on probing order derived from base
address of NIC registers:
eth1: ethernet at 30000 - probes as eth0
eth2: ethernet at 34000 - probes as eth1
eth0: ethernet at 70000 - probes as eth2
It is a bit confusing. I meant eth2 in DTS. Sorry.
>
>
>> We have our proprietary support hacked onto mvneta driver for
>> disconnecting PHY on the fly. It is a bit nasty, so I suggest to
>> ignore SFP in this DTS altogether and let's wait till "phylink based
>> SFP module support" or something alike hits upstream, so we can base
>> the SFP support on solid code;
>
> It would be great if you could work on getting the phylink patches
> into mainline. It is something i have wanted to do for a long time,
> but it is too low down on my priority list to get to. The code is high
> quality, so i don't think there will be too many issues. It probably
> just needs splitting up into smaller batches, submitting, and working
> on any comments.
That is exactly what I thought when I saw the patches for the first
time. I will try to merge the patches to the current kernel and see
what happens. I still need to learn a lot about PHY subsystem.
>
>
>> Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176
>> switch. The problem is that from what I have read so far the switch
>> can not operate in DSA mode with two CPU ports.
>
> Again, this is something i wanted to do, and i did have a prototype at
> one point. But again, not enough time. If you have resources to work
> on this, i can find my code, explain my ideas, and let you complete
> it.
I am definitely interested, though I didn't have time to read and
absorb DSA yet, but I definitely want to try to hack 88E6176 support. I
would be really grateful if you can provide some pointers and/or code
to start from.
Thanks,
Tomas
^ permalink raw reply
* [PATCH v2 1/9] arm64: dts: rockchip: add eMMC's power domain support for rk3399
From: Caesar Wang @ 2016-11-14 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2342292.tK2jqRKrXH@phil>
On 2016?11?14? 22:45, Heiko Stuebner wrote:
> Am Mittwoch, 9. November 2016, 21:21:53 CET schrieb Caesar Wang:
>> From: Ziyuan Xu <xzy.xu@rock-chips.com>
>>
>> Control power domain for eMMC via genpd to reduce power consumption.
>>
>> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
>> Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
>> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> Authorship / Signed-off mismatch. From above suggest Ziyuan is the author
> while first Signed-off-by indicates Elaine as author. Please clarify.
I believe the Elaine is the first author. Sorry for this kind of
question to brother you again. :(
-
Caesar
>
> Thanks
> Heiko
>
>> ---
>>
>> Changes in v2:
>> - Reviewed-on: https://chromium-review.googlesource.com/376558
>> - Verified on ChromeOS kernel4.4
>>
>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index cbb7f8b..b401176 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> @@ -269,6 +269,7 @@
>> #clock-cells = <0>;
>> phys = <&emmc_phy>;
>> phy-names = "phy_arasan";
>> + power-domains = <&power RK3399_PD_EMMC>;
>> status = "disabled";
>> };
>>
>> @@ -690,6 +691,11 @@
>> status = "disabled";
>> };
>>
>> + qos_emmc: qos at ffa58000 {
>> + compatible = "syscon";
>> + reg = <0x0 0xffa58000 0x0 0x20>;
>> + };
>> +
>> qos_gmac: qos at ffa5c000 {
>> compatible = "syscon";
>> reg = <0x0 0xffa5c000 0x0 0x20>;
>> @@ -823,6 +829,11 @@
>> };
>>
>> /* These power domains are grouped by VD_LOGIC */
>> + pd_emmc at RK3399_PD_EMMC {
>> + reg = <RK3399_PD_EMMC>;
>> + clocks = <&cru ACLK_EMMC>;
>> + pm_qos = <&qos_emmc>;
>> + };
>> pd_gmac at RK3399_PD_GMAC {
>> reg = <RK3399_PD_GMAC>;
>> clocks = <&cru ACLK_GMAC>;
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
--
caesar wang | software engineer | wxt at rock-chip.com
^ permalink raw reply
* [PATCH v2 1/9] arm64: dts: rockchip: add eMMC's power domain support for rk3399
From: Caesar Wang @ 2016-11-14 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bce1a5eb-fbb3-9ed9-46b9-72a95eefed3e@rock-chips.com>
On 2016?11?12? 12:22, Shawn Lin wrote:
> On 2016/11/9 21:21, Caesar Wang wrote:
>> From: Ziyuan Xu <xzy.xu@rock-chips.com>
>>
>> Control power domain for eMMC via genpd to reduce power consumption.
>>
>> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
>> Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
>> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
>
> It was verified on my rk3399 evb with kernel4.4, so
> free feel to add my tag,
>
> Tested-by: Shawn Lin <shawn.lin@rock-chips.com>
>
Thanks the tests.
> BTW, it seems my reply is bounced form Yakir's address, so please
> remove him from CC list if he changed his mail address.
Right, Yakir's (ykk at rock-chips.com) address had left this world.;-)
But the patman tool is auto sending with the Cc people.
-
Caesar
>
>> ---
>>
>> Changes in v2:
>> - Reviewed-on: https://chromium-review.googlesource.com/376558
>> - Verified on ChromeOS kernel4.4
>>
>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> index cbb7f8b..b401176 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> @@ -269,6 +269,7 @@
>> #clock-cells = <0>;
>> phys = <&emmc_phy>;
>> phy-names = "phy_arasan";
>> + power-domains = <&power RK3399_PD_EMMC>;
>> status = "disabled";
>> };
>>
>> @@ -690,6 +691,11 @@
>> status = "disabled";
>> };
>>
>> + qos_emmc: qos at ffa58000 {
>> + compatible = "syscon";
>> + reg = <0x0 0xffa58000 0x0 0x20>;
>> + };
>> +
>> qos_gmac: qos at ffa5c000 {
>> compatible = "syscon";
>> reg = <0x0 0xffa5c000 0x0 0x20>;
>> @@ -823,6 +829,11 @@
>> };
>>
>> /* These power domains are grouped by VD_LOGIC */
>> + pd_emmc at RK3399_PD_EMMC {
>> + reg = <RK3399_PD_EMMC>;
>> + clocks = <&cru ACLK_EMMC>;
>> + pm_qos = <&qos_emmc>;
>> + };
>> pd_gmac at RK3399_PD_GMAC {
>> reg = <RK3399_PD_GMAC>;
>> clocks = <&cru ACLK_GMAC>;
>>
>
>
--
caesar wang | software engineer | wxt at rock-chip.com
^ permalink raw reply
* [PATCH] ARM: zynq: Reserve correct amount of non-DMA RAM
From: Michal Simek @ 2016-11-14 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+aJhH2yZqrwR=U2pgWZfxuF63FF75-NVwGHbDU=fFs7cmcg9w@mail.gmail.com>
On 10.11.2016 10:57, Nathan Rossi wrote:
> On 10 November 2016 at 19:33, Nathan Rossi <nathan@nathanrossi.com> wrote:
>> On 10 November 2016 at 18:41, Michal Simek <monstr@monstr.eu> wrote:
>>> + Nathan
>>>
>>> 2016-10-31 17:26 GMT+01:00 Kyle Roeschley <kyle.roeschley@ni.com>:
>>>>
>>>> On Zynq, we haven't been reserving the correct amount of DMA-incapable
>>>> RAM to keep DMA away from it (per the Zynq TRM Section 4.1, it should be
>>>> the first 512k). In older kernels, this was masked by the
>>>> memblock_reserve call in arm_memblock_init(). Now, reserve the correct
>>>> amount excplicitly rather than relying on swapper_pg_dir, which is an
>>>> address and not a size anyway.
>>>>
>>>> Fixes: 46f5b96 ("ARM: zynq: Reserve not DMAable space in front of the
>>>> kernel")
>>>>
>>>> Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
>>
>> Tested-by: Nathan Rossi <nathan@nathanrossi.com>
>>
>> For reference this causes problems with DEBUG_RODATA (which changed to
>
> Sorry typo -> s/causes/caused/, as in "... this [incorrect reserving
> of the lower 512K] caused ...".
>
> Regards,
> Nathan
>
>> default yes for CPU_V7 in v4.6) due to padding memory between
>> .head.text and .text, allowing memory below 0x80000 to be available
>> for allocation as non-reserved memory.
Applied to zynq/soc
https://github.com/Xilinx/linux-xlnx/commits/zynq/soc
Thanks,
Michal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/08ba1daa/attachment.sig>
^ 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