* [PATCH v3 02/15] clocksource: orion: Use atomic access for shared registers
From: Ezequiel Garcia @ 2014-01-21 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390310774-20781-1-git-send-email-ezequiel.garcia@free-electrons.com>
Replace the driver-specific thread-safe shared register API
by the recently introduced atomic_io_clear_set().
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
drivers/clocksource/time-orion.c | 28 ++++++++++------------------
1 file changed, 10 insertions(+), 18 deletions(-)
diff --git a/drivers/clocksource/time-orion.c b/drivers/clocksource/time-orion.c
index 9c7f018..3f14e56 100644
--- a/drivers/clocksource/time-orion.c
+++ b/drivers/clocksource/time-orion.c
@@ -35,20 +35,6 @@
#define ORION_ONESHOT_MAX 0xfffffffe
static void __iomem *timer_base;
-static DEFINE_SPINLOCK(timer_ctrl_lock);
-
-/*
- * Thread-safe access to TIMER_CTRL register
- * (shared with watchdog timer)
- */
-void orion_timer_ctrl_clrset(u32 clr, u32 set)
-{
- spin_lock(&timer_ctrl_lock);
- writel((readl(timer_base + TIMER_CTRL) & ~clr) | set,
- timer_base + TIMER_CTRL);
- spin_unlock(&timer_ctrl_lock);
-}
-EXPORT_SYMBOL(orion_timer_ctrl_clrset);
/*
* Free-running clocksource handling.
@@ -68,7 +54,8 @@ static int orion_clkevt_next_event(unsigned long delta,
{
/* setup and enable one-shot timer */
writel(delta, timer_base + TIMER1_VAL);
- orion_timer_ctrl_clrset(TIMER1_RELOAD_EN, TIMER1_EN);
+ atomic_io_modify(timer_base + TIMER_CTRL,
+ TIMER1_RELOAD_EN | TIMER1_EN, TIMER1_EN);
return 0;
}
@@ -80,10 +67,13 @@ static void orion_clkevt_mode(enum clock_event_mode mode,
/* setup and enable periodic timer at 1/HZ intervals */
writel(ticks_per_jiffy - 1, timer_base + TIMER1_RELOAD);
writel(ticks_per_jiffy - 1, timer_base + TIMER1_VAL);
- orion_timer_ctrl_clrset(0, TIMER1_RELOAD_EN | TIMER1_EN);
+ atomic_io_modify(timer_base + TIMER_CTRL,
+ TIMER1_RELOAD_EN | TIMER1_EN,
+ TIMER1_RELOAD_EN | TIMER1_EN);
} else {
/* disable timer */
- orion_timer_ctrl_clrset(TIMER1_RELOAD_EN | TIMER1_EN, 0);
+ atomic_io_modify(timer_base + TIMER_CTRL,
+ TIMER1_RELOAD_EN | TIMER1_EN, 0);
}
}
@@ -131,7 +121,9 @@ static void __init orion_timer_init(struct device_node *np)
/* setup timer0 as free-running clocksource */
writel(~0, timer_base + TIMER0_VAL);
writel(~0, timer_base + TIMER0_RELOAD);
- orion_timer_ctrl_clrset(0, TIMER0_RELOAD_EN | TIMER0_EN);
+ atomic_io_modify(timer_base + TIMER_CTRL,
+ TIMER0_RELOAD_EN | TIMER0_EN,
+ TIMER0_RELOAD_EN | TIMER0_EN);
clocksource_mmio_init(timer_base + TIMER0_VAL, "orion_clocksource",
clk_get_rate(clk), 300, 32,
clocksource_mmio_readl_down);
--
1.8.1.5
^ permalink raw reply related
* [PATCH v3 01/15] ARM: Introduce atomic MMIO modify
From: Ezequiel Garcia @ 2014-01-21 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390310774-20781-1-git-send-email-ezequiel.garcia@free-electrons.com>
Some SoC have MMIO regions that are shared across orthogonal
subsystems. This commit implements a possible solution for the
thread-safe access of such regions through a spinlock-protected API.
Concurrent access is protected with a single spinlock for the
entire MMIO address space. While this protects shared-registers,
it also serializes access to unrelated/unshared registers.
We add relaxed and non-relaxed variants, by using writel_relaxed and writel,
respectively. The rationale for this is that some users may not require
register write completion but only thread-safe access to a register.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
Submitted to ARM patch tracker:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7930/1
arch/arm/include/asm/io.h | 6 ++++++
arch/arm/kernel/io.c | 35 +++++++++++++++++++++++++++++++++++
2 files changed, 41 insertions(+)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index fbeb39c..8aa4cca 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -38,6 +38,12 @@
#define isa_bus_to_virt phys_to_virt
/*
+ * Atomic MMIO-wide IO modify
+ */
+extern void atomic_io_modify(void __iomem *reg, u32 mask, u32 set);
+extern void atomic_io_modify_relaxed(void __iomem *reg, u32 mask, u32 set);
+
+/*
* Generic IO read/write. These perform native-endian accesses. Note
* that some architectures will want to re-define __raw_{read,write}w.
*/
diff --git a/arch/arm/kernel/io.c b/arch/arm/kernel/io.c
index dcd5b4d..9203cf8 100644
--- a/arch/arm/kernel/io.c
+++ b/arch/arm/kernel/io.c
@@ -1,6 +1,41 @@
#include <linux/export.h>
#include <linux/types.h>
#include <linux/io.h>
+#include <linux/spinlock.h>
+
+static DEFINE_RAW_SPINLOCK(__io_lock);
+
+/*
+ * Generic atomic MMIO modify.
+ *
+ * Allows thread-safe access to registers shared by unrelated subsystems.
+ * The access is protected by a single MMIO-wide lock.
+ */
+void atomic_io_modify_relaxed(void __iomem *reg, u32 mask, u32 set)
+{
+ unsigned long flags;
+ u32 value;
+
+ raw_spin_lock_irqsave(&__io_lock, flags);
+ value = readl_relaxed(reg) & ~mask;
+ value |= (set & mask);
+ writel_relaxed(value, reg);
+ raw_spin_unlock_irqrestore(&__io_lock, flags);
+}
+EXPORT_SYMBOL(atomic_io_modify_relaxed);
+
+void atomic_io_modify(void __iomem *reg, u32 mask, u32 set)
+{
+ unsigned long flags;
+ u32 value;
+
+ raw_spin_lock_irqsave(&__io_lock, flags);
+ value = readl_relaxed(reg) & ~mask;
+ value |= (set & mask);
+ writel(value, reg);
+ raw_spin_unlock_irqrestore(&__io_lock, flags);
+}
+EXPORT_SYMBOL(atomic_io_modify);
/*
* Copy data from IO memory space to "real" memory space.
--
1.8.1.5
^ permalink raw reply related
* [PATCH v3 00/15] Armada 370/XP watchdog support
From: Ezequiel Garcia @ 2014-01-21 13:25 UTC (permalink / raw)
To: linux-arm-kernel
Third patchset to extend Orion watchdog driver adding support for
Armada 370/XP SoC. This consists on a small incremental series.
Please take a look at the previous version and the discussion raised:
http://www.spinics.net/lists/arm-kernel/msg302104.html
Changes from v2:
* Add proper error checking on clk_prepare_enable() and return
PTR_ERR instead of ENODEV. Suggested by Fabio Estevam.
* After the usage of the atomic I/O and considering the watchdog core
does its own serialization, the driver's spinlock was completely
redundant and was removed. Also suggested by Fabio.
* Instead of making the driver dependent on PLAT_ORION, added a dependency
to ARCH_MVEBU. This was proposed by Sebastian and Andrew, given
we're working on PLAT_ORION removal.
This series is based on v3.13-rc8 and has been tested on:
* Marvell's Armada XP GP board
Ezequiel Garcia (15):
ARM: Introduce atomic MMIO modify
clocksource: orion: Use atomic access for shared registers
watchdog: orion: Use atomic access for shared registers
watchdog: orion: Handle IRQ
watchdog: orion: Make RSTOUT register a separate resource
watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
watchdog: orion: Introduce an orion_watchdog device structure
watchdog: orion: Introduce per-compatible of_device_id data
watchdog: orion: Add per-compatible clock initialization
watchdog: orion: Add per-compatible watchdog start implementation
watchdog: orion: Add support for Armada 370 and Armada XP SoC
ARM: mvebu: Enable Armada 370/XP watchdog in the devicetree
ARM: kirkwood: Add RSTOUT 'reg' entry to devicetree
watchdog: orion: Enable the build on ARCH_MVEBU
ARM: mvebu: Enable watchdog support in defconfig
.../devicetree/bindings/watchdog/marvel.txt | 8 +-
arch/arm/boot/dts/armada-370-xp.dtsi | 4 +
arch/arm/boot/dts/armada-370.dtsi | 5 +
arch/arm/boot/dts/armada-xp.dtsi | 6 +
arch/arm/boot/dts/kirkwood.dtsi | 2 +-
arch/arm/configs/mvebu_defconfig | 2 +
arch/arm/include/asm/io.h | 6 +
arch/arm/kernel/io.c | 35 +++
arch/arm/mach-dove/include/mach/bridge-regs.h | 1 +
arch/arm/mach-kirkwood/include/mach/bridge-regs.h | 1 +
arch/arm/mach-mv78xx0/include/mach/bridge-regs.h | 1 +
arch/arm/mach-orion5x/include/mach/bridge-regs.h | 1 +
arch/arm/plat-orion/common.c | 10 +-
drivers/clocksource/time-orion.c | 28 +-
drivers/watchdog/Kconfig | 2 +-
drivers/watchdog/orion_wdt.c | 320 ++++++++++++++++-----
16 files changed, 329 insertions(+), 103 deletions(-)
--
1.8.1.5
^ permalink raw reply
* [RFC PATCH 3/3] KVM: Documentation: Add info regarding KVM_ARM_VCPU_PSCI_0_2 feature
From: Anup Patel @ 2014-01-21 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390309301-28424-1-git-send-email-anup.patel@linaro.org>
We have in-kernel emulation of PSCI v0.2 in KVM ARM/ARM64. To provide
PSCI v0.2 interface to VCPUs, we have to enable KVM_ARM_VCPU_PSCI_0_2
feature when doing KVM_ARM_VCPU_INIT ioctl.
The patch updates documentation of KVM_ARM_VCPU_INIT ioctl to provide
info regarding KVM_ARM_VCPU_PSCI_0_2 feature.
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
---
Documentation/virtual/kvm/api.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index aad3244..a15fcdd 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2346,6 +2346,8 @@ Possible features:
Depends on KVM_CAP_ARM_PSCI.
- KVM_ARM_VCPU_EL1_32BIT: Starts the CPU in a 32bit mode.
Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only).
+ - KVM_ARM_VCPU_PSCI_0_2: Emulate PSCI v0.2 for CPU.
+ Depends on KVM_CAP_ARM_PSCI_0_2.
4.83 KVM_ARM_PREFERRED_TARGET
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 2/3] ARM/ARM64: KVM: Add support for PSCI v0.2 emulation
From: Anup Patel @ 2014-01-21 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390309301-28424-1-git-send-email-anup.patel@linaro.org>
Currently, the in-kernel PSCI emulation provides PSCI v0.1 interface to
VCPUs. This patch extends current in-kernel PSCI emulation to provide
PSCI v0.2 interface to VCPUs.
By default, ARM/ARM64 KVM will always provide PSCI v0.1 interface for
keeping the ABI backward-compatible.
To select PSCI v0.2 interface for VCPUs, the user space (i.e. QEMU or
KVMTOOL) will have to set KVM_ARM_VCPU_PSCI_0_2 feature when doing VCPU
init using KVM_ARM_VCPU_INIT ioctl.
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
---
arch/arm/include/asm/kvm_host.h | 2 +-
arch/arm/include/uapi/asm/kvm.h | 39 ++++++++++++++++--
arch/arm/kvm/arm.c | 6 ++-
arch/arm/kvm/psci.c | 79 ++++++++++++++++++++++++++++++-------
arch/arm64/include/asm/kvm_host.h | 2 +-
arch/arm64/include/uapi/asm/kvm.h | 39 ++++++++++++++++--
6 files changed, 143 insertions(+), 24 deletions(-)
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 8a6f6db..0239ac5 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -36,7 +36,7 @@
#define KVM_COALESCED_MMIO_PAGE_OFFSET 1
#define KVM_HAVE_ONE_REG
-#define KVM_VCPU_MAX_FEATURES 1
+#define KVM_VCPU_MAX_FEATURES 2
#include <kvm/arm_vgic.h>
diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
index c498b60..d9eb74c 100644
--- a/arch/arm/include/uapi/asm/kvm.h
+++ b/arch/arm/include/uapi/asm/kvm.h
@@ -83,6 +83,7 @@ struct kvm_regs {
#define KVM_VGIC_V2_CPU_SIZE 0x2000
#define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */
+#define KVM_ARM_VCPU_PSCI_0_2 1 /* CPU uses PSCI v0.2 */
struct kvm_vcpu_init {
__u32 target;
@@ -164,7 +165,7 @@ struct kvm_arch_memory_slot {
/* Highest supported SPI, from VGIC_NR_IRQS */
#define KVM_ARM_IRQ_GIC_MAX 127
-/* PSCI interface */
+/* PSCI v0.1 interface */
#define KVM_PSCI_FN_BASE 0x95c1ba5e
#define KVM_PSCI_FN(n) (KVM_PSCI_FN_BASE + (n))
@@ -173,9 +174,41 @@ struct kvm_arch_memory_slot {
#define KVM_PSCI_FN_CPU_ON KVM_PSCI_FN(2)
#define KVM_PSCI_FN_MIGRATE KVM_PSCI_FN(3)
+/* PSCI v0.2 interface */
+#define KVM_PSCI_0_2_FN_BASE 0x84000000
+#define KVM_PSCI_0_2_FN(n) (KVM_PSCI_0_2_FN_BASE + (n))
+#define KVM_PSCI_0_2_FN64_BASE 0xC4000000
+#define KVM_PSCI_0_2_FN64(n) (KVM_PSCI_0_2_FN64_BASE + (n))
+
+#define KVM_PSCI_0_2_FN_PSCI_VERSION KVM_PSCI_0_2_FN(0)
+#define KVM_PSCI_0_2_FN_CPU_SUSPEND KVM_PSCI_0_2_FN(1)
+#define KVM_PSCI_0_2_FN_CPU_OFF KVM_PSCI_0_2_FN(2)
+#define KVM_PSCI_0_2_FN_CPU_ON KVM_PSCI_0_2_FN(3)
+#define KVM_PSCI_0_2_FN_AFFINITY_INFO KVM_PSCI_0_2_FN(4)
+#define KVM_PSCI_0_2_FN_MIGRATE KVM_PSCI_0_2_FN(5)
+#define KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE \
+ KVM_PSCI_0_2_FN(6)
+#define KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU \
+ KVM_PSCI_0_2_FN(7)
+#define KVM_PSCI_0_2_FN_SYSTEM_OFF KVM_PSCI_0_2_FN(8)
+#define KVM_PSCI_0_2_FN_SYSTEM_RESET KVM_PSCI_0_2_FN(9)
+
+#define KVM_PSCI_0_2_FN64_CPU_SUSPEND KVM_PSCI_0_2_FN64(1)
+#define KVM_PSCI_0_2_FN64_CPU_ON KVM_PSCI_0_2_FN64(3)
+#define KVM_PSCI_0_2_FN64_AFFINITY_INFO KVM_PSCI_0_2_FN64(4)
+#define KVM_PSCI_0_2_FN64_MIGRATE KVM_PSCI_0_2_FN64(5)
+#define KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU \
+ KVM_PSCI_0_2_FN64(7)
+
+/* PSCI return values */
#define KVM_PSCI_RET_SUCCESS 0
-#define KVM_PSCI_RET_NI ((unsigned long)-1)
-#define KVM_PSCI_RET_INVAL ((unsigned long)-2)
+#define KVM_PSCI_RET_NOT_SUPPORTED ((unsigned long)-1)
+#define KVM_PSCI_RET_INVALID_PARAMS ((unsigned long)-2)
#define KVM_PSCI_RET_DENIED ((unsigned long)-3)
+#define KVM_PSCI_RET_ALREADY_ON ((unsigned long)-4)
+#define KVM_PSCI_RET_ON_PENDING ((unsigned long)-5)
+#define KVM_PSCI_RET_INTERNAL_FAILURE ((unsigned long)-6)
+#define KVM_PSCI_RET_NOT_PRESENT ((unsigned long)-7)
+#define KVM_PSCI_RET_DISABLED ((unsigned long)-8)
#endif /* __ARM_KVM_H__ */
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 2a700e0..0b7817a 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -193,6 +193,7 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_DESTROY_MEMORY_REGION_WORKS:
case KVM_CAP_ONE_REG:
case KVM_CAP_ARM_PSCI:
+ case KVM_CAP_ARM_PSCI_0_2:
r = 1;
break;
case KVM_CAP_COALESCED_MMIO:
@@ -483,7 +484,10 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
* PSCI code.
*/
if (test_and_clear_bit(KVM_ARM_VCPU_POWER_OFF, vcpu->arch.features)) {
- *vcpu_reg(vcpu, 0) = KVM_PSCI_FN_CPU_OFF;
+ if (test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features))
+ *vcpu_reg(vcpu, 0) = KVM_PSCI_0_2_FN_CPU_OFF;
+ else
+ *vcpu_reg(vcpu, 0) = KVM_PSCI_FN_CPU_OFF;
kvm_psci_call(vcpu);
}
diff --git a/arch/arm/kvm/psci.c b/arch/arm/kvm/psci.c
index 0881bf1..ee044a3 100644
--- a/arch/arm/kvm/psci.c
+++ b/arch/arm/kvm/psci.c
@@ -55,13 +55,13 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
}
if (!vcpu)
- return KVM_PSCI_RET_INVAL;
+ return KVM_PSCI_RET_INVALID_PARAMS;
target_pc = *vcpu_reg(source_vcpu, 2);
wq = kvm_arch_vcpu_wq(vcpu);
if (!waitqueue_active(wq))
- return KVM_PSCI_RET_INVAL;
+ return KVM_PSCI_RET_INVALID_PARAMS;
kvm_reset_vcpu(vcpu);
@@ -84,17 +84,49 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
return KVM_PSCI_RET_SUCCESS;
}
-/**
- * kvm_psci_call - handle PSCI call if r0 value is in range
- * @vcpu: Pointer to the VCPU struct
- *
- * Handle PSCI calls from guests through traps from HVC instructions.
- * The calling convention is similar to SMC calls to the secure world where
- * the function number is placed in r0 and this function returns true if the
- * function number specified in r0 is withing the PSCI range, and false
- * otherwise.
- */
-bool kvm_psci_call(struct kvm_vcpu *vcpu)
+static bool kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
+{
+ unsigned long psci_fn = *vcpu_reg(vcpu, 0) & ~((u32) 0);
+ unsigned long val;
+
+ switch (psci_fn) {
+ case KVM_PSCI_0_2_FN_PSCI_VERSION:
+ /*
+ * Bits[31:16] = Major Version = 0
+ * Bits[15:0] = Minor Version = 2
+ */
+ val = 2;
+ break;
+ case KVM_PSCI_0_2_FN_CPU_OFF:
+ kvm_psci_vcpu_off(vcpu);
+ val = KVM_PSCI_RET_SUCCESS;
+ break;
+ case KVM_PSCI_0_2_FN_CPU_ON:
+ case KVM_PSCI_0_2_FN64_CPU_ON:
+ val = kvm_psci_vcpu_on(vcpu);
+ break;
+ case KVM_PSCI_0_2_FN_CPU_SUSPEND:
+ case KVM_PSCI_0_2_FN_AFFINITY_INFO:
+ case KVM_PSCI_0_2_FN_MIGRATE:
+ case KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE:
+ case KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU:
+ case KVM_PSCI_0_2_FN_SYSTEM_OFF:
+ case KVM_PSCI_0_2_FN_SYSTEM_RESET:
+ case KVM_PSCI_0_2_FN64_CPU_SUSPEND:
+ case KVM_PSCI_0_2_FN64_AFFINITY_INFO:
+ case KVM_PSCI_0_2_FN64_MIGRATE:
+ case KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
+ val = KVM_PSCI_RET_NOT_SUPPORTED;
+ break;
+ default:
+ return false;
+ }
+
+ *vcpu_reg(vcpu, 0) = val;
+ return true;
+}
+
+static bool kvm_psci_0_1_call(struct kvm_vcpu *vcpu)
{
unsigned long psci_fn = *vcpu_reg(vcpu, 0) & ~((u32) 0);
unsigned long val;
@@ -109,9 +141,8 @@ bool kvm_psci_call(struct kvm_vcpu *vcpu)
break;
case KVM_PSCI_FN_CPU_SUSPEND:
case KVM_PSCI_FN_MIGRATE:
- val = KVM_PSCI_RET_NI;
+ val = KVM_PSCI_RET_NOT_SUPPORTED;
break;
-
default:
return false;
}
@@ -119,3 +150,21 @@ bool kvm_psci_call(struct kvm_vcpu *vcpu)
*vcpu_reg(vcpu, 0) = val;
return true;
}
+
+/**
+ * kvm_psci_call - handle PSCI call if r0 value is in range
+ * @vcpu: Pointer to the VCPU struct
+ *
+ * Handle PSCI calls from guests through traps from HVC instructions.
+ * The calling convention is similar to SMC calls to the secure world where
+ * the function number is placed in r0 and this function returns true if the
+ * function number specified in r0 is withing the PSCI range, and false
+ * otherwise.
+ */
+bool kvm_psci_call(struct kvm_vcpu *vcpu)
+{
+ if (test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features))
+ return kvm_psci_0_2_call(vcpu);
+
+ return kvm_psci_0_1_call(vcpu);
+}
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 0a1d697..92242ce 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -39,7 +39,7 @@
#include <kvm/arm_vgic.h>
#include <kvm/arm_arch_timer.h>
-#define KVM_VCPU_MAX_FEATURES 2
+#define KVM_VCPU_MAX_FEATURES 3
struct kvm_vcpu;
int kvm_target_cpu(void);
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index d9f026b..0eb254d 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -77,6 +77,7 @@ struct kvm_regs {
#define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */
#define KVM_ARM_VCPU_EL1_32BIT 1 /* CPU running a 32bit VM */
+#define KVM_ARM_VCPU_PSCI_0_2 2 /* CPU uses PSCI v0.2 */
struct kvm_vcpu_init {
__u32 target;
@@ -150,7 +151,7 @@ struct kvm_arch_memory_slot {
/* Highest supported SPI, from VGIC_NR_IRQS */
#define KVM_ARM_IRQ_GIC_MAX 127
-/* PSCI interface */
+/* PSCI v0.1 interface */
#define KVM_PSCI_FN_BASE 0x95c1ba5e
#define KVM_PSCI_FN(n) (KVM_PSCI_FN_BASE + (n))
@@ -159,10 +160,42 @@ struct kvm_arch_memory_slot {
#define KVM_PSCI_FN_CPU_ON KVM_PSCI_FN(2)
#define KVM_PSCI_FN_MIGRATE KVM_PSCI_FN(3)
+/* PSCI v0.2 interface */
+#define KVM_PSCI_0_2_FN_BASE 0x84000000
+#define KVM_PSCI_0_2_FN(n) (KVM_PSCI_0_2_FN_BASE + (n))
+#define KVM_PSCI_0_2_FN64_BASE 0xC4000000
+#define KVM_PSCI_0_2_FN64(n) (KVM_PSCI_0_2_FN64_BASE + (n))
+
+#define KVM_PSCI_0_2_FN_PSCI_VERSION KVM_PSCI_0_2_FN(0)
+#define KVM_PSCI_0_2_FN_CPU_SUSPEND KVM_PSCI_0_2_FN(1)
+#define KVM_PSCI_0_2_FN_CPU_OFF KVM_PSCI_0_2_FN(2)
+#define KVM_PSCI_0_2_FN_CPU_ON KVM_PSCI_0_2_FN(3)
+#define KVM_PSCI_0_2_FN_AFFINITY_INFO KVM_PSCI_0_2_FN(4)
+#define KVM_PSCI_0_2_FN_MIGRATE KVM_PSCI_0_2_FN(5)
+#define KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE \
+ KVM_PSCI_0_2_FN(6)
+#define KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU \
+ KVM_PSCI_0_2_FN(7)
+#define KVM_PSCI_0_2_FN_SYSTEM_OFF KVM_PSCI_0_2_FN(8)
+#define KVM_PSCI_0_2_FN_SYSTEM_RESET KVM_PSCI_0_2_FN(9)
+
+#define KVM_PSCI_0_2_FN64_CPU_SUSPEND KVM_PSCI_0_2_FN64(1)
+#define KVM_PSCI_0_2_FN64_CPU_ON KVM_PSCI_0_2_FN64(3)
+#define KVM_PSCI_0_2_FN64_AFFINITY_INFO KVM_PSCI_0_2_FN64(4)
+#define KVM_PSCI_0_2_FN64_MIGRATE KVM_PSCI_0_2_FN64(5)
+#define KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU \
+ KVM_PSCI_0_2_FN64(7)
+
+/* PSCI return values */
#define KVM_PSCI_RET_SUCCESS 0
-#define KVM_PSCI_RET_NI ((unsigned long)-1)
-#define KVM_PSCI_RET_INVAL ((unsigned long)-2)
+#define KVM_PSCI_RET_NOT_SUPPORTED ((unsigned long)-1)
+#define KVM_PSCI_RET_INVALID_PARAMS ((unsigned long)-2)
#define KVM_PSCI_RET_DENIED ((unsigned long)-3)
+#define KVM_PSCI_RET_ALREADY_ON ((unsigned long)-4)
+#define KVM_PSCI_RET_ON_PENDING ((unsigned long)-5)
+#define KVM_PSCI_RET_INTERNAL_FAILURE ((unsigned long)-6)
+#define KVM_PSCI_RET_NOT_PRESENT ((unsigned long)-7)
+#define KVM_PSCI_RET_DISABLED ((unsigned long)-8)
#endif
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 1/3] KVM: Add capability to advertise PSCI v0.2 support
From: Anup Patel @ 2014-01-21 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390309301-28424-1-git-send-email-anup.patel@linaro.org>
User space (i.e. QEMU or KVMTOOL) should be able to check whether KVM
ARM/ARM64 supports in-kernel PSCI v0.2 emulation. For this purpose, we
define KVM_CAP_ARM_PSCI_0_2 in KVM user space interface header.
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
---
include/uapi/linux/kvm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 902f124..d64349e 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -674,6 +674,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_ARM_EL1_32BIT 93
#define KVM_CAP_SPAPR_MULTITCE 94
#define KVM_CAP_EXT_EMUL_CPUID 95
+#define KVM_CAP_ARM_PSCI_0_2 96
#ifdef KVM_CAP_IRQ_ROUTING
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 0/3] In-kernel PSCI v0.2 emulation for KVM ARM/ARM64
From: Anup Patel @ 2014-01-21 13:01 UTC (permalink / raw)
To: linux-arm-kernel
Currently, KVM ARM/ARM64 only provides in-kernel emulation of Power State
and Coordination Interface (PSCI) v0.1.
This patchset aims at providing newer PSCI v0.2 for KVM ARM/ARM64 VCPUs
such that it does not break current KVM ARM/ARM64 ABI. Also, the patchset
provides emulation of only few PSCI v0.2 functions such as PSCI_VERSION,
CPU_ON, and CPU_OFF. Emulation of other PSCI v0.2 functions will be added
later.
The user space tools (i.e. QEMU or KVMTOOL) will have to explicitly enable
KVM_ARM_VCPU_PSCI_0_2 feature using KVM_ARM_VCPU_INIT ioctl for providing
PSCI v0.2 to VCPUs.
Anup Patel (3):
KVM: Add capability to advertise PSCI v0.2 support
ARM/ARM64: KVM: Add support for PSCI v0.2 emulation
KVM: Documentation: Add info regarding KVM_ARM_VCPU_PSCI_0_2 feature
Documentation/virtual/kvm/api.txt | 2 +
arch/arm/include/asm/kvm_host.h | 2 +-
arch/arm/include/uapi/asm/kvm.h | 39 ++++++++++++++++--
arch/arm/kvm/arm.c | 6 ++-
arch/arm/kvm/psci.c | 79 ++++++++++++++++++++++++++++++-------
arch/arm64/include/asm/kvm_host.h | 2 +-
arch/arm64/include/uapi/asm/kvm.h | 39 ++++++++++++++++--
include/uapi/linux/kvm.h | 1 +
8 files changed, 146 insertions(+), 24 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH 0/2] clk: shmobile rcar-gen2 fixes
From: Laurent Pinchart @ 2014-01-21 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1591253.8BzYfubhGS@avalon>
Hi Mike,
On Wednesday 08 January 2014 00:06:39 Laurent Pinchart wrote:
> On Tuesday 07 January 2014 17:59:01 Geert Uytterhoeven wrote:
> > On Tue, Jan 7, 2014 at 5:47 PM, Laurent Pinchart wrote:
> > > Geert, could you please verify that the series fixes your QSPI clock
> > > issues with the Koelsch board ?
> > >
> > > Laurent Pinchart (2):
> > > clk: shmobile: rcar-gen2: Fix clock parent all non-PLL clocks
> > > clk: shmobile: rcar-gen2: Fix qspi divisor
> >
> > Thanks, both:
> >
> > Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
>
> Thank you.
>
> Mike, could you please pick those patches up for v3.14 ?
Ping ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 15/15] ARM: mvebu: Enable watchdog support in defconfig
From: Jason Cooper @ 2014-01-21 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121125339.GH13396@lunn.ch>
On Tue, Jan 21, 2014 at 01:53:39PM +0100, Andrew Lunn wrote:
> On Tue, Jan 21, 2014 at 07:47:46AM -0500, Jason Cooper wrote:
> > On Tue, Jan 21, 2014 at 06:12:41AM -0300, Ezequiel Garcia wrote:
> > > Now that we have proper support for Armada 370/XP watchdog
> > > let's enable it in the defconfig.
> > >
> > > Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> > > ---
> > > arch/arm/configs/mvebu_defconfig | 2 ++
> > > 1 file changed, 2 insertions(+)
> >
> > Just a note to myself more than anything: I need to square up multi_v7
> > with mvebu. As we make these changes next cycle, we need to be able to
> > easily test that we aren't breaking multiplat build or boot.
>
> Hi Jason
>
> Hopefully you can also tackle multi_v5 as well, once DT kirkwood moves
> into mach-mvebu.
Yes.
> To check for breaking boot, you need some other hardware
> platform. Nomadik was breaking kirkwood multi_v5, and you would not
> see the problem on Nomadik.
Yes, I was more specifically looking to leverage arm-buildbot...
thx,
Jason.
^ permalink raw reply
* [PATCH v2 15/15] ARM: mvebu: Enable watchdog support in defconfig
From: Andrew Lunn @ 2014-01-21 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121124746.GZ29184@titan.lakedaemon.net>
On Tue, Jan 21, 2014 at 07:47:46AM -0500, Jason Cooper wrote:
> On Tue, Jan 21, 2014 at 06:12:41AM -0300, Ezequiel Garcia wrote:
> > Now that we have proper support for Armada 370/XP watchdog
> > let's enable it in the defconfig.
> >
> > Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> > ---
> > arch/arm/configs/mvebu_defconfig | 2 ++
> > 1 file changed, 2 insertions(+)
>
> Just a note to myself more than anything: I need to square up multi_v7
> with mvebu. As we make these changes next cycle, we need to be able to
> easily test that we aren't breaking multiplat build or boot.
Hi Jason
Hopefully you can also tackle multi_v5 as well, once DT kirkwood moves
into mach-mvebu.
To check for breaking boot, you need some other hardware
platform. Nomadik was breaking kirkwood multi_v5, and you would not
see the problem on Nomadik.
Andrew
^ permalink raw reply
* [RFC] dt-bindings: configuration of parent clocks and clock frequency
From: Sylwester Nawrocki @ 2014-01-21 12:48 UTC (permalink / raw)
To: linux-arm-kernel
Hi All,
During LCE13 there was a discussion regarding initial configuration
of clocks from consumer perspective and the related device tree bindings.
It seems no one started working on this, at least I couldn't see any
related posts/patches on the mailing list, so I thought I'd give a try
the initial binding proposal [1].
As it turns out, by adding only a single property with a list of parent
clock specifiers or clock frequencies corresponding to clocks listed in
the 'clocks' property it is difficult to specify parent clocks or
frequencies only for selected clocks of a device.
So I modified the proposed binding and there are some variants below
it would be nice to get a feedback for.
Let's assume a clock provider and an UART device:
clk {
#clock-cells = <1>;
};
uart: uart {
clocks = <&clk 10>, <&clk 11>, <&clk 12>;
clock-names = "sclk_0", "sclk_1", "gate";
...
};
1. The first version I actually tried in practice is
'assigned-clk-parents' and assigned-clk-rates properties listing
<clk clk_parent> and <clk clk_rate> pairs respectively:
uart {
clocks = <&clk 10>, <&clk 11>, <&clk 12>;
clock-names = "sclk_0", "sclk_1", "gate";
assigned-clk-parents = <&clk_a 10 &clk_a 20>,
<&clk_a 11 &clk_a 100>;
assigned-clk-rates = <&clk_a 10 600000>,
<&clk_a 100 100000>;
};
Parsing assigned-clk-parents is straightforward, only assigned-clk-rates
requires a bit more exercise.
2. A different option would be to list all the required clocks in clock/
clock-names properties and use properties as below to refer to the
clocks by name:
uart {
clocks = <&clk 10>, <&clk 11>, <&clk 12>, &clk 100> /* PLL */;
clock-names = "sclk_0", "sclk_1", "gate", "pll";
assigned-clk-parent-clocks = "sclk_0";
assigned-clk-parent-parents = "pll";
assigned-clk-rate-clocks = "pll";
assigned-clk-rate-values = <600000>;
};
It might be more readable and would allow configuring things more
consciously. However it adds an additional indirection and introduces
specifiers of clocks potentially unrelated to a device in clocks/
clock-names properties.
3. A simplified variant of 2., with indexes to 'clocks' property rather
than values from the clock-names property:
uart: uart {
clocks = <&clk 10>, <&clk 11>, <&clk 12>, &clk 100> /* PLL */;
clock-names = "sclk_0", "sclk_1", "gate", "pll";
assigned-clk-parent-clocks = 0;
assigned-clk-parent-parents = 3;
assigned-clk-rate-clocks = 3;
assigned-clk-rate-values = <600000>;
};
4. With phandle + clock specifier instead of device clock names:
uart: uart {
clocks = <&clk 10>, <&clk 11>, <&clk 12>, &clk 100> /* PLL */;
clock-names = "sclk_0", "sclk_1", "gate", "pll";
assigned-clk-parent-clocks = <&clk 10>;
assigned-clk-parent-parents = <&clk 100>;
assigned-clk-rate-clocks = <&clk 100>;
assigned-clk-rate-values = <600000>;
};
5. Similarly to the regulator bindings the clock names could be appended
to name of a DT property:
[clk_name]-assigned-clock-parent = <...>;
[clk_name]-assigned-clock-rate = <...>;
It has an issue though that length of a DT property name is limited
to 31 characters and there may not be enough room for the clock name.
uart: uart {
clocks = <&clk 10>, <&clk 11>, <&clk 12>;
clock-names = "sclk_0", "sclk_1", "gate";
sclk_0-assigned-clk-parent = <&clk 100>;
pll-assigned-clk-rate = <600000>;
};
Does any of these look reasonable ? Perhaps someone could suggest
a better approach ?
[1] https://lkml.org/lkml/2013/8/22/2
--
Regards,
Sylwester
^ permalink raw reply
* [PATCH v2 15/15] ARM: mvebu: Enable watchdog support in defconfig
From: Jason Cooper @ 2014-01-21 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390295561-3466-16-git-send-email-ezequiel.garcia@free-electrons.com>
On Tue, Jan 21, 2014 at 06:12:41AM -0300, Ezequiel Garcia wrote:
> Now that we have proper support for Armada 370/XP watchdog
> let's enable it in the defconfig.
>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> ---
> arch/arm/configs/mvebu_defconfig | 2 ++
> 1 file changed, 2 insertions(+)
Just a note to myself more than anything: I need to square up multi_v7
with mvebu. As we make these changes next cycle, we need to be able to
easily test that we aren't breaking multiplat build or boot.
Hopefully I can get some defconfig changes in for -rc1? :)
thx,
Jason.
> diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
> index 594d706..84ec924 100644
> --- a/arch/arm/configs/mvebu_defconfig
> +++ b/arch/arm/configs/mvebu_defconfig
> @@ -60,6 +60,8 @@ CONFIG_GPIOLIB=y
> CONFIG_GPIO_SYSFS=y
> CONFIG_THERMAL=y
> CONFIG_ARMADA_THERMAL=y
> +CONFIG_WATCHDOG=y
> +CONFIG_ORION_WATCHDOG=y
> CONFIG_USB_SUPPORT=y
> CONFIG_USB=y
> CONFIG_USB_EHCI_HCD=y
> --
> 1.8.1.5
>
^ permalink raw reply
* [RFC PATCH 1/1] of/irq: create interrupts-extended-2 property
From: Jean-Christophe PLAGNIOL-VILLARD @ 2014-01-21 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121120214.GK28747@e106331-lin.cambridge.arm.com>
On 12:02 Tue 21 Jan , Mark Rutland wrote:
> On Tue, Jan 21, 2014 at 01:03:23AM +0000, Olof Johansson wrote:
> > On Mon, Jan 20, 2014 at 2:47 PM, Grant Likely <grant.likely@linaro.org> wrote:
> > > On Wed, 15 Jan 2014 16:12:24 +0000, Mark Rutland <mark.rutland@arm.com> wrote:
> > >> >
> > >> > Another, more invasive option would be extend the dts syntax and teach
> > >> > dtc to handle property appending. Then the soc dts could stay as it is,
> > >> > and the board dts could have something like:
> > >> >
> > >> > /append-property/ interrupts = <&intc1 6 1>;
> > >> > /append-property/ interrupt-names = "board-specific-irq";
> > >> >
> > >> > Both these options solve the issue at the source, are general to other
> > >> > properties, and allow more than one level of hierarchy (the proposed
> > >> > interrupts-extended-2 only allows one level).
> > >>
> > >> I've just had a go at implementing the append-property mechanism above
> > >> in dtc, and it was far easier than I expected (patch below).
> > >>
> > >> Does anyone have any issues with the /append-property/ idea?
> > >
> > > I think that is reasonable.
> >
> >
> > The main problem with this (same for clocks) is if you need to append
> > something with a name when the original didn't have any.
>
> Can you not just add a name in the original file? I assume we're not
> going to use this to adjust dts files we're not already in full control
> of.
>
> >
> > Reordering entries might not work for interrupts, since the bindings
> > might have requirements on order.
>
> That's a fair point.
>
> Do we currently have any optional/board-specific interrupts which must
> appear at the start or middle of the list?
>
> For those, could we add names? The kernel should be abel to fall back to
> ordering if names aren't present, and we can recommend a particular
> ordering for compatiblity with older kernels.
>
> As a general preventative measure it would be nice to have named
> elements whenever elements can be optional.
I never was a fanof index search I do agree the names irq is the best way
>
> >
> > I'm not aware of a good solution for this. Suggestions welcome.
>
> Me neither. Prepending and appending is easy.
>
> Inserting and/or modifying the list requires knowledge of the size of
> each element (and for variable-sized entries requires knowledge of the
> particular binding, which we cannot embed in dtc).
>
> I suspect adding richer syntax for modifying properties in arbitrary
> ways will devolve into a turing tarpit.
no this need to stay simple if too much complexe => mess up, unmaintainable
if you really have complex stuff duplicate the info
Best Regards,
J.
>
> Thanks,
> Mark.
^ permalink raw reply
* [PATCH v10] clk: add MOXA ART SoCs clock driver
From: Jonas Jensen @ 2014-01-21 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389971035-17781-1-git-send-email-jonas.jensen@gmail.com>
MOXA ART SoCs allow to determine PLL output and APB frequencies
by reading registers holding multiplier and divisor information.
Add a clock driver for this SoC.
Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
---
Notes:
Thanks for the reply Sudeep, changes are in v10.
Changes since v9:
1. rebase drivers/clk/Makefile to next-20140121
2. remove unnecessary switch
3. use a more elaborate commit message
Applies to next-20140121
.../bindings/clock/moxa,moxart-clock.txt | 48 +++++++++++
drivers/clk/Makefile | 1 +
drivers/clk/clk-moxart.c | 99 ++++++++++++++++++++++
3 files changed, 148 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt
create mode 100644 drivers/clk/clk-moxart.c
diff --git a/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt b/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt
new file mode 100644
index 0000000..242e3fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt
@@ -0,0 +1,48 @@
+Device Tree Clock bindings for arch-moxart
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+MOXA ART SoCs allow to determine PLL output and APB frequencies
+by reading registers holding multiplier and divisor information.
+
+
+PLL:
+
+Required properties:
+- compatible : Must be "moxa,moxart-pll-clock"
+- #clock-cells : Should be 0
+- reg : Should contain registers location and length
+- clocks : Should contain phandle to parent clock
+
+Optional properties:
+- clock-output-names : Should contain clock name
+
+
+APB:
+
+Required properties:
+- compatible : Must be "moxa,moxart-apb-clock"
+- #clock-cells : Should be 0
+- reg : Should contain registers location and length
+- clocks : Should contain phandle to parent clock
+
+Optional properties:
+- clock-output-names : Should contain clock name
+
+
+For example:
+
+ clk_pll: clk_pll at 98100000 {
+ compatible = "moxa,moxart-pll-clock";
+ #clock-cells = <0>;
+ reg = <0x98100000 0x34>;
+ };
+
+ clk_apb: clk_apb at 98100000 {
+ compatible = "moxa,moxart-apb-clock";
+ #clock-cells = <0>;
+ reg = <0x98100000 0x34>;
+ clocks = <&clk_pll>;
+ };
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 58b2d72..24361bf 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_COMMON_CLK) += clk-composite.o
# SoCs specific
obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
obj-$(CONFIG_ARCH_EFM32) += clk-efm32gg.o
+obj-$(CONFIG_ARCH_MOXART) += clk-moxart.o
obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
obj-$(CONFIG_ARCH_HIGHBANK) += clk-highbank.o
obj-$(CONFIG_ARCH_HI3xxx) += hisilicon/
diff --git a/drivers/clk/clk-moxart.c b/drivers/clk/clk-moxart.c
new file mode 100644
index 0000000..7021748
--- /dev/null
+++ b/drivers/clk/clk-moxart.c
@@ -0,0 +1,99 @@
+/*
+ * MOXA ART SoCs clock driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen@gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/clkdev.h>
+
+void __init moxart_of_pll_clk_init(struct device_node *node)
+{
+ static void __iomem *base;
+ struct clk *clk, *ref_clk;
+ unsigned long rate;
+ unsigned int mul;
+ const char *name = node->name;
+
+ of_property_read_string(node, "clock-output-names", &name);
+
+ base = of_iomap(node, 0);
+ if (!base) {
+ pr_err("%s: of_iomap failed\n", node->full_name);
+ return;
+ }
+
+ mul = readl(base + 0x30) >> 3 & 0x3f;
+ iounmap(base);
+
+ ref_clk = of_clk_get(node, 0);
+ if (IS_ERR(ref_clk)) {
+ pr_err("%s: of_clk_get failed\n", node->full_name);
+ return;
+ }
+
+ rate = mul * clk_get_rate(ref_clk);
+
+ clk = clk_register_fixed_rate(NULL, name, NULL, CLK_IS_ROOT, rate);
+ if (IS_ERR(clk)) {
+ pr_err("%s: clk_register_fixed_rate failed\n", node->full_name);
+ return;
+ }
+
+ clk_register_clkdev(clk, NULL, name);
+ of_clk_add_provider(node, of_clk_src_simple_get, clk);
+}
+CLK_OF_DECLARE(moxart_pll_clock, "moxa,moxart-pll-clock",
+ moxart_of_pll_clk_init);
+
+void __init moxart_of_apb_clk_init(struct device_node *node)
+{
+ static void __iomem *base;
+ struct clk *clk, *pll_clk;
+ unsigned long rate;
+ unsigned int div, val;
+ unsigned int div_idx[] = { 2, 3, 4, 6, 8};
+ const char *name = node->name;
+
+ of_property_read_string(node, "clock-output-names", &name);
+
+ base = of_iomap(node, 0);
+ if (!base) {
+ pr_err("%s: of_iomap failed\n", node->full_name);
+ return;
+ }
+
+ val = readl(base + 0xc) >> 4 & 0x7;
+ iounmap(base);
+
+ if (val > 4)
+ val = 0;
+ div = div_idx[val];
+
+ pll_clk = of_clk_get(node, 0);
+ if (IS_ERR(pll_clk)) {
+ pr_err("%s: of_clk_get failed\n", node->full_name);
+ return;
+ }
+
+ rate = clk_get_rate(pll_clk) / (div * 2);
+
+ clk = clk_register_fixed_rate(NULL, name, NULL, CLK_IS_ROOT, rate);
+ if (IS_ERR(clk)) {
+ pr_err("%s: clk_register_fixed_rate failed\n", node->full_name);
+ return;
+ }
+
+ clk_register_clkdev(clk, NULL, name);
+ of_clk_add_provider(node, of_clk_src_simple_get, clk);
+}
+CLK_OF_DECLARE(moxart_apb_clock, "moxa,moxart-apb-clock",
+ moxart_of_apb_clk_init);
--
1.8.2.1
^ permalink raw reply related
* [patch] drm/exynos: potential use after free in exynos_drm_open()
From: walter harms @ 2014-01-21 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DE69F3.9070307@bfs.de>
i have just noticed: The function already exits
194 static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
195 {
196 if (!file->driver_priv)
197 return;
198
199 kfree(file->driver_priv);
200 file->driver_priv = NULL;
201 }
Am 21.01.2014 13:37, schrieb walter harms:
>
>
> Am 21.01.2014 07:57, schrieb Dan Carpenter:
>> If exynos_drm_subdrv_open() fails then we re-use "file_priv".
>>
>> Fixes: 96f5421523df ('drm/exynos: use a new anon file for exynos gem mmaper')
>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index 9d096a0c5f8d..3c845292845a 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -174,6 +174,7 @@ static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
>> if (ret) {
>> kfree(file_priv);
>> file->driver_priv = NULL;
>> + return ret;
>> }
>
> using
> kfree( file->driver_priv );
> file->driver_priv = NULL;
>
> would be less confusing to read, and give checkers a better chance to spot mistakes.
> (btw: file_priv could be removed from this function completely).
>
> just my 2 cents,
> re,
> wh
>
>>
>> anon_filp = anon_inode_getfile("exynos_gem", &exynos_drm_gem_fops,
>> @@ -186,7 +187,7 @@ static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
>> anon_filp->f_mode = FMODE_READ | FMODE_WRITE;
>> file_priv->anon_filp = anon_filp;
>>
>> - return ret;
>> + return 0;
>> }
>>
>> static void exynos_drm_preclose(struct drm_device *dev,
>> --
>> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [patch] drm/exynos: potential use after free in exynos_drm_open()
From: walter harms @ 2014-01-21 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121065748.GC31535@elgon.mountain>
Am 21.01.2014 07:57, schrieb Dan Carpenter:
> If exynos_drm_subdrv_open() fails then we re-use "file_priv".
>
> Fixes: 96f5421523df ('drm/exynos: use a new anon file for exynos gem mmaper')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 9d096a0c5f8d..3c845292845a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -174,6 +174,7 @@ static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
> if (ret) {
> kfree(file_priv);
> file->driver_priv = NULL;
> + return ret;
> }
using
kfree( file->driver_priv );
file->driver_priv = NULL;
would be less confusing to read, and give checkers a better chance to spot mistakes.
(btw: file_priv could be removed from this function completely).
just my 2 cents,
re,
wh
>
> anon_filp = anon_inode_getfile("exynos_gem", &exynos_drm_gem_fops,
> @@ -186,7 +187,7 @@ static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
> anon_filp->f_mode = FMODE_READ | FMODE_WRITE;
> file_priv->anon_filp = anon_filp;
>
> - return ret;
> + return 0;
> }
>
> static void exynos_drm_preclose(struct drm_device *dev,
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
From: Arnd Bergmann @ 2014-01-21 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYiy+sya6NqRfAmsrFOXvaa3qX=qjRuTDW1vZVSaG1+Gg@mail.gmail.com>
On Tuesday 21 January 2014, Linus Walleij wrote:
> On Tue, Jan 21, 2014 at 4:11 AM, Alexandre Courbot <gnurou@gmail.com> wrote:
> > On Sat, Jan 18, 2014 at 8:11 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > I agree that's how it should be be done with the current API if your
> > driver can obtain GPIOs from both ACPI and DT. This is a potential
> > issue, as drivers are not supposed to make assumptions about who is
> > going to be their GPIO provider. Let's say you started a driver with
> > only DT in mind, and used gpio_get(dev, con_id) to get your GPIOs. DT
> > bindings are thus of the form "con_id-gpio = <phandle>", and set in
> > stone. Then later, someone wants to use your driver with ACPI. How do
> > you handle that gracefully?
>
> Short answer is you can't. You have to pour backward-compatibility
> code into the driver first checking for that property and then falling
> back to the new binding if it doesn't exist.
With the ACPI named properties extension, it should be possible to have
something akin to a "gpio-names" list that can be attached to an indexed
array of gpio descriptors. I assume that Intel is going to need this
for named irqs, clocks, regulators, dmas as well, so I think it will
eventually get there. It's not something that can be done today though,
or that is standardized in APCI-5.0.
My guess is that named GPIOs are going to make more sense on x86 embedded
than on arm64 server.
> > I'm starting to wonder, now that ACPI is a first-class GPIO provider,
> > whether we should not start to encourage the deprecation of the
> > "con_id-gpio = <phandle>" binding form in DT and only use a single
> > indexed GPIO property per device.
>
> You have a valid point.
Independent of ACPI, I prefer indexed "gpios" properties over "con_id-gpio"
properties anyway, because it's more consistent with some of the other
subsystems. I don't have an opinion though on whether we should also
allow a "gpios"/"gpio-names" pair, or whether we should keep the indexed
"gpios" list for the anonymous case.
> > The con_id parameter would then only
> > be used as a label, which would also have the nice side-effect that
> > all GPIOs used for a given function will be reported under the same
> > name no matter what the GPIO provider is.
>
> As discussed earlier in this thread I'm not sure the con_id is
> suitable for labelling GPIOs. It'd be better to have a proper name
> specified in DT/ACPI instead.
+1
> > From an aesthetic point of view, I definitely prefer using con_id to
> > identify GPIOs instead of indexes, but I don't see how we can make it
> > play nice with ACPI. Thoughts?
>
> Let's ask the DT maintainers...
>
> I'm a bit sceptic to the whole ACPI-DT-API-should-be-unified
> just-one-function-call business, as this was just a very simple example
> of what can happen to something as simple as
> devm_gpiod_get[_index]().
I think a unified kernel API makes more sense for some subsystems than
others, and it depends a bit on the rate of adoption of APCI for drivers
that already have a DT binding (or vice versa, if that happens).
GPIO might actually be in the first category since it's commonly used
for off-chip components that will get shared across ARM and x86 (as
well as everything else), while a common kernel API would be less
important for things that are internal to an SoC where Intel is the
only company needing ACPI support.
Arnd
^ permalink raw reply
* [PATCH v4 3/4] ARM: pinctrl: Add Broadcom Capri pinctrl driver
From: Linus Walleij @ 2014-01-21 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DD75B1.3090701@broadcom.com>
On Mon, Jan 20, 2014 at 8:14 PM, Sherman Yin <syin@broadcom.com> wrote:
> I'll confirm the new name with Matt before sending out another patch. Which
> would work better for you - a) a set of patches replacing my previous ones,
> b) a set of patches on top of my previous ones, c) a single patch on top of
> my previous ones? d) something else?
(c)
The tree goes upstream now, you have to make this fix on top.
Yours,
Linus Walleij
^ permalink raw reply
* [RFC PATCH 2/3] arm64: KVM: trap VM system registers until MMU and caches are ON
From: Pranavkumar Sawargaonkar @ 2014-01-21 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAhSdy1+P0p5-i+oouFv_HwjG3gh1djee7S3er0+WE=TmX2fnw@mail.gmail.com>
Hi Marc,
On 20 January 2014 22:00, Anup Patel <anup@brainfault.org> wrote:
> Hi Marc,
>
> On Mon, Jan 20, 2014 at 7:11 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> Hi Anup,
>>
>> On 20/01/14 12:00, Anup Patel wrote:
>>> On Fri, Jan 17, 2014 at 8:33 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>>>> In order to be able to detect the point where the guest enables
>>>> its MMU and caches, trap all the VM related system registers.
>>>>
>>>> Once we see the guest enabling both the MMU and the caches, we
>>>> can go back to a saner mode of operation, which is to leave these
>>>> registers in complete control of the guest.
>>>>
>>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>>> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
>>>> ---
>>>> arch/arm64/include/asm/kvm_arm.h | 3 ++-
>>>> arch/arm64/kvm/sys_regs.c | 58 ++++++++++++++++++++++++++++++++--------
>>>> 2 files changed, 49 insertions(+), 12 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
>>>> index c98ef47..fd0a651 100644
>>>> --- a/arch/arm64/include/asm/kvm_arm.h
>>>> +++ b/arch/arm64/include/asm/kvm_arm.h
>>>> @@ -62,6 +62,7 @@
>>>> * RW: 64bit by default, can be overriden for 32bit VMs
>>>> * TAC: Trap ACTLR
>>>> * TSC: Trap SMC
>>>> + * TVM: Trap VM ops (until M+C set in SCTLR_EL1)
>>>> * TSW: Trap cache operations by set/way
>>>> * TWE: Trap WFE
>>>> * TWI: Trap WFI
>>>> @@ -74,7 +75,7 @@
>>>> * SWIO: Turn set/way invalidates into set/way clean+invalidate
>>>> */
>>>> #define HCR_GUEST_FLAGS (HCR_TSC | HCR_TSW | HCR_TWE | HCR_TWI | HCR_VM | \
>>>> - HCR_BSU_IS | HCR_FB | HCR_TAC | \
>>>> + HCR_TVM | HCR_BSU_IS | HCR_FB | HCR_TAC | \
>>>> HCR_AMO | HCR_IMO | HCR_FMO | \
>>>> HCR_SWIO | HCR_TIDCP | HCR_RW)
>>>> #define HCR_VIRT_EXCP_MASK (HCR_VA | HCR_VI | HCR_VF)
>>>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>>>> index 02e9d09..5e92b9e 100644
>>>> --- a/arch/arm64/kvm/sys_regs.c
>>>> +++ b/arch/arm64/kvm/sys_regs.c
>>>> @@ -121,6 +121,42 @@ done:
>>>> }
>>>>
>>>> /*
>>>> + * Generic accessor for VM registers. Only called as long as HCR_TVM
>>>> + * is set.
>>>> + */
>>>> +static bool access_vm_reg(struct kvm_vcpu *vcpu,
>>>> + const struct sys_reg_params *p,
>>>> + const struct sys_reg_desc *r)
>>>> +{
>>>> + BUG_ON(!p->is_write);
>>>> +
>>>> + vcpu_sys_reg(vcpu, r->reg) = *vcpu_reg(vcpu, p->Rt);
>>>> + return true;
>>>> +}
>>>> +
>>>> +/*
>>>> + * SCTLR_EL1 accessor. Only called as long as HCR_TVM is set. If the
>>>> + * guest enables the MMU, we stop trapping the VM sys_regs and leave
>>>> + * it in complete control of the caches.
>>>> + */
>>>> +static bool access_sctlr_el1(struct kvm_vcpu *vcpu,
>>>> + const struct sys_reg_params *p,
>>>> + const struct sys_reg_desc *r)
>>>> +{
>>>> + unsigned long val;
>>>> +
>>>> + BUG_ON(!p->is_write);
>>>> +
>>>> + val = *vcpu_reg(vcpu, p->Rt);
>>>> + vcpu_sys_reg(vcpu, r->reg) = val;
>>>> +
>>>> + if ((val & (0b101)) == 0b101) /* MMU+Caches enabled? */
>>>> + vcpu->arch.hcr_el2 &= ~HCR_TVM;
>>>> +
>>>> + return true;
>>>> +}
>>>> +
>>>> +/*
>>>> * We could trap ID_DFR0 and tell the guest we don't support performance
>>>> * monitoring. Unfortunately the patch to make the kernel check ID_DFR0 was
>>>> * NAKed, so it will read the PMCR anyway.
>>>> @@ -185,32 +221,32 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>>>> NULL, reset_mpidr, MPIDR_EL1 },
>>>> /* SCTLR_EL1 */
>>>> { Op0(0b11), Op1(0b000), CRn(0b0001), CRm(0b0000), Op2(0b000),
>>>> - NULL, reset_val, SCTLR_EL1, 0x00C50078 },
>>>> + access_sctlr_el1, reset_val, SCTLR_EL1, 0x00C50078 },
>>>
>>> This patch in its current form breaks Aarch32 VMs on Foundation v8 Model
>>> because encoding for Aarch64 VM registers we get Op0=0b11 and for Aarch32
>>> VM registers we get Op0=0b00 when trapped.
>>>
>>> Either its a Foundation v8 Model bug or we need to add more enteries in
>>> sys_reg_desc[] for Aarch32 VM registers with Op0=0b00.
>>
>> That's a good point. But Op0 isn't defined for AArch32, the value is
>> simply hardcoded in kvm_handle_cp15_32/kvm_handle_cp15_64, which is
>> obviously horribly broken.
>>
>> I'll work on a fix for that, thanks noticing it.
>>
>> Does this series otherwise fix your L3 cache issue (assuming you stick
>> to 64bit guests)?
>
> Just started trying your patches today.
> First tried on Foundation v8 Model.
> Next we will try on X-Gene.
>
> Me or Pranav will soon provide more feedback in this regard.
>
Tested this patch with kvmtool on xgene, works fine !!
>>
>> Cheers,
>>
>> M.
>> --
>> Jazz is not dead. It just smells funny...
Thanks,
Pranav
>
> Thanks,
> Anup
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
^ permalink raw reply
* [PATCH v3] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN
From: Stefano Stabellini @ 2014-01-21 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121110826.GG30706@mudshark.cambridge.arm.com>
On Tue, 21 Jan 2014, Will Deacon wrote:
> On Mon, Jan 20, 2014 at 03:32:48PM +0000, Stefano Stabellini wrote:
> > On Thu, 16 Jan 2014, Will Deacon wrote:
> > > For the xchg part, yes, that looks a lot better. I don't like the #undef
> > > CONFIG_CPU_V6 though, can that be rewritten to use __LINUX_ARM_ARCH__?
> >
> > The problem is that the 1 and 2 byte parameter size cases in __cmpxchg
> > are ifdef'ed CONFIG_CPU_V6 but drivers/xen/grant-table.c needs them.
> >
> > So we can either undef CONFIG_CPU_V6 in grant-table.c or call a
> > different function.
> >
> > If I switch from ifdef CONFIG_CPU_V6 to if __LINUX_ARM_ARCH__ > 6 in
> > __cmpxchg, we still have the problem that if __LINUX_ARM_ARCH__ == 6,
> > grant-table.c doesn't compile.
> >
> > Maybe the approach taken by the other patch for cmpxchg is better, see
> > below.
>
> Yes, I prefer this approach. Minor comment below.
>
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index c1f1a7e..ae54ae0 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1881,8 +1881,7 @@ config XEN_DOM0
> > config XEN
> > bool "Xen guest support on ARM (EXPERIMENTAL)"
> > depends on ARM && AEABI && OF
> > - depends on CPU_V7 && !CPU_V6
> > - depends on !GENERIC_ATOMIC64
> > + depends on CPU_V7
> > select ARM_PSCI
> > select SWIOTLB_XEN
> > help
> > diff --git a/arch/arm/include/asm/cmpxchg.h b/arch/arm/include/asm/cmpxchg.h
> > index df2fbba..cc8a4a2 100644
> > --- a/arch/arm/include/asm/cmpxchg.h
> > +++ b/arch/arm/include/asm/cmpxchg.h
> > @@ -133,6 +133,44 @@ extern void __bad_cmpxchg(volatile void *ptr, int size);
> > * cmpxchg only support 32-bits operands on ARMv6.
> > */
> >
> > +static inline unsigned long __cmpxchg8(volatile void *ptr, unsigned long old,
> > + unsigned long new)
> > +{
> > + unsigned long oldval, res;
> > +
> > + do {
> > + asm volatile("@ __cmpxchg1\n"
> > + " ldrexb %1, [%2]\n"
> > + " mov %0, #0\n"
> > + " teq %1, %3\n"
> > + " strexbeq %0, %4, [%2]\n"
> > + : "=&r" (res), "=&r" (oldval)
> > + : "r" (ptr), "Ir" (old), "r" (new)
> > + : "memory", "cc");
> > + } while (res);
> > +
> > + return oldval;
> > +}
> > +
> > +static inline unsigned long __cmpxchg16(volatile void *ptr, unsigned long old,
> > + unsigned long new)
> > +{
> > + unsigned long oldval, res;
> > +
> > + do {
> > + asm volatile("@ __cmpxchg1\n"
>
> Can you fix this comment while you're here please?
OK, I'll use @ __cmpxchg16 and @ __cmpxchg8.
I'll resend as a separate patch.
^ permalink raw reply
* [RFC PATCH 1/1] of/irq: create interrupts-extended-2 property
From: Mark Rutland @ 2014-01-21 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMjrLs9eEPurjUpOfgyexnc__FJkRYmAR84_f7C15HH07Q@mail.gmail.com>
On Tue, Jan 21, 2014 at 01:03:23AM +0000, Olof Johansson wrote:
> On Mon, Jan 20, 2014 at 2:47 PM, Grant Likely <grant.likely@linaro.org> wrote:
> > On Wed, 15 Jan 2014 16:12:24 +0000, Mark Rutland <mark.rutland@arm.com> wrote:
> >> >
> >> > Another, more invasive option would be extend the dts syntax and teach
> >> > dtc to handle property appending. Then the soc dts could stay as it is,
> >> > and the board dts could have something like:
> >> >
> >> > /append-property/ interrupts = <&intc1 6 1>;
> >> > /append-property/ interrupt-names = "board-specific-irq";
> >> >
> >> > Both these options solve the issue at the source, are general to other
> >> > properties, and allow more than one level of hierarchy (the proposed
> >> > interrupts-extended-2 only allows one level).
> >>
> >> I've just had a go at implementing the append-property mechanism above
> >> in dtc, and it was far easier than I expected (patch below).
> >>
> >> Does anyone have any issues with the /append-property/ idea?
> >
> > I think that is reasonable.
>
>
> The main problem with this (same for clocks) is if you need to append
> something with a name when the original didn't have any.
Can you not just add a name in the original file? I assume we're not
going to use this to adjust dts files we're not already in full control
of.
>
> Reordering entries might not work for interrupts, since the bindings
> might have requirements on order.
That's a fair point.
Do we currently have any optional/board-specific interrupts which must
appear at the start or middle of the list?
For those, could we add names? The kernel should be abel to fall back to
ordering if names aren't present, and we can recommend a particular
ordering for compatiblity with older kernels.
As a general preventative measure it would be nice to have named
elements whenever elements can be optional.
>
> I'm not aware of a good solution for this. Suggestions welcome.
Me neither. Prepending and appending is easy.
Inserting and/or modifying the list requires knowledge of the size of
each element (and for variable-sized entries requires knowledge of the
particular binding, which we cannot embed in dtc).
I suspect adding richer syntax for modifying properties in arbitrary
ways will devolve into a turing tarpit.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2] dma: imx-sdma: clarify firmare not found warning
From: Russell King - ARM Linux @ 2014-01-21 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121125200.6b1e96bd@ipc1.ka-ro>
On Tue, Jan 21, 2014 at 12:52:00PM +0100, Lothar Wa?mann wrote:
> Hi,
>
> Russell King - ARM Linux wrote:
> > On Tue, Jan 21, 2014 at 07:59:22AM +0100, Lothar Wa?mann wrote:
> > > The file is automatically removed after the timeout has expired (or
> > > the frimware has been loaded).
> > > Thus you must check for it within the timeout period during boot.
> >
> > ... which is impossible if imx-sdma is built into the kernel - it
> > expires while the initramfs has only just started running, giving a
> > very narrow window for userspace to load firmware.
> >
> It works for me, but I'm not using initramfs.
You can take my email as a report of "it doesn't work for everyone." The
*only* way I can get firmware to load is to build imx-sdma as a module.
Building it in is a hopeless case here.
--
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 v2] dma: imx-sdma: clarify firmare not found warning
From: Lothar Waßmann @ 2014-01-21 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121110107.GS15937@n2100.arm.linux.org.uk>
Hi,
Russell King - ARM Linux wrote:
> On Tue, Jan 21, 2014 at 07:59:22AM +0100, Lothar Wa?mann wrote:
> > The file is automatically removed after the timeout has expired (or
> > the frimware has been loaded).
> > Thus you must check for it within the timeout period during boot.
>
> ... which is impossible if imx-sdma is built into the kernel - it
> expires while the initramfs has only just started running, giving a
> very narrow window for userspace to load firmware.
>
It works for me, but I'm not using initramfs.
Lothar Wa?mann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
^ permalink raw reply
* [PATCH RFC v2 1/2] Documentation: arm: add cache DT bindings
From: Dave Martin @ 2014-01-21 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390240079-6495-2-git-send-email-lorenzo.pieralisi@arm.com>
On Mon, Jan 20, 2014 at 05:47:58PM +0000, Lorenzo Pieralisi wrote:
> On ARM systems the cache topology cannot be probed at runtime, in
> particular, it is impossible to probe which CPUs share a given cache
> level. Power management software requires this knowledge to implement
> optimized power down sequences, hence this patch adds a document that
> defines the DT cache bindings for ARM systems. The bindings are compliant
> with ePAPR (PowerPC bindings), even though most of the cache nodes
> properties requirements are overriden, because caches geometry for
> architected caches is probeable on ARM systems. This patch also adds
> properties that are specific to ARM architected caches to the existing ones
> defined in the ePAPR v1.1, as bindings extensions.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> ---
> Documentation/devicetree/bindings/arm/cache.txt | 187 ++++++++++++++++++++++++
> 1 file changed, 187 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/cache.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/cache.txt b/Documentation/devicetree/bindings/arm/cache.txt
> new file mode 100644
> index 0000000..b27cedf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/cache.txt
> @@ -0,0 +1,187 @@
> +==========================================
> +ARM processors cache binding description
> +==========================================
> +
> +Device tree bindings for ARM processor caches adhere to the cache bindings
> +described in [3], in section 3.8 for multi-level and shared caches.
> +On ARM based systems most of the cache properties related to cache
> +geometry are probeable in HW, hence, unless otherwise stated, the properties
> +defined in ePAPR for multi-level and shared caches are to be considered
> +optional by default.
This point should be highlighted for discussion.
I do have a worry that because the kernel won't normally use this
information, by default it will get pasted between .dts files, won't get
tested and will be wrong rather often. It also violates the DT principle
that probeable information should not be present in the DT -- ePAPR
obviously envisages systems where cache geometry information is not
probeable, but that's not the case for architected caches on ARM, except
in rare cases where the CLIDR is wrong.
But deviating needlessly from ePAPR is arguably a bad thing too.
There is one good argument in favour of making these properties
mandatory: it gives people a way to get (possibly wrong or unvalidated)
information about cache geometry and topology into userspace without the
kernel having to care. This remains a contraversial issue though.
If we decide to allow or mandate these properties, the kernel should
validate them for consistency with the hardware and BUG() on boot if they
are inconsistent. This is the correct approach until/unless the kernel
grows a proper mechanism for using this info from the DT.
> +
> +On ARM, caches are either architected (directly controlled by the processor
> +through coprocessor instructions and tightly coupled with the processor
> +implementation) or unarchitected (controlled through a memory mapped
> +interface, implemented as a stand-alone IP external to the processor
> +implementation).
> +
> +This document provides the device tree bindings for ARM architected caches.
> +
> +- ARM architected cache node
> +
> + Description: must be a direct child of the cpu node. A system
For this paragraph as a whole:
Can we break this paragraph up, and move the background information (e.g.
description of the ARM Architecture) outside?
It's long and hard to read at present.
I think we only need the fundamental rules, which are basically that
the next-level-cache properties must be consistent with the hardware
cache topology. We could try to be more precise, but ePAPR is pretty
vague too.
> + can contain multiple architected cache nodes per cpu node,
> + linked through the next-level-cache phandle. The
> + next-level-cache property in the cpu node points to
> + the first level of architected cache for the CPU.
> + The next-level-cache property in architected cache nodes
> + points to the respective next level of caching in the
> + hierarchy. An architected cache node with an empty or
> + missing next-level-cache property represents the last
> + architected cache level for the CPU.
> + On ARM v7 and v8 architectures, the order in which cache
> + nodes are linked through the next-level-cache phandle must
> + follow the ordering specified in the processors CLIDR (v7)
We shouldn't describe the ARM Architecture in the binding. That's
background information that could move outside.
> + and CLIDR_EL1 (v8) registers, as described in [1][2],
> + implying that a cache node pointed at by a
> + next-level-cache phandle must correspond to a level
> + defined in CLIDR (v7) and CLIDR_EL1 (v8) greater than the
> + one the cache node containing the next-level-cache
> + phandle corresponds to.
> +
> + Since on ARM most of the cache properties are probeable in HW the
> + properties described in [3] - section 3.8 multi-level and shared
> + caches - shall be considered optional, with the following properties
> + updates, specific for the ARM architected cache node.
> +
> + - compatible
> + Usage: Required
> + Value type: <string>
> + Definition: value shall be "arm,arch-cache".
> +
> + - interrupts
> + Usage: Optional
> + Value type: See definition
> + Definition: standard device tree property [3] that defines
> + the interrupt line associated with the cache.
> + The property can be accompanied by an
> + interrupt-names property, as described in [4].
Do ARM Architectured caches ever have interrupts? (Just my ignorance
here.)
> +
> + - power-domain
> + Usage: Optional
> + Value type: phandle
> + Definition: A phandle and power domain specifier as defined by
> + bindings of power controller specified by the
> + phandle [5].
> +
> +Example(dual-cluster big.LITTLE system 32-bit)
> +
> + cpus {
> + #size-cells = <0>;
> + #address-cells = <1>;
> +
> + cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <0x0>;
> + next-level-cache = <&L1_0>;
ePAPR puts the L1 cache properties in the cpu node directly;
there's no "L1" node as such. That geometry description is also
mandated by ePAPR.
The ARM Architecture does not force a CPU to have any non-shared
first level(s) of cache, and ePAPR does not permit next-level-cache
to point to a cpu node, so there are possible ARM Architecture
implementations that cannot be described without violating ePAPR.
However, for practical reasons, such systems are unlikely -- I don't
know if any exist today.
We should decide whether to deviate explicitly from ePAPR on this
point (your examples provide on way), or whether to follow ePAPR and
bodge things later for L1-less systems if they appear.
Cheers
---Dave
^ permalink raw reply
* Removing PLAT_ORION dependency from ARCH_MVEBU (Was Re: [PATCH v2 14/15] watchdog: orion: Allow to build on any Orion platform)
From: Sebastian Hesselbarth @ 2014-01-21 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121110603.GB4356@localhost>
On 01/21/14 12:06, Ezequiel Garcia wrote:
> Sebastian,
>
> I'm picking on this discussion, with a new Subject.
>
> On Tue, Jan 21, 2014 at 10:41:17AM +0100, Sebastian Hesselbarth wrote:
>> On 01/21/14 10:12, Ezequiel Garcia wrote:
>>> After getting rid of all the mach-specific code, it's now possible
>>> to allow builds in any Orion platform.
>>>
>>> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
>>> ---
>>> drivers/watchdog/Kconfig | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
>>> index 5be6e91..1689f72 100644
>>> --- a/drivers/watchdog/Kconfig
>>> +++ b/drivers/watchdog/Kconfig
>>> @@ -282,7 +282,7 @@ config DAVINCI_WATCHDOG
>>>
>>> config ORION_WATCHDOG
>>> tristate "Orion watchdog"
>>> - depends on ARCH_ORION5X || ARCH_KIRKWOOD || ARCH_DOVE
>>> + depends on PLAT_ORION
> [..]
>>
>> I haven't checked why ARCH_MVEBU at all added PLAT_ORION as dependency,
>> but IIRC it was just because of a missing mbus driver? If it is just
>> this, we should also remove PLAT_ORION from ARCH_MVEBU to have a clean
>> cut between new common arch and existing sub-archs.
>>
>
> Well, I'm not sure if I'm following you. Many drivers currently depend
> on PLAT_ORION, so if we remove PLAT_ORION from ARCH_MVEBU we would have
> to replace: s/PLAT_ORION/ARCH_{MVEBU, KIRKWOOD, DOVE, ...}.
>
> Is this the suggested roadmap or I've completely misunderstood it?
Actually, you are right, PLAT_ORION is dependency for a bunch of
drivers. But as PLAT_ORION - code-wise - almost only contains non-DT
stuff, I'd prefer to use ARCH_MVEBU for DT enabled Marvell SoCs where
possible.
So for the above, just add ARCH_MVEBU and remove ARCH_KIRKWOOD,
ARCH_DOVE later when we kill them, instead of hiding all behind
PLAT_ORION. Also remove the dependency of ARCH_MVEBU to PLAT_ORION
where possible or replace it with ARCH_MVEBU directly.
This way we would have a clean ARCH_MVEBU config for DT-enabled
SoCs and PLAT_ORION for non-DT ones. BTW, there is also
PLAT_ORION_LEGACY which is just selecting PLAT_ORION. IIRC, I added
that to distinguish non-DT and DT earlier, but ARCH_MVEBU selecting
PLAT_ORION made that redundant.
Sebastian
^ 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