* [PATCH RFC 08/26] dmaengine: omap-dma: consolidate setup of CCR
From: Russell King - ARM Linux @ 2014-01-22 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DFBFDD.8040506@ti.com>
On Wed, Jan 22, 2014 at 06:25:57PM +0530, Sricharan R wrote:
> Setting up of DMA_DST_SYNC_PREFETCH is missing after this ?
I'm not looking for the DMA engine driver to be a 100% reimplementation
of the legacy driver. Rather than supporting the entire set of features
which the legacy driver did, and have many of them simply not used, the
approach I'm taking here is to only support what is necessary for the
drivers we have in mainline - and what fits the DMA engine interfaces.
There is no point inventing new DMA engine interfaces for features for
which we have no users in mainline kernel - to try to do that will be
quite rightfully thrown out by the DMA engine maintainers.
Here's the total number of references/definitions of DMA_DST_SYNC_PREFETCH
in the mainline kernel:
arch/arm/plat-omap/dma.c: if (src_or_dst_synch == OMAP_DMA_DST_SYNC_PREFETCH) {
include/linux/omap-dma.h:#define OMAP_DMA_DST_SYNC_PREFETCH 0x02
Hence, this feature is unused at present.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH] ARM: EXYNOS: cpuidle: Fix build error of no type of module_init
From: Krzysztof Kozlowski @ 2014-01-22 14:18 UTC (permalink / raw)
To: linux-arm-kernel
Add missing include to fix build error:
arch/arm/mach-exynos/cpuidle.c:256:1: warning: data definition has no type or storage class [enabled by default]
arch/arm/mach-exynos/cpuidle.c:256:1: error: type defaults to ?int? in declaration of ?module_init? [-Werror=implicit-int]
arch/arm/mach-exynos/cpuidle.c:256:1: warning: parameter names (without types) in function declaration [enabled by default]
arch/arm/mach-exynos/cpuidle.c:256:1: warning: data definition has no type or storage class [enabled by default]
arch/arm/mach-exynos/cpuidle.c:256:1: error: type defaults to ?int? in declaration of ?module_exit? [-Werror=implicit-int]
arch/arm/mach-exynos/cpuidle.c:256:1: warning: parameter names (without types) in function declaration [enabled by default]
arch/arm/mach-exynos/cpuidle.c:256:1: warning: ?exynos_cpuidle_driver_init? defined but not used [-Wunused-function]
cc1: some warnings being treated as errors
make[1]: *** [arch/arm/mach-exynos/cpuidle.o] Error 1
Build error happens on gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
and was introduced by commit 35baa3369d1c (ARM: EXYNOS: convert cpuidle
driver to be a platform driver).
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
---
arch/arm/mach-exynos/cpuidle.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index f57cb91f02aa..53dc1e705b2f 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -15,6 +15,7 @@
#include <linux/io.h>
#include <linux/export.h>
#include <linux/time.h>
+#include <linux/module.h>
#include <linux/platform_device.h>
#include <asm/proc-fns.h>
--
1.7.9.5
^ permalink raw reply related
* [PATCH RFC 03/26] dmaengine: omap-dma: program hardware directly
From: Russell King - ARM Linux @ 2014-01-22 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DFBF89.3020102@ti.com>
On Wed, Jan 22, 2014 at 06:24:33PM +0530, Sricharan R wrote:
> EI and FI are always set to zero. So interleaved transfers support
> have to enabled in omap-dma, as it was supported by the
> legacy driver. It was not enabled because of no users of the feature,
> right ?
None of the users of the legacy driver used this feature. Moreover,
dmaengine doesn't have the interfaces to support this specialised
feature at present.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 4/4] ARM64: perf: support dwarf unwinding in compat mode
From: Jean Pihet @ 2014-01-22 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390399879-5109-1-git-send-email-jean.pihet@linaro.org>
Add support for unwinding using the dwarf information in compat
mode. Using the correct user stack pointer allows perf to record
the frames correctly in the native and compat modes.
Note that although the dwarf frame unwinding works ok using
libunwind in native mode (on ARMv7 & ARMv8), some changes are
required to the libunwind code for the compat mode. Those changes
are posted separately on the libunwind mailing list.
Tested on ARMv8 platform with v8 and compat v7 binaries, the latter
are statically built.
Signed-off-by: Jean Pihet <jean.pihet@linaro.org>
---
arch/arm64/include/asm/compat.h | 2 +-
arch/arm64/include/asm/ptrace.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index fda2704..e71f81f 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -228,7 +228,7 @@ static inline compat_uptr_t ptr_to_compat(void __user *uptr)
return (u32)(unsigned long)uptr;
}
-#define compat_user_stack_pointer() (current_pt_regs()->compat_sp)
+#define compat_user_stack_pointer() (user_stack_pointer(current_pt_regs()))
static inline void __user *arch_compat_alloc_user_space(long len)
{
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index fbb0020..86d5b54 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -133,7 +133,7 @@ struct pt_regs {
(!((regs)->pstate & PSR_F_BIT))
#define user_stack_pointer(regs) \
- ((regs)->sp)
+ (!compat_user_mode(regs)) ? ((regs)->sp) : ((regs)->compat_sp)
/*
* Are the current registers suitable for user mode? (used to maintain
--
1.7.11.7
^ permalink raw reply related
* [PATCH 3/4] ARM64: perf: add support for frame pointer unwinding in compat mode
From: Jean Pihet @ 2014-01-22 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390399879-5109-1-git-send-email-jean.pihet@linaro.org>
When profiling a 32-bit application, user space callchain unwinding
using the frame pointer is performed in compat mode. The code is taken
over from the AARCH32 code and adapted to work on AARCH64.
Signed-off-by: Jean Pihet <jean.pihet@linaro.org>
---
arch/arm64/kernel/perf_event.c | 75 +++++++++++++++++++++++++++++++++++++-----
1 file changed, 67 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 5b1cd79..e868c72 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -1348,8 +1348,8 @@ early_initcall(init_hw_perf_events);
* Callchain handling code.
*/
struct frame_tail {
- struct frame_tail __user *fp;
- unsigned long lr;
+ struct frame_tail __user *fp;
+ unsigned long lr;
} __attribute__((packed));
/*
@@ -1386,22 +1386,80 @@ user_backtrace(struct frame_tail __user *tail,
return buftail.fp;
}
+/*
+ * The registers we're interested in are at the end of the variable
+ * length saved register structure. The fp points at the end of this
+ * structure so the address of this struct is:
+ * (struct compat_frame_tail *)(xxx->fp)-1
+ *
+ * This code has been adapted from the ARM OProfile support.
+ */
+struct compat_frame_tail {
+ compat_uptr_t fp; /* a (struct compat_frame_tail *) in compat mode */
+ u32 sp;
+ u32 lr;
+} __attribute__((packed));
+
+static struct compat_frame_tail __user *
+compat_user_backtrace(struct compat_frame_tail __user *tail,
+ struct perf_callchain_entry *entry)
+{
+ struct compat_frame_tail buftail;
+ unsigned long err;
+
+ /* Also check accessibility of one struct frame_tail beyond */
+ if (!access_ok(VERIFY_READ, tail, sizeof(buftail)))
+ return NULL;
+
+ pagefault_disable();
+ err = __copy_from_user_inatomic(&buftail, tail, sizeof(buftail));
+ pagefault_enable();
+
+ if (err)
+ return NULL;
+
+ perf_callchain_store(entry, buftail.lr);
+
+ /*
+ * Frame pointers should strictly progress back up the stack
+ * (towards higher addresses).
+ */
+ if (tail + 1 >= (struct compat_frame_tail __user *)
+ compat_ptr(buftail.fp))
+ return NULL;
+
+ return (struct compat_frame_tail __user *)compat_ptr(buftail.fp) - 1;
+}
+
void perf_callchain_user(struct perf_callchain_entry *entry,
struct pt_regs *regs)
{
- struct frame_tail __user *tail;
-
if (perf_guest_cbs && perf_guest_cbs->is_in_guest()) {
/* We don't support guest os callchain now */
return;
}
perf_callchain_store(entry, regs->pc);
- tail = (struct frame_tail __user *)regs->regs[29];
- while (entry->nr < PERF_MAX_STACK_DEPTH &&
- tail && !((unsigned long)tail & 0xf))
- tail = user_backtrace(tail, entry);
+ if (!compat_user_mode(regs)) {
+ /* AARCH64 mode */
+ struct frame_tail __user *tail;
+
+ tail = (struct frame_tail __user *)regs->regs[29];
+
+ while (entry->nr < PERF_MAX_STACK_DEPTH &&
+ tail && !((unsigned long)tail & 0xf))
+ tail = user_backtrace(tail, entry);
+ } else {
+ /* AARCH32 compat mode */
+ struct compat_frame_tail __user *tail;
+
+ tail = (struct compat_frame_tail __user *)regs->compat_fp - 1;
+
+ while ((entry->nr < PERF_MAX_STACK_DEPTH) &&
+ tail && !((unsigned long)tail & 0x3))
+ tail = compat_user_backtrace(tail, entry);
+ }
}
/*
@@ -1429,6 +1487,7 @@ void perf_callchain_kernel(struct perf_callchain_entry *entry,
frame.fp = regs->regs[29];
frame.sp = regs->sp;
frame.pc = regs->pc;
+
walk_stackframe(&frame, callchain_trace, entry);
}
--
1.7.11.7
^ permalink raw reply related
* [PATCH 2/4] ARM64: perf: wire up perf_regs and unwind support
From: Jean Pihet @ 2014-01-22 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390399879-5109-1-git-send-email-jean.pihet@linaro.org>
From: Jean Pihet <jean.pihet@newoldbits.com>
This patch hooks in the perf_regs and libunwind code for ARM64.
The tools/perf/arch/arm64 is created; it contains the arch specific
code for DWARF unwinding.
Signed-off-by: Jean Pihet <jean.pihet@linaro.org>
Cc: Will Deacon <will.deacon@arm.com>
---
tools/perf/arch/arm64/Makefile | 7 +++
tools/perf/arch/arm64/include/perf_regs.h | 88 +++++++++++++++++++++++++++++++
tools/perf/arch/arm64/util/dwarf-regs.c | 80 ++++++++++++++++++++++++++++
tools/perf/arch/arm64/util/unwind.c | 82 ++++++++++++++++++++++++++++
tools/perf/config/Makefile | 8 ++-
5 files changed, 264 insertions(+), 1 deletion(-)
create mode 100644 tools/perf/arch/arm64/Makefile
create mode 100644 tools/perf/arch/arm64/include/perf_regs.h
create mode 100644 tools/perf/arch/arm64/util/dwarf-regs.c
create mode 100644 tools/perf/arch/arm64/util/unwind.c
diff --git a/tools/perf/arch/arm64/Makefile b/tools/perf/arch/arm64/Makefile
new file mode 100644
index 0000000..fe9b61e
--- /dev/null
+++ b/tools/perf/arch/arm64/Makefile
@@ -0,0 +1,7 @@
+ifndef NO_DWARF
+PERF_HAVE_DWARF_REGS := 1
+LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/dwarf-regs.o
+endif
+ifndef NO_LIBUNWIND
+LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/unwind.o
+endif
diff --git a/tools/perf/arch/arm64/include/perf_regs.h b/tools/perf/arch/arm64/include/perf_regs.h
new file mode 100644
index 0000000..2359546
--- /dev/null
+++ b/tools/perf/arch/arm64/include/perf_regs.h
@@ -0,0 +1,88 @@
+#ifndef ARCH_PERF_REGS_H
+#define ARCH_PERF_REGS_H
+
+#include <stdlib.h>
+#include "../../util/types.h"
+#include <asm/perf_regs.h>
+
+#define PERF_REGS_MASK ((1ULL << PERF_REG_ARM64_MAX) - 1)
+#define PERF_REG_IP PERF_REG_ARM64_PC
+#define PERF_REG_SP PERF_REG_ARM64_SP
+
+static inline const char *perf_reg_name(int id)
+{
+ switch (id) {
+ case PERF_REG_ARM64_X0:
+ return "x0";
+ case PERF_REG_ARM64_X1:
+ return "x1";
+ case PERF_REG_ARM64_X2:
+ return "x2";
+ case PERF_REG_ARM64_X3:
+ return "x3";
+ case PERF_REG_ARM64_X4:
+ return "x4";
+ case PERF_REG_ARM64_X5:
+ return "x5";
+ case PERF_REG_ARM64_X6:
+ return "x6";
+ case PERF_REG_ARM64_X7:
+ return "x7";
+ case PERF_REG_ARM64_X8:
+ return "x8";
+ case PERF_REG_ARM64_X9:
+ return "x9";
+ case PERF_REG_ARM64_X10:
+ return "x10";
+ case PERF_REG_ARM64_X11:
+ return "x11";
+ case PERF_REG_ARM64_X12:
+ return "x12";
+ case PERF_REG_ARM64_X13:
+ return "x13";
+ case PERF_REG_ARM64_X14:
+ return "x14";
+ case PERF_REG_ARM64_X15:
+ return "x15";
+ case PERF_REG_ARM64_X16:
+ return "x16";
+ case PERF_REG_ARM64_X17:
+ return "x17";
+ case PERF_REG_ARM64_X18:
+ return "x18";
+ case PERF_REG_ARM64_X19:
+ return "x19";
+ case PERF_REG_ARM64_X20:
+ return "x20";
+ case PERF_REG_ARM64_X21:
+ return "x21";
+ case PERF_REG_ARM64_X22:
+ return "x22";
+ case PERF_REG_ARM64_X23:
+ return "x23";
+ case PERF_REG_ARM64_X24:
+ return "x24";
+ case PERF_REG_ARM64_X25:
+ return "x25";
+ case PERF_REG_ARM64_X26:
+ return "x26";
+ case PERF_REG_ARM64_X27:
+ return "x27";
+ case PERF_REG_ARM64_X28:
+ return "x28";
+ case PERF_REG_ARM64_X29:
+ return "x29";
+ case PERF_REG_ARM64_SP:
+ return "sp";
+ case PERF_REG_ARM64_LR:
+ return "lr";
+ case PERF_REG_ARM64_PC:
+ return "pc";
+ default:
+ return NULL;
+ }
+
+ return NULL;
+}
+
+#endif /* ARCH_PERF_REGS_H */
diff --git a/tools/perf/arch/arm64/util/dwarf-regs.c b/tools/perf/arch/arm64/util/dwarf-regs.c
new file mode 100644
index 0000000..d49efeb
--- /dev/null
+++ b/tools/perf/arch/arm64/util/dwarf-regs.c
@@ -0,0 +1,80 @@
+/*
+ * Mapping of DWARF debug register numbers into register names.
+ *
+ * Copyright (C) 2010 Will Deacon, ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <stddef.h>
+#include <dwarf-regs.h>
+
+struct pt_regs_dwarfnum {
+ const char *name;
+ unsigned int dwarfnum;
+};
+
+#define STR(s) #s
+#define REG_DWARFNUM_NAME(r, num) {.name = r, .dwarfnum = num}
+#define GPR_DWARFNUM_NAME(num) \
+ {.name = STR(%x##num), .dwarfnum = num}
+#define REG_DWARFNUM_END {.name = NULL, .dwarfnum = 0}
+
+/*
+ * Reference:
+ * http://infocenter.arm.com/help/topic/com.arm.doc.ihi0057b/IHI0057B_aadwarf64.pdf
+ */
+static const struct pt_regs_dwarfnum regdwarfnum_table[] = {
+ GPR_DWARFNUM_NAME(0),
+ GPR_DWARFNUM_NAME(1),
+ GPR_DWARFNUM_NAME(2),
+ GPR_DWARFNUM_NAME(3),
+ GPR_DWARFNUM_NAME(4),
+ GPR_DWARFNUM_NAME(5),
+ GPR_DWARFNUM_NAME(6),
+ GPR_DWARFNUM_NAME(7),
+ GPR_DWARFNUM_NAME(8),
+ GPR_DWARFNUM_NAME(9),
+ GPR_DWARFNUM_NAME(10),
+ GPR_DWARFNUM_NAME(11),
+ GPR_DWARFNUM_NAME(12),
+ GPR_DWARFNUM_NAME(13),
+ GPR_DWARFNUM_NAME(14),
+ GPR_DWARFNUM_NAME(15),
+ GPR_DWARFNUM_NAME(16),
+ GPR_DWARFNUM_NAME(17),
+ GPR_DWARFNUM_NAME(18),
+ GPR_DWARFNUM_NAME(19),
+ GPR_DWARFNUM_NAME(20),
+ GPR_DWARFNUM_NAME(21),
+ GPR_DWARFNUM_NAME(22),
+ GPR_DWARFNUM_NAME(23),
+ GPR_DWARFNUM_NAME(24),
+ GPR_DWARFNUM_NAME(25),
+ GPR_DWARFNUM_NAME(26),
+ GPR_DWARFNUM_NAME(27),
+ GPR_DWARFNUM_NAME(28),
+ GPR_DWARFNUM_NAME(29),
+ REG_DWARFNUM_NAME("%lr", 30),
+ REG_DWARFNUM_NAME("%sp", 31),
+ REG_DWARFNUM_END,
+};
+
+/**
+ * get_arch_regstr() - lookup register name from it's DWARF register number
+ * @n: the DWARF register number
+ *
+ * get_arch_regstr() returns the name of the register in struct
+ * regdwarfnum_table from it's DWARF register number. If the register is not
+ * found in the table, this returns NULL;
+ */
+const char *get_arch_regstr(unsigned int n)
+{
+ const struct pt_regs_dwarfnum *roff;
+ for (roff = regdwarfnum_table; roff->name != NULL; roff++)
+ if (roff->dwarfnum == n)
+ return roff->name;
+ return NULL;
+}
diff --git a/tools/perf/arch/arm64/util/unwind.c b/tools/perf/arch/arm64/util/unwind.c
new file mode 100644
index 0000000..8d37a4c
--- /dev/null
+++ b/tools/perf/arch/arm64/util/unwind.c
@@ -0,0 +1,82 @@
+
+#include <errno.h>
+#include <libunwind.h>
+#include "perf_regs.h"
+#include "../../util/unwind.h"
+
+int unwind__arch_reg_id(int regnum)
+{
+ switch (regnum) {
+ case UNW_AARCH64_X0:
+ return PERF_REG_ARM64_X0;
+ case UNW_AARCH64_X1:
+ return PERF_REG_ARM64_X1;
+ case UNW_AARCH64_X2:
+ return PERF_REG_ARM64_X2;
+ case UNW_AARCH64_X3:
+ return PERF_REG_ARM64_X3;
+ case UNW_AARCH64_X4:
+ return PERF_REG_ARM64_X4;
+ case UNW_AARCH64_X5:
+ return PERF_REG_ARM64_X5;
+ case UNW_AARCH64_X6:
+ return PERF_REG_ARM64_X6;
+ case UNW_AARCH64_X7:
+ return PERF_REG_ARM64_X7;
+ case UNW_AARCH64_X8:
+ return PERF_REG_ARM64_X8;
+ case UNW_AARCH64_X9:
+ return PERF_REG_ARM64_X9;
+ case UNW_AARCH64_X10:
+ return PERF_REG_ARM64_X10;
+ case UNW_AARCH64_X11:
+ return PERF_REG_ARM64_X11;
+ case UNW_AARCH64_X12:
+ return PERF_REG_ARM64_X12;
+ case UNW_AARCH64_X13:
+ return PERF_REG_ARM64_X13;
+ case UNW_AARCH64_X14:
+ return PERF_REG_ARM64_X14;
+ case UNW_AARCH64_X15:
+ return PERF_REG_ARM64_X15;
+ case UNW_AARCH64_X16:
+ return PERF_REG_ARM64_X16;
+ case UNW_AARCH64_X17:
+ return PERF_REG_ARM64_X17;
+ case UNW_AARCH64_X18:
+ return PERF_REG_ARM64_X18;
+ case UNW_AARCH64_X19:
+ return PERF_REG_ARM64_X19;
+ case UNW_AARCH64_X20:
+ return PERF_REG_ARM64_X20;
+ case UNW_AARCH64_X21:
+ return PERF_REG_ARM64_X21;
+ case UNW_AARCH64_X22:
+ return PERF_REG_ARM64_X22;
+ case UNW_AARCH64_X23:
+ return PERF_REG_ARM64_X23;
+ case UNW_AARCH64_X24:
+ return PERF_REG_ARM64_X24;
+ case UNW_AARCH64_X25:
+ return PERF_REG_ARM64_X25;
+ case UNW_AARCH64_X26:
+ return PERF_REG_ARM64_X26;
+ case UNW_AARCH64_X27:
+ return PERF_REG_ARM64_X27;
+ case UNW_AARCH64_X28:
+ return PERF_REG_ARM64_X28;
+ case UNW_AARCH64_X29:
+ return PERF_REG_ARM64_X29;
+ case UNW_AARCH64_X30:
+ return PERF_REG_ARM64_LR;
+ case UNW_AARCH64_SP:
+ return PERF_REG_ARM64_SP;
+ case UNW_AARCH64_PC:
+ return PERF_REG_ARM64_PC;
+ default:
+ pr_err("unwind: invalid reg id %d\n", regnum);
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index d604e50..2fdcd68 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -29,11 +29,17 @@ ifeq ($(ARCH),x86)
endif
NO_PERF_REGS := 0
endif
+
ifeq ($(ARCH),arm)
NO_PERF_REGS := 0
LIBUNWIND_LIBS = -lunwind -lunwind-arm
endif
+ifeq ($(ARCH),arm64)
+ NO_PERF_REGS := 0
+ LIBUNWIND_LIBS = -lunwind -lunwind-aarch64
+endif
+
ifeq ($(LIBUNWIND_LIBS),)
NO_LIBUNWIND := 1
else
@@ -327,7 +333,7 @@ ifndef NO_LIBUNWIND
msg := $(warning No libunwind found, disabling post unwind support. Please install libunwind-dev[el] >= 1.1);
NO_LIBUNWIND := 1
else
- ifeq ($(ARCH),arm)
+ ifeq ($(ARCH),$(filter $(ARCH),arm arm64))
$(call feature_check,libunwind-debug-frame)
ifneq ($(feature-libunwind-debug-frame), 1)
msg := $(warning No debug_frame support found in libunwind);
--
1.7.11.7
^ permalink raw reply related
* [PATCH 1/4] ARM64: perf: add support for perf registers API
From: Jean Pihet @ 2014-01-22 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390399879-5109-1-git-send-email-jean.pihet@linaro.org>
From: Jean Pihet <jean.pihet@newoldbits.com>
This patch implements the functions required for the perf registers API,
allowing the perf tool to interface kernel register dumps with libunwind
in order to provide userspace backtracing.
Compat mode is also supported.
Only the general purpose user space registers are exported, i.e.:
PERF_REG_ARM_X0,
...
PERF_REG_ARM_X28,
PERF_REG_ARM_FP,
PERF_REG_ARM_LR,
PERF_REG_ARM_SP,
PERF_REG_ARM_PC
and not the PERF_REG_ARM_V* registers.
Signed-off-by: Jean Pihet <jean.pihet@linaro.org>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/Kconfig | 2 ++
arch/arm64/include/asm/ptrace.h | 1 +
arch/arm64/include/uapi/asm/Kbuild | 1 +
arch/arm64/include/uapi/asm/perf_regs.h | 40 ++++++++++++++++++++++++++++++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/perf_regs.c | 44 +++++++++++++++++++++++++++++++++
6 files changed, 89 insertions(+)
create mode 100644 arch/arm64/include/uapi/asm/perf_regs.h
create mode 100644 arch/arm64/kernel/perf_regs.c
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index dd4327f..e9899bb 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -37,6 +37,8 @@ config ARM64
select HAVE_HW_BREAKPOINT if PERF_EVENTS
select HAVE_MEMBLOCK
select HAVE_PERF_EVENTS
+ select HAVE_PERF_REGS
+ select HAVE_PERF_USER_STACK_DUMP
select IRQ_DOMAIN
select MODULES_USE_ELF_RELA
select NO_BOOTMEM
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index 0e7fa49..fbb0020 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -68,6 +68,7 @@
/* Architecturally defined mapping between AArch32 and AArch64 registers */
#define compat_usr(x) regs[(x)]
+#define compat_fp regs[11]
#define compat_sp regs[13]
#define compat_lr regs[14]
#define compat_sp_hyp regs[15]
diff --git a/arch/arm64/include/uapi/asm/Kbuild b/arch/arm64/include/uapi/asm/Kbuild
index e4b78bd..942376d 100644
--- a/arch/arm64/include/uapi/asm/Kbuild
+++ b/arch/arm64/include/uapi/asm/Kbuild
@@ -9,6 +9,7 @@ header-y += byteorder.h
header-y += fcntl.h
header-y += hwcap.h
header-y += kvm_para.h
+header-y += perf_regs.h
header-y += param.h
header-y += ptrace.h
header-y += setup.h
diff --git a/arch/arm64/include/uapi/asm/perf_regs.h b/arch/arm64/include/uapi/asm/perf_regs.h
new file mode 100644
index 0000000..172b831
--- /dev/null
+++ b/arch/arm64/include/uapi/asm/perf_regs.h
@@ -0,0 +1,40 @@
+#ifndef _ASM_ARM64_PERF_REGS_H
+#define _ASM_ARM64_PERF_REGS_H
+
+enum perf_event_arm_regs {
+ PERF_REG_ARM64_X0,
+ PERF_REG_ARM64_X1,
+ PERF_REG_ARM64_X2,
+ PERF_REG_ARM64_X3,
+ PERF_REG_ARM64_X4,
+ PERF_REG_ARM64_X5,
+ PERF_REG_ARM64_X6,
+ PERF_REG_ARM64_X7,
+ PERF_REG_ARM64_X8,
+ PERF_REG_ARM64_X9,
+ PERF_REG_ARM64_X10,
+ PERF_REG_ARM64_X11,
+ PERF_REG_ARM64_X12,
+ PERF_REG_ARM64_X13,
+ PERF_REG_ARM64_X14,
+ PERF_REG_ARM64_X15,
+ PERF_REG_ARM64_X16,
+ PERF_REG_ARM64_X17,
+ PERF_REG_ARM64_X18,
+ PERF_REG_ARM64_X19,
+ PERF_REG_ARM64_X20,
+ PERF_REG_ARM64_X21,
+ PERF_REG_ARM64_X22,
+ PERF_REG_ARM64_X23,
+ PERF_REG_ARM64_X24,
+ PERF_REG_ARM64_X25,
+ PERF_REG_ARM64_X26,
+ PERF_REG_ARM64_X27,
+ PERF_REG_ARM64_X28,
+ PERF_REG_ARM64_X29,
+ PERF_REG_ARM64_LR,
+ PERF_REG_ARM64_SP,
+ PERF_REG_ARM64_PC,
+ PERF_REG_ARM64_MAX,
+};
+#endif /* _ASM_ARM64_PERF_REGS_H */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 2d4554b..9a5d592 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -15,6 +15,7 @@ arm64-obj-$(CONFIG_COMPAT) += sys32.o kuser32.o signal32.o \
sys_compat.o
arm64-obj-$(CONFIG_MODULES) += arm64ksyms.o module.o
arm64-obj-$(CONFIG_SMP) += smp.o smp_spin_table.o
+arm64-obj-$(CONFIG_PERF_EVENTS) += perf_regs.o
arm64-obj-$(CONFIG_HW_PERF_EVENTS) += perf_event.o
arm64-obj-$(CONFIG_HAVE_HW_BREAKPOINT)+= hw_breakpoint.o
arm64-obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
diff --git a/arch/arm64/kernel/perf_regs.c b/arch/arm64/kernel/perf_regs.c
new file mode 100644
index 0000000..f2d6f0a
--- /dev/null
+++ b/arch/arm64/kernel/perf_regs.c
@@ -0,0 +1,44 @@
+#include <linux/errno.h>
+#include <linux/kernel.h>
+#include <linux/perf_event.h>
+#include <linux/bug.h>
+#include <asm/perf_regs.h>
+#include <asm/ptrace.h>
+
+u64 perf_reg_value(struct pt_regs *regs, int idx)
+{
+ if (WARN_ON_ONCE((u32)idx >= PERF_REG_ARM64_MAX))
+ return 0;
+
+ /*
+ * Compat (i.e. 32 bit) mode:
+ * - PC has been set in the pt_regs struct in kernel_entry,
+ * - Handle SP and LR here.
+ */
+ if (compat_user_mode(regs)) {
+ if ((u32)idx == PERF_REG_ARM64_SP)
+ return regs->compat_sp;
+ if ((u32)idx == PERF_REG_ARM64_LR)
+ return regs->compat_lr;
+ }
+
+ return regs->regs[idx];
+}
+
+#define REG_RESERVED (~((1ULL << PERF_REG_ARM64_MAX) - 1))
+
+int perf_reg_validate(u64 mask)
+{
+ if (!mask || mask & REG_RESERVED)
+ return -EINVAL;
+
+ return 0;
+}
+
+u64 perf_reg_abi(struct task_struct *task)
+{
+ if (is_compat_thread(task_thread_info(task)))
+ return PERF_SAMPLE_REGS_ABI_32;
+ else
+ return PERF_SAMPLE_REGS_ABI_64;
+}
--
1.7.11.7
^ permalink raw reply related
* [PATCH v5 0/4] perf: AARCH64 arch support
From: Jean Pihet @ 2014-01-22 14:11 UTC (permalink / raw)
To: linux-arm-kernel
Add AARCH64 specific support. This includes the following:
- AARCH64 perf registers definition and hooks,
- compat mode registers use, i.e. profiling a 32-bit binary on
a 64-bit system,
- unwinding using the dwarf information from the .debug_frame
section of the ELF binary,
- unwinding using the frame pointer information; in 64-bit and
compat modes.
Note: support for unwinding using the dwarf information in compat
mode requires some changes to the libunwind code. Those changes
have been submitted on the libunwind ML and are in discussion.
Tested on ARMv7, ARMv8 and x86_64 platforms. The compat mode has been
tested on ARMv8 using statically built 32-bit binaries.
Jean Pihet (4):
ARM64: perf: add support for perf registers API
ARM64: perf: wire up perf_regs and unwind support
ARM64: perf: add support for frame pointer unwinding in compat mode
ARM64: perf: support dwarf unwinding in compat mode
arch/arm64/Kconfig | 2 +
arch/arm64/include/asm/compat.h | 2 +-
arch/arm64/include/asm/ptrace.h | 3 +-
arch/arm64/include/uapi/asm/Kbuild | 1 +
arch/arm64/include/uapi/asm/perf_regs.h | 40 ++++++++++++++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/perf_event.c | 75 +++++++++++++++++++++++---
arch/arm64/kernel/perf_regs.c | 44 ++++++++++++++++
tools/perf/arch/arm64/Makefile | 7 +++
tools/perf/arch/arm64/include/perf_regs.h | 88 +++++++++++++++++++++++++++++++
tools/perf/arch/arm64/util/dwarf-regs.c | 80 ++++++++++++++++++++++++++++
tools/perf/arch/arm64/util/unwind.c | 82 ++++++++++++++++++++++++++++
tools/perf/config/Makefile | 8 ++-
13 files changed, 422 insertions(+), 11 deletions(-)
create mode 100644 arch/arm64/include/uapi/asm/perf_regs.h
create mode 100644 arch/arm64/kernel/perf_regs.c
create mode 100644 tools/perf/arch/arm64/Makefile
create mode 100644 tools/perf/arch/arm64/include/perf_regs.h
create mode 100644 tools/perf/arch/arm64/util/dwarf-regs.c
create mode 100644 tools/perf/arch/arm64/util/unwind.c
--
1.7.11.7
^ permalink raw reply
* [PATCHv5][ 6/8] ARM: dts: mbimx51sd: Add display support.
From: Denis Carikli @ 2014-01-22 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201312052156.50236.marex@denx.de>
On 12/05/2013 09:56 PM, Marek Vasut wrote:
>> +++ b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
[...]
>> +&display {
>> + display-supply = <®_lcd_3v3>;
>> + status = "okay";
>
> The "status = " here should probably be in the board DTS, not in the LCD DTS.
The display is optional on the baseboard of the cpuimx51.
So my idea was to activate the display only for the configurations where
it's used.
Denis.
^ permalink raw reply
* [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group notifier block
From: Varun Sethi @ 2014-01-22 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122134028.GB14108@mudshark.cambridge.arm.com>
> -----Original Message-----
> From: Will Deacon [mailto:will.deacon at arm.com]
> Sent: Wednesday, January 22, 2014 7:10 PM
> To: Sethi Varun-B16395
> Cc: Andreas Herrmann; iommu at lists.linux-foundation.org; linux-arm-
> kernel at lists.infradead.org; Andreas Herrmann
> Subject: Re: [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group
> notifier block
>
> On Wed, Jan 22, 2014 at 01:14:13PM +0000, Varun Sethi wrote:
> > > On Tue, Jan 21, 2014 at 05:48:02PM +0000, Varun Sethi wrote:
> > > > > +static int arm_smmu_group_notifier(struct notifier_block *nb,
> > > > > + unsigned long action, void *data) {
> > > > > + struct device *dev = data;
> > > > > + struct dma_iommu_mapping *mapping;
> > > > > + struct arm_smmu_device *smmu;
> > > > > + int ret;
> > > > > +
> > > > > + switch (action) {
> > > > > + case IOMMU_GROUP_NOTIFY_BIND_DRIVER:
> > > > > +
> > > > > + smmu = dev->archdata.iommu;
> > > > > + if (!smmu || !(smmu->options &
> ARM_SMMU_OPT_ISOLATE_DEVICES))
> > > > > + break;
> > > > [Sethi Varun-B16395] Should this check be really done here? The
> > > > "Isolate devices" property would allow us to set up iommu groups.
> > > > My understanding is that if we specify the isolate devices
> > > > property, then each device would have a separate iommu group
> > > > otherwise all devices connected to the SMMU would share the iommu
> group.
> > >
> > > That's not what currently happens (at least, in the patch I have
> > > queued for groups). The code queued adds each device to its own
> > > group in arm_smmu_add_device, which I think is the right thing to do.
> > >
> > > > With that logic, we should link the mapping to the iommu group.
> > >
> > > Ok, so are you suggesting that we perform the isolation mapping in
> > > arm_smmu_add_device and drop the notifier altogether?
> > I think that should be fine, until we want to delay mapping creation
> > till driver bind time.
>
> Is there a hard dependency on that?
>
Not sure, may be Andreas can answer that.
> > But the "isolate device" property should dictate iommu group creation.
>
> The reason we added automatic group creation (per-device) is for VFIO,
> which expects all devices to be in a group regardless of the device
> isolation configuration.
>
IIUC, with the "isolate devices" property we ensure that there would be independent SMR and S2CR per device. Is that correct?
-Varun
^ permalink raw reply
* [PATCH 5/5 v2] ARM: integrator: select AMBA bus and GPIO block
From: Linus Walleij @ 2014-01-22 13:49 UTC (permalink / raw)
To: linux-arm-kernel
The Integrator/AP can be used with a logic module called
IM-PD1, which contains a few AMBA PrimeCell devices, one of which
is the PL061 GPIO controller. As the lines from this GPIO
controller are looped back to devices on the board itself and
provides resources back to it, we need to always have GPIO
and the PL061 driver available for other devices to work.
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Drop selection of ARM_AMBA as this is already done by the
parent ARCH_INTEGRATOR symbol.
---
arch/arm/mach-integrator/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-integrator/Kconfig b/arch/arm/mach-integrator/Kconfig
index 46be99007529..6e8b0e10b420 100644
--- a/arch/arm/mach-integrator/Kconfig
+++ b/arch/arm/mach-integrator/Kconfig
@@ -30,7 +30,9 @@ config ARCH_CINTEGRATOR
config INTEGRATOR_IMPD1
tristate "Include support for Integrator/IM-PD1"
depends on ARCH_INTEGRATOR_AP
+ select ARCH_REQUIRE_GPIOLIB
select ARM_VIC
+ select GPIO_PL061 if GPIOLIB
help
The IM-PD1 is an add-on logic module for the Integrator which
allows ARM(R) Ltd PrimeCells to be developed and evaluated.
--
1.8.4.2
^ permalink raw reply related
* [PATCHv6 7/7] ARM: dts: mbimx51sd: Add CMO-QVGA backlight support.
From: Denis Carikli @ 2014-01-22 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390398511-8041-1-git-send-email-denis@eukrea.com>
Cc: Eric B?nard <eric@eukrea.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Denis Carikli <denis@eukrea.com>
---
ChangeLog v5->v6:
- Reordered the Cc list.
ChangeLog v3->v5:
- Updated to the new GPIO defines.
ChangeLog v2->v3:
- Splitted out from the patch that added support for the cpuimx51/mbimxsd51 boards.
- This patch now only adds backlight support.
- Added some interested people in the Cc list, and removed some people that
might be annoyed by the receiving of that patch which is unrelated to their
subsystem.
---
.../imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
index f37d65b..f8f5abe 100644
--- a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
+++ b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
@@ -17,6 +17,14 @@
model = "Eukrea MBIMXSD51 with the CMO-QVGA Display";
compatible = "eukrea,mbimxsd51-baseboard-cmo-qvga", "eukrea,mbimxsd51-baseboard", "eukrea,cpuimx51", "fsl,imx51";
+ backlight {
+ compatible = "gpio-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_backlight_1>;
+ gpios = <&gpio3 4 GPIO_ACTIVE_HIGH>;
+ default-brightness-level = <1>;
+ };
+
reg_lcd_3v3: lcd-en {
compatible = "regulator-fixed";
pinctrl-names = "default";
--
1.7.9.5
^ permalink raw reply related
* [PATCHv6 6/7] ARM: dts: mbimx51sd: Add display support.
From: Denis Carikli @ 2014-01-22 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390398511-8041-1-git-send-email-denis@eukrea.com>
The CMO-QVGA, DVI-SVGA and DVI-VGA are added.
Cc: Eric B?nard <eric@eukrea.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Denis Carikli <denis@eukrea.com>
---
ChangeLog v5->v6:
- Reordered the Cc list.
ChangeLog v3->v5:
- Updated to new GPIO defines.
- Updated to new licenses checkpatch requirements.
- one whitespace cleanup.
ChangeLog v2->v3:
- Splitted out from the patch that added support for the cpuimx51/mbimxsd51 boards.
- This patch now only adds display support.
- Added some interested people in the Cc list, and removed some people that
might be annoyed by the receiving of that patch which is unrelated to their
subsystem.
- rebased and reworked the dts displays addition.
- Also rebased and reworked the fsl,pins usage.
---
.../imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts | 55 ++++++++++++++++++++
.../imx51-eukrea-mbimxsd51-baseboard-dvi-svga.dts | 42 +++++++++++++++
.../imx51-eukrea-mbimxsd51-baseboard-dvi-vga.dts | 42 +++++++++++++++
.../boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts | 13 +++++
4 files changed, 152 insertions(+)
create mode 100644 arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
create mode 100644 arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-svga.dts
create mode 100644 arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-vga.dts
diff --git a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
new file mode 100644
index 0000000..f37d65b
--- /dev/null
+++ b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
@@ -0,0 +1,55 @@
+/*
+ * Copyright 2013 Eukr?a Electromatique <denis@eukrea.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * 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.
+ */
+
+#include "imx51-eukrea-mbimxsd51-baseboard.dts"
+
+/ {
+ model = "Eukrea MBIMXSD51 with the CMO-QVGA Display";
+ compatible = "eukrea,mbimxsd51-baseboard-cmo-qvga", "eukrea,mbimxsd51-baseboard", "eukrea,cpuimx51", "fsl,imx51";
+
+ reg_lcd_3v3: lcd-en {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_lcd_3v3>;
+ regulator-name = "lcd-3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio3 13 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+};
+
+&display {
+ display-supply = <®_lcd_3v3>;
+ status = "okay";
+ display-timings {
+ model = "CMO-QVGA";
+ bits-per-pixel = <16>;
+ cmoqvga {
+ native-mode;
+ clock-frequency = <6500000>;
+ hactive = <320>;
+ vactive = <240>;
+ hfront-porch = <20>;
+ hback-porch = <38>;
+ vfront-porch = <4>;
+ vback-porch = <15>;
+ hsync-len = <30>;
+ vsync-len = <3>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <0>;
+ pixelclk-active = <1>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-svga.dts b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-svga.dts
new file mode 100644
index 0000000..07e80e8
--- /dev/null
+++ b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-svga.dts
@@ -0,0 +1,42 @@
+/*
+ * Copyright 2013 Eukr?a Electromatique <denis@eukrea.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * 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.
+ */
+
+#include "imx51-eukrea-mbimxsd51-baseboard.dts"
+
+/ {
+ model = "Eukrea MBIMXSD51 with the DVI-SVGA Display";
+ compatible = "eukrea,mbimxsd51-baseboard-dvi-svga", "eukrea,mbimxsd51-baseboard", "eukrea,cpuimx51", "fsl,imx51";
+};
+
+&display {
+ status = "okay";
+ display-timings {
+ model = "DVI-SVGA";
+ bits-per-pixel = <16>;
+ svga {
+ clock-frequency = <38251000>;
+ hactive = <800>;
+ vactive = <600>;
+ hback-porch = <112>;
+ hfront-porch = <32>;
+ vback-porch = <3>;
+ vfront-porch = <17>;
+ hsync-len = <80>;
+ vsync-len = <4>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ de-active = <1>;
+ pixelclk-active = <0>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-vga.dts b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-vga.dts
new file mode 100644
index 0000000..0ec523f
--- /dev/null
+++ b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-vga.dts
@@ -0,0 +1,42 @@
+/*
+ * Copyright 2013 Eukr?a Electromatique <denis@eukrea.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * 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.
+ */
+
+#include "imx51-eukrea-mbimxsd51-baseboard.dts"
+
+/ {
+ model = "Eukrea MBIMXSD51 with the DVI-VGA Display";
+ compatible = "eukrea,mbimxsd51-baseboard-dvi-vga", "eukrea,mbimxsd51-baseboard", "eukrea,cpuimx51", "fsl,imx51";
+};
+
+&display {
+ status = "okay";
+ display-timings {
+ model = "DVI-VGA";
+ bits-per-pixel = <16>;
+ vga {
+ clock-frequency = <23750000>;
+ hactive = <640>;
+ vactive = <480>;
+ hback-porch = <80>;
+ hfront-porch = <16>;
+ vback-porch = <3>;
+ vfront-porch = <13>;
+ hsync-len = <64>;
+ vsync-len = <4>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ de-active = <1>;
+ pixelclk-active = <0>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts
index 6774c66..06f987e 100644
--- a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts
+++ b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts
@@ -23,6 +23,15 @@
model = "Eukrea CPUIMX51";
compatible = "eukrea,mbimxsd51","eukrea,cpuimx51", "fsl,imx51";
+ display: display at di0 {
+ compatible = "fsl,imx-parallel-display";
+ crtcs = <&ipu 0>;
+ interface-pix-fmt = "rgb666";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu_disp1>;
+ status = "disabled";
+ };
+
gpio_keys {
compatible = "gpio-keys";
pinctrl-names = "default";
@@ -124,6 +133,10 @@
>;
};
+ pinctrl_ipu_disp1: ipudisp1grp {
+ fsl,pins = <MX51_IPU_DISP1_PINGRP1>;
+ };
+
pinctrl_reg_lcd_3v3: reg_lcd_3v3 {
fsl,pins = <
MX51_PAD_CSI1_D9__GPIO3_13 0x1f5
--
1.7.9.5
^ permalink raw reply related
* [PATCHv6 4/7] staging: imx-drm: Use de-active and pixelclk-active display-timings.
From: Denis Carikli @ 2014-01-22 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390398511-8041-1-git-send-email-denis@eukrea.com>
If de-active and/or pixelclk-active properties were set in the
display-timings DT node, they were not used.
Instead the data-enable and the pixel data clock polarity
were hardcoded.
This change is needed for making the eukrea-cpuimx51
QVGA display work.
Cc: David Airlie <airlied@linux.ie>
Cc: Eric B?nard <eric@eukrea.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: dri-devel at lists.freedesktop.org
Cc: driverdev-devel at linuxdriverproject.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Denis Carikli <denis@eukrea.com>
---
ChangeLog v5->v6:
- Remove people not concerned by this patch from the Cc list.
- Removed wrong coments from the code.
- Corrected the code style of the "if (!!val)"
ChangeLog v3->v4:
- The old patch was named "staging: imx-drm: ipuv3-crtc: don't harcode some mode".
- Reworked the patch entierly: we now takes the mode flags from the device tree.
ChangeLog v2->v3:
- Added some interested people in the Cc list.
- Ajusted the flags to match the changes in "drm: Add the lacking
DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*"
---
drivers/staging/imx-drm/imx-drm.h | 3 +++
drivers/staging/imx-drm/ipuv3-crtc.c | 8 ++++++--
drivers/staging/imx-drm/parallel-display.c | 27 +++++++++++++++++++++++++++
3 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-drm.h b/drivers/staging/imx-drm/imx-drm.h
index ae90c9c..dfdc180 100644
--- a/drivers/staging/imx-drm/imx-drm.h
+++ b/drivers/staging/imx-drm/imx-drm.h
@@ -5,6 +5,9 @@
#define IPU_PIX_FMT_GBR24 v4l2_fourcc('G', 'B', 'R', '3')
+#define IMXDRM_MODE_FLAG_DE_HIGH (1<<0)
+#define IMXDRM_MODE_FLAG_PIXDATA_POSEDGE (1<<1)
+
struct drm_crtc;
struct drm_connector;
struct drm_device;
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c b/drivers/staging/imx-drm/ipuv3-crtc.c
index ce6ba98..ce8e6e4 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -156,8 +156,12 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
sig_cfg.Vsync_pol = 1;
- sig_cfg.enable_pol = 1;
- sig_cfg.clk_pol = 1;
+ if (mode->private_flags & IMXDRM_MODE_FLAG_DE_HIGH)
+ sig_cfg.enable_pol = 1;
+
+ if (mode->private_flags & IMXDRM_MODE_FLAG_PIXDATA_POSEDGE)
+ sig_cfg.clk_pol = 1;
+
sig_cfg.width = mode->hdisplay;
sig_cfg.height = mode->vdisplay;
sig_cfg.pixel_fmt = out_pixel_fmt;
diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-drm/parallel-display.c
index bb71d6d..02aa4da 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -74,7 +74,34 @@ static int imx_pd_connector_get_modes(struct drm_connector *connector)
if (np) {
struct drm_display_mode *mode = drm_mode_create(connector->dev);
+ struct device_node *timings_np;
+ struct device_node *mode_np;
+ u32 val;
+
of_get_drm_display_mode(np, &imxpd->mode, 0);
+
+ timings_np = of_get_child_by_name(np, "display-timings");
+ if (timings_np) {
+ /* get the display mode node */
+ mode_np = of_parse_phandle(timings_np,
+ "native-mode", 0);
+ if (!mode_np)
+ mode_np = of_get_next_child(timings_np, NULL);
+
+ /* set de-active to 1 if not set */
+ of_property_read_u32(mode_np, "de-active", &val);
+ if (val) {
+ imxpd->mode.private_flags |=
+ IMXDRM_MODE_FLAG_DE_HIGH;
+ }
+
+ /* set pixelclk-active to 1 if not set */
+ of_property_read_u32(mode_np, "pixelclk-active", &val);
+ if (val) {
+ imxpd->mode.private_flags |=
+ IMXDRM_MODE_FLAG_PIXDATA_POSEDGE;
+ }
+ }
drm_mode_copy(mode, &imxpd->mode);
mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
drm_mode_probed_add(connector, mode);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group notifier block
From: Will Deacon @ 2014-01-22 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a73ef0128a0141eabf0a3b899f3afdae@DM2PR03MB479.namprd03.prod.outlook.com>
On Wed, Jan 22, 2014 at 01:14:13PM +0000, Varun Sethi wrote:
> > On Tue, Jan 21, 2014 at 05:48:02PM +0000, Varun Sethi wrote:
> > > > +static int arm_smmu_group_notifier(struct notifier_block *nb,
> > > > + unsigned long action, void *data) {
> > > > + struct device *dev = data;
> > > > + struct dma_iommu_mapping *mapping;
> > > > + struct arm_smmu_device *smmu;
> > > > + int ret;
> > > > +
> > > > + switch (action) {
> > > > + case IOMMU_GROUP_NOTIFY_BIND_DRIVER:
> > > > +
> > > > + smmu = dev->archdata.iommu;
> > > > + if (!smmu || !(smmu->options & ARM_SMMU_OPT_ISOLATE_DEVICES))
> > > > + break;
> > > [Sethi Varun-B16395] Should this check be really done here? The
> > > "Isolate devices" property would allow us to set up iommu groups. My
> > > understanding is that if we specify the isolate devices property, then
> > > each device would have a separate iommu group otherwise all devices
> > > connected to the SMMU would share the iommu group.
> >
> > That's not what currently happens (at least, in the patch I have queued
> > for groups). The code queued adds each device to its own group in
> > arm_smmu_add_device, which I think is the right thing to do.
> >
> > > With that logic, we should link the mapping to the iommu group.
> >
> > Ok, so are you suggesting that we perform the isolation mapping in
> > arm_smmu_add_device and drop the notifier altogether?
> I think that should be fine, until we want to delay mapping creation till
> driver bind time.
Is there a hard dependency on that?
> But the "isolate device" property should dictate iommu group creation.
The reason we added automatic group creation (per-device) is for VFIO, which
expects all devices to be in a group regardless of the device isolation
configuration.
Will
^ permalink raw reply
* [PATCH 5/5] ARM: integrator: select AMBA bus and GPIO block
From: Russell King - ARM Linux @ 2014-01-22 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390397471-6802-6-git-send-email-linus.walleij@linaro.org>
On Wed, Jan 22, 2014 at 02:31:11PM +0100, Linus Walleij wrote:
> The Integrator/AP can be used with a logical module called
logic module
> IM-PD1, which contains a few AMBA PrimeCell devices, one of which
> is the PL061 GPIO controller. As the lines from this GPIO
> controller are looped back to devices on the board itself and
> provides resources back to it, we need to always have GPIO
> and the PL061 driver available for other devices to work.
> config INTEGRATOR_IMPD1
> tristate "Include support for Integrator/IM-PD1"
> depends on ARCH_INTEGRATOR_AP
> + select ARCH_REQUIRE_GPIOLIB
> + select ARM_AMBA
Doesn't ARCH_INTEGRATOR already select ARM_AMBA, which this option already
depends on?
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 5/5] ARM: integrator: select AMBA bus and GPIO block
From: Linus Walleij @ 2014-01-22 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390397471-6802-1-git-send-email-linus.walleij@linaro.org>
The Integrator/AP can be used with a logical module called
IM-PD1, which contains a few AMBA PrimeCell devices, one of which
is the PL061 GPIO controller. As the lines from this GPIO
controller are looped back to devices on the board itself and
provides resources back to it, we need to always have GPIO
and the PL061 driver available for other devices to work.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mach-integrator/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-integrator/Kconfig b/arch/arm/mach-integrator/Kconfig
index 46be99007529..b61e962ef992 100644
--- a/arch/arm/mach-integrator/Kconfig
+++ b/arch/arm/mach-integrator/Kconfig
@@ -30,7 +30,10 @@ config ARCH_CINTEGRATOR
config INTEGRATOR_IMPD1
tristate "Include support for Integrator/IM-PD1"
depends on ARCH_INTEGRATOR_AP
+ select ARCH_REQUIRE_GPIOLIB
+ select ARM_AMBA
select ARM_VIC
+ select GPIO_PL061 if GPIOLIB
help
The IM-PD1 is an add-on logic module for the Integrator which
allows ARM(R) Ltd PrimeCells to be developed and evaluated.
--
1.8.4.2
^ permalink raw reply related
* [PATCH 4/5] ARM: integrator: register the IM-PD1 VIC
From: Linus Walleij @ 2014-01-22 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390397471-6802-1-git-send-email-linus.walleij@linaro.org>
The peripherals on the IM-PD1 has never really been able to
properly fire their IRQs to the main FPGA IRQ controller.
Cascade it properly and register interrupts for all the
devices in the array.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mach-integrator/Kconfig | 1 +
arch/arm/mach-integrator/impd1.c | 45 ++++++++++++++++++++++++++++++++--------
2 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-integrator/Kconfig b/arch/arm/mach-integrator/Kconfig
index abeff25532ab..46be99007529 100644
--- a/arch/arm/mach-integrator/Kconfig
+++ b/arch/arm/mach-integrator/Kconfig
@@ -30,6 +30,7 @@ config ARCH_CINTEGRATOR
config INTEGRATOR_IMPD1
tristate "Include support for Integrator/IM-PD1"
depends on ARCH_INTEGRATOR_AP
+ select ARM_VIC
help
The IM-PD1 is an add-on logic module for the Integrator which
allows ARM(R) Ltd PrimeCells to be developed and evaluated.
diff --git a/arch/arm/mach-integrator/impd1.c b/arch/arm/mach-integrator/impd1.c
index aeeae0d79a18..d9b784824808 100644
--- a/arch/arm/mach-integrator/impd1.c
+++ b/arch/arm/mach-integrator/impd1.c
@@ -23,6 +23,7 @@
#include <linux/io.h>
#include <linux/platform_data/clk-integrator.h>
#include <linux/slab.h>
+#include <linux/irqchip/arm-vic.h>
#include <mach/lm.h>
#include <mach/impd1.h>
@@ -35,6 +36,7 @@ MODULE_PARM_DESC(lmid, "logic module stack position");
struct impd1_module {
void __iomem *base;
+ void __iomem *vic_base;
};
void impd1_tweak_control(struct device *dev, u32 mask, u32 val)
@@ -262,9 +264,6 @@ struct impd1_device {
static struct impd1_device impd1_devs[] = {
{
- .offset = 0x03000000,
- .id = 0x00041190,
- }, {
.offset = 0x00100000,
.irq = { 1 },
.id = 0x00141011,
@@ -304,9 +303,15 @@ static struct impd1_device impd1_devs[] = {
}
};
-static int impd1_probe(struct lm_device *dev)
+/*
+ * Valid IRQs: 0 thru 9 and 11, 10 unused.
+ */
+#define IMPD1_VALID_IRQS 0x00000bffU
+
+static int __init impd1_probe(struct lm_device *dev)
{
struct impd1_module *impd1;
+ int irq_base;
int i;
if (dev->id != module_id)
@@ -325,23 +330,45 @@ static int impd1_probe(struct lm_device *dev)
if (!impd1->base)
return -ENOMEM;
- lm_set_drvdata(dev, impd1);
+ integrator_impd1_clk_init(impd1->base, dev->id);
+
+ if (!devm_request_mem_region(&dev->dev,
+ dev->resource.start + 0x03000000,
+ SZ_4K, "VIC"))
+ return -EBUSY;
- printk("IM-PD1 found at 0x%08lx\n",
- (unsigned long)dev->resource.start);
+ impd1->vic_base = devm_ioremap(&dev->dev,
+ dev->resource.start + 0x03000000,
+ SZ_4K);
+ if (!impd1->vic_base)
+ return -ENOMEM;
- integrator_impd1_clk_init(impd1->base, dev->id);
+ irq_base = vic_init_cascaded(impd1->vic_base, dev->irq,
+ IMPD1_VALID_IRQS, 0);
+
+ lm_set_drvdata(dev, impd1);
+
+ dev_info(&dev->dev, "IM-PD1 found at 0x%08lx\n",
+ (unsigned long)dev->resource.start);
for (i = 0; i < ARRAY_SIZE(impd1_devs); i++) {
struct impd1_device *idev = impd1_devs + i;
struct amba_device *d;
unsigned long pc_base;
char devname[32];
+ int irq1 = idev->irq[0];
+ int irq2 = idev->irq[1];
+
+ /* Translate IRQs to IM-PD1 local numberspace */
+ if (irq1)
+ irq1 += irq_base;
+ if (irq2)
+ irq2 += irq_base;
pc_base = dev->resource.start + idev->offset;
snprintf(devname, 32, "lm%x:%5.5lx", dev->id, idev->offset >> 12);
d = amba_ahb_device_add_res(&dev->dev, devname, pc_base, SZ_4K,
- dev->irq, dev->irq,
+ irq1, irq2,
idev->platform_data, idev->id,
&dev->resource);
if (IS_ERR(d)) {
--
1.8.4.2
^ permalink raw reply related
* [PATCH 3/5] ARM: integrator: use managed resources for the IM-PD1
From: Linus Walleij @ 2014-01-22 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390397471-6802-1-git-send-email-linus.walleij@linaro.org>
Switch the IM-PD1 driver to use managed resources and cut down
on boilerplate.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mach-integrator/impd1.c | 36 ++++++++++--------------------------
1 file changed, 10 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-integrator/impd1.c b/arch/arm/mach-integrator/impd1.c
index 9f82f9dcbb98..aeeae0d79a18 100644
--- a/arch/arm/mach-integrator/impd1.c
+++ b/arch/arm/mach-integrator/impd1.c
@@ -307,25 +307,23 @@ static struct impd1_device impd1_devs[] = {
static int impd1_probe(struct lm_device *dev)
{
struct impd1_module *impd1;
- int i, ret;
+ int i;
if (dev->id != module_id)
return -EINVAL;
- if (!request_mem_region(dev->resource.start, SZ_4K, "LM registers"))
+ if (!devm_request_mem_region(&dev->dev, dev->resource.start,
+ SZ_4K, "LM registers"))
return -EBUSY;
- impd1 = kzalloc(sizeof(struct impd1_module), GFP_KERNEL);
- if (!impd1) {
- ret = -ENOMEM;
- goto release_lm;
- }
+ impd1 = devm_kzalloc(&dev->dev, sizeof(struct impd1_module),
+ GFP_KERNEL);
+ if (!impd1)
+ return -ENOMEM;
- impd1->base = ioremap(dev->resource.start, SZ_4K);
- if (!impd1->base) {
- ret = -ENOMEM;
- goto free_impd1;
- }
+ impd1->base = devm_ioremap(&dev->dev, dev->resource.start, SZ_4K);
+ if (!impd1->base)
+ return -ENOMEM;
lm_set_drvdata(dev, impd1);
@@ -353,14 +351,6 @@ static int impd1_probe(struct lm_device *dev)
}
return 0;
-
- free_impd1:
- if (impd1 && impd1->base)
- iounmap(impd1->base);
- kfree(impd1);
- release_lm:
- release_mem_region(dev->resource.start, SZ_4K);
- return ret;
}
static int impd1_remove_one(struct device *dev, void *data)
@@ -371,16 +361,10 @@ static int impd1_remove_one(struct device *dev, void *data)
static void impd1_remove(struct lm_device *dev)
{
- struct impd1_module *impd1 = lm_get_drvdata(dev);
-
device_for_each_child(&dev->dev, NULL, impd1_remove_one);
integrator_impd1_clk_exit(dev->id);
lm_set_drvdata(dev, NULL);
-
- iounmap(impd1->base);
- kfree(impd1);
- release_mem_region(dev->resource.start, SZ_4K);
}
static struct lm_driver impd1_driver = {
--
1.8.4.2
^ permalink raw reply related
* [PATCH 2/5] irqchip: support cascaded VICs
From: Linus Walleij @ 2014-01-22 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390397471-6802-1-git-send-email-linus.walleij@linaro.org>
This adds support for a VIC to be cascaded off another IRQ.
On the Integrator/AP logical module IM-PD1 there is a VIC
cascaded off the central FPGA IRQ controller so this is
needed for that to work out.
In order for the plug-in board to be able to register all
the devices with their IRQs relative to the offset of the
base obtained for the cascaded VIC, the base IRQ number
is passed back to the caller.
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
tglx: if you're happy with this pls ACK it so I can take this
through the ARM SoC tree.
---
arch/arm/mach-versatile/core.c | 2 +-
drivers/irqchip/irq-vic.c | 53 ++++++++++++++++++++++++++++++++++++-----
include/linux/irqchip/arm-vic.h | 6 +++--
3 files changed, 52 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c
index 3b0572f30d56..36b97212d554 100644
--- a/arch/arm/mach-versatile/core.c
+++ b/arch/arm/mach-versatile/core.c
@@ -108,7 +108,7 @@ void __init versatile_init_irq(void)
np = of_find_matching_node_by_address(NULL, vic_of_match,
VERSATILE_VIC_BASE);
- __vic_init(VA_VIC_BASE, IRQ_VIC_START, ~0, 0, np);
+ __vic_init(VA_VIC_BASE, 0, IRQ_VIC_START, ~0, 0, np);
writel(~0, VA_SIC_BASE + SIC_IRQ_ENABLE_CLEAR);
diff --git a/drivers/irqchip/irq-vic.c b/drivers/irqchip/irq-vic.c
index 70108c1491bc..6002942a231c 100644
--- a/drivers/irqchip/irq-vic.c
+++ b/drivers/irqchip/irq-vic.c
@@ -57,6 +57,7 @@
/**
* struct vic_device - VIC PM device
+ * @parent_irq: The parent IRQ number of the VIC if cascaded, or 0.
* @irq: The IRQ number for the base of the VIC.
* @base: The register base for the VIC.
* @valid_sources: A bitmask of valid interrupts
@@ -224,6 +225,17 @@ static int handle_one_vic(struct vic_device *vic, struct pt_regs *regs)
return handled;
}
+static void vic_handle_irq_cascaded(unsigned int irq, struct irq_desc *desc)
+{
+ u32 stat, hwirq;
+ struct vic_device *vic = irq_desc_get_handler_data(desc);
+
+ while ((stat = readl_relaxed(vic->base + VIC_IRQ_STATUS))) {
+ hwirq = ffs(stat) - 1;
+ generic_handle_irq(irq_find_mapping(vic->domain, hwirq));
+ }
+}
+
/*
* Keep iterating over all registered VIC's until there are no pending
* interrupts.
@@ -246,6 +258,7 @@ static struct irq_domain_ops vic_irqdomain_ops = {
/**
* vic_register() - Register a VIC.
* @base: The base address of the VIC.
+ * @parent_irq: The parent IRQ if cascaded, else 0.
* @irq: The base IRQ for the VIC.
* @valid_sources: bitmask of valid interrupts
* @resume_sources: bitmask of interrupts allowed for resume sources.
@@ -257,7 +270,8 @@ static struct irq_domain_ops vic_irqdomain_ops = {
*
* This also configures the IRQ domain for the VIC.
*/
-static void __init vic_register(void __iomem *base, unsigned int irq,
+static void __init vic_register(void __iomem *base, unsigned int parent_irq,
+ unsigned int irq,
u32 valid_sources, u32 resume_sources,
struct device_node *node)
{
@@ -275,6 +289,12 @@ static void __init vic_register(void __iomem *base, unsigned int irq,
v->resume_sources = resume_sources;
set_handle_irq(vic_handle_irq);
vic_id++;
+
+ if (parent_irq) {
+ irq_set_handler_data(parent_irq, v);
+ irq_set_chained_handler(parent_irq, vic_handle_irq_cascaded);
+ }
+
v->domain = irq_domain_add_simple(node, fls(valid_sources), irq,
&vic_irqdomain_ops, v);
/* create an IRQ mapping for each valid IRQ */
@@ -413,10 +433,10 @@ static void __init vic_init_st(void __iomem *base, unsigned int irq_start,
writel(32, base + VIC_PL190_DEF_VECT_ADDR);
}
- vic_register(base, irq_start, vic_sources, 0, node);
+ vic_register(base, 0, irq_start, vic_sources, 0, node);
}
-void __init __vic_init(void __iomem *base, int irq_start,
+void __init __vic_init(void __iomem *base, int parent_irq, int irq_start,
u32 vic_sources, u32 resume_sources,
struct device_node *node)
{
@@ -453,7 +473,7 @@ void __init __vic_init(void __iomem *base, int irq_start,
vic_init2(base);
- vic_register(base, irq_start, vic_sources, resume_sources, node);
+ vic_register(base, parent_irq, irq_start, vic_sources, resume_sources, node);
}
/**
@@ -466,7 +486,28 @@ void __init __vic_init(void __iomem *base, int irq_start,
void __init vic_init(void __iomem *base, unsigned int irq_start,
u32 vic_sources, u32 resume_sources)
{
- __vic_init(base, irq_start, vic_sources, resume_sources, NULL);
+ __vic_init(base, 0, irq_start, vic_sources, resume_sources, NULL);
+}
+
+/**
+ * vic_init_cascaded() - initialise a cascaded vectored interrupt controller
+ * @base: iomem base address
+ * @parent_irq: the parent IRQ we're cascaded off
+ * @irq_start: starting interrupt number, must be muliple of 32
+ * @vic_sources: bitmask of interrupt sources to allow
+ * @resume_sources: bitmask of interrupt sources to allow for resume
+ *
+ * This returns the base for the new interrupts or negative on error.
+ */
+int __init vic_init_cascaded(void __iomem *base, unsigned int parent_irq,
+ u32 vic_sources, u32 resume_sources)
+{
+ struct vic_device *v;
+
+ v = &vic_devices[vic_id];
+ __vic_init(base, parent_irq, 0, vic_sources, resume_sources, NULL);
+ /* Return out acquired base */
+ return v->irq;
}
#ifdef CONFIG_OF
@@ -489,7 +530,7 @@ int __init vic_of_init(struct device_node *node, struct device_node *parent)
/*
* Passing 0 as first IRQ makes the simple domain allocate descriptors
*/
- __vic_init(regs, 0, interrupt_mask, wakeup_mask, node);
+ __vic_init(regs, 0, 0, interrupt_mask, wakeup_mask, node);
return 0;
}
diff --git a/include/linux/irqchip/arm-vic.h b/include/linux/irqchip/arm-vic.h
index e3c82dc95756..ba46c794b4e5 100644
--- a/include/linux/irqchip/arm-vic.h
+++ b/include/linux/irqchip/arm-vic.h
@@ -29,8 +29,10 @@
struct device_node;
struct pt_regs;
-void __vic_init(void __iomem *base, int irq_start, u32 vic_sources,
- u32 resume_sources, struct device_node *node);
+void __vic_init(void __iomem *base, int parent_irq, int irq_start,
+ u32 vic_sources, u32 resume_sources, struct device_node *node);
void vic_init(void __iomem *base, unsigned int irq_start, u32 vic_sources, u32 resume_sources);
+int vic_init_cascaded(void __iomem *base, unsigned int parent_irq,
+ u32 vic_sources, u32 resume_sources);
#endif
--
1.8.4.2
^ permalink raw reply related
* [PATCH 1/5] irqchip: vic: update the base IRQ member correctly
From: Linus Walleij @ 2014-01-22 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390397471-6802-1-git-send-email-linus.walleij@linaro.org>
When passing 0 as the irq base the VIC driver will dynamically
allocate a number of consecutive interrupt descriptors at some
available number range. Make sure this number is recorded in
the state container rather than the passed-in zero argument
in this case.
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
tglx: if you're happy with this pls ACK it so I can take this
through the ARM SoC tree.
---
drivers/irqchip/irq-vic.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-vic.c b/drivers/irqchip/irq-vic.c
index 8e21ae0bab46..70108c1491bc 100644
--- a/drivers/irqchip/irq-vic.c
+++ b/drivers/irqchip/irq-vic.c
@@ -273,7 +273,6 @@ static void __init vic_register(void __iomem *base, unsigned int irq,
v->base = base;
v->valid_sources = valid_sources;
v->resume_sources = resume_sources;
- v->irq = irq;
set_handle_irq(vic_handle_irq);
vic_id++;
v->domain = irq_domain_add_simple(node, fls(valid_sources), irq,
@@ -282,6 +281,11 @@ static void __init vic_register(void __iomem *base, unsigned int irq,
for (i = 0; i < fls(valid_sources); i++)
if (valid_sources & (1 << i))
irq_create_mapping(v->domain, i);
+ /* If no base IRQ was passed, figure out our allocated base */
+ if (irq)
+ v->irq = irq;
+ else
+ v->irq = irq_find_mapping(v->domain, 0);
}
static void vic_ack_irq(struct irq_data *d)
--
1.8.4.2
^ permalink raw reply related
* [PATCH 0/5] ARM: integrator: cascaded IRQs on IM-PD1
From: Linus Walleij @ 2014-01-22 13:31 UTC (permalink / raw)
To: linux-arm-kernel
This series alters the VIC driver to allow for cascaded VICs off other
IRQ parents, such as the VIC found on the IM-PD1 daughterboard on the
Integrator/AP.
After this series I can start a fully working console on the UARTs on
the IM-PD1 that report their IRQs in /proc/interrupts like this:
root at integrator:/ cat /proc/interrupts
CPU0
17: 111 pic 1 uart-pl010
18: 7 pic 2 uart-pl010
22: 5377 pic 6 timer
24: 0 pic 8 rtc-pl030
33: 0 pic 17 PCIv3 error
39: 102 VIC 1 uart-pl011
40: 7 VIC 2 uart-pl011
Err: 0
(Dumped on the IM-PD1 UART.)
Linus Walleij (5):
irqchip: vic: update the base IRQ member correctly
irqchip: support cascaded VICs
ARM: integrator: use managed resources for the IM-PD1
ARM: integrator: register the IM-PD1 VIC
ARM: integrator: select AMBA bus and GPIO block
arch/arm/mach-integrator/Kconfig | 4 ++
arch/arm/mach-integrator/impd1.c | 81 +++++++++++++++++++++++-----------------
arch/arm/mach-versatile/core.c | 2 +-
drivers/irqchip/irq-vic.c | 59 +++++++++++++++++++++++++----
include/linux/irqchip/arm-vic.h | 6 ++-
5 files changed, 107 insertions(+), 45 deletions(-)
--
1.8.4.2
^ permalink raw reply
* [PATCH 2/3] ARM: kexec: copying code to ioremapped area
From: Russell King - ARM Linux @ 2014-01-22 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390389916-8711-3-git-send-email-wangnan0@huawei.com>
On Wed, Jan 22, 2014 at 07:25:15PM +0800, Wang Nan wrote:
> ARM's kdump is actually corrupted (at least for omap4460), mainly because of
> cache problem: flush_icache_range can't reliably ensure the copied data
> correctly goes into RAM.
Quite right too. You're mistake here is thinking that flush_icache_range()
should push it to RAM. That's incorrect.
flush_icache_range() is there to deal with such things as loadable modules
and self modifying code, where the MMU is not being turned off. Hence, it
only flushes to the point of coherency between the I and D caches, and
any further levels of cache between that point and memory are not touched.
Why should it touch any more levels - it's not the function's purpose.
> After mmu turned off and jump to the trampoline, kexec always failed due
> to random undef instructions.
We already have code in the kernel which deals with shutting the MMU off.
An instance of how this can be done is illustrated in the soft_restart()
code path, and kexec already uses this.
One of the first things soft_restart() does is turn off the outer cache -
which OMAP4 does have, but this can only be done if there is a single CPU
running. If there's multiple CPUs running, then the outer cache can't be
disabled, and that's the most likely cause of the problem you're seeing.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group notifier block
From: Varun Sethi @ 2014-01-22 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122122550.GA14108@mudshark.cambridge.arm.com>
> -----Original Message-----
> From: Will Deacon [mailto:will.deacon at arm.com]
> Sent: Wednesday, January 22, 2014 5:56 PM
> To: Sethi Varun-B16395
> Cc: Andreas Herrmann; iommu at lists.linux-foundation.org; linux-arm-
> kernel at lists.infradead.org; Andreas Herrmann
> Subject: Re: [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group
> notifier block
>
> Hi Varun, Andreas,
>
> On Tue, Jan 21, 2014 at 05:48:02PM +0000, Varun Sethi wrote:
> > > +static int arm_smmu_group_notifier(struct notifier_block *nb,
> > > + unsigned long action, void *data) {
> > > + struct device *dev = data;
> > > + struct dma_iommu_mapping *mapping;
> > > + struct arm_smmu_device *smmu;
> > > + int ret;
> > > +
> > > + switch (action) {
> > > + case IOMMU_GROUP_NOTIFY_BIND_DRIVER:
> > > +
> > > + smmu = dev->archdata.iommu;
> > > + if (!smmu || !(smmu->options & ARM_SMMU_OPT_ISOLATE_DEVICES))
> > > + break;
> > [Sethi Varun-B16395] Should this check be really done here? The
> > "Isolate devices" property would allow us to set up iommu groups. My
> > understanding is that if we specify the isolate devices property, then
> > each device would have a separate iommu group otherwise all devices
> > connected to the SMMU would share the iommu group.
>
> That's not what currently happens (at least, in the patch I have queued
> for groups). The code queued adds each device to its own group in
> arm_smmu_add_device, which I think is the right thing to do.
>
> > With that logic, we should link the mapping to the iommu group.
>
> Ok, so are you suggesting that we perform the isolation mapping in
> arm_smmu_add_device and drop the notifier altogether?
I think that should be fine, until we want to delay mapping creation till driver bind time. But the "isolate device" property should dictate iommu group creation.
-Varun
^ permalink raw reply
* [PATCH 2/3] ARM: kexec: copying code to ioremapped area
From: Wang Nan @ 2014-01-22 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANacCWz2DdLvns9htszpwWnASrYGXQt+tHMsw4aBbjoyw-DmeQ@mail.gmail.com>
On 2014/1/22 20:56, Vaibhav Bedia wrote:
> On Wed, Jan 22, 2014 at 6:25 AM, Wang Nan <wangnan0 at huawei.com <mailto:wangnan0@huawei.com>> wrote:
>
> ARM's kdump is actually corrupted (at least for omap4460), mainly because of
> cache problem: flush_icache_range can't reliably ensure the copied data
> correctly goes into RAM. After mmu turned off and jump to the trampoline, kexec
> always failed due to random undef instructions.
>
> This patch use ioremap to make sure the destnation of all memcpy() is
> uncachable memory, including copying of target kernel and trampoline.
>
>
> AFAIK ioremap on RAM in forbidden in ARM and device memory that ioremap()
> ends up creating is not meant for executable code.
>
> Doesn't this trigger the WARN_ON() in _arm_ioremap_pfn_caller)?
This patch is depend on the previous one:
ARM: Premit ioremap() to map reserved pages
However, Russell is opposed to it.
^ 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