* [PATCH 0/5] SMP support for Armada XP
From: Gregory CLEMENT @ 2012-10-22 17:02 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
The purpose of this patch set is to add the SMP support for the Armada
XP SoCs. Beside the SMP support itself brought by the last 3 patches,
this patch set also adds the support for the coherency fabric unit and
the power management service unit.
The coherency fabric is responsible for ensuring hardware coherency
between all CPUs and between CPUs and I/O masters. This unit is also
available for Armada 370 and will be used in an incoming patch set
for hardware I/O cache coherency.
The power management service unit is responsible for powering down and
waking up CPUs and other SOC units.
The original code is from Yehuda Yitschak, it was reworked by myself
and reviewed by Yehuda.
This patch set is based on 3.7-rc2 and depends one the framework clock
support (the last version was posted last week:
http://thread.gmane.org/gmane.linux.kernel/1375701). The git branch
called ArmadaXP-SMP-for-3.8 is also available at
https://github.com/MISL-EBU-System-SW/mainline-public.git.
Regards,
Yehuda Yitschak (5):
arm: mvebu: Added support for coherency fabric in mach-mvebu
arm: mvebu: Added initial support for power managmement service unit
arm: mvebu: Added IPI support via doorbells
arm: mm: Added support for PJ4B cpu and init routines
arm: mvebu: Added SMP support for Armada XP
.../devicetree/bindings/arm/armada-370-xp-pmsu.txt | 20 ++++
.../devicetree/bindings/arm/coherency-fabric.txt | 16 +++
arch/arm/boot/dts/armada-370-xp.dtsi | 5 +
arch/arm/boot/dts/armada-xp.dtsi | 12 +-
arch/arm/configs/mvebu_defconfig | 3 +
arch/arm/mach-mvebu/Kconfig | 3 +-
arch/arm/mach-mvebu/Makefile | 4 +-
arch/arm/mach-mvebu/armada-370-xp.c | 1 +
arch/arm/mach-mvebu/armada-370-xp.h | 10 ++
arch/arm/mach-mvebu/coherency.c | 92 +++++++++++++++
arch/arm/mach-mvebu/coherency.h | 20 ++++
arch/arm/mach-mvebu/common.h | 6 +
arch/arm/mach-mvebu/headsmp.S | 65 +++++++++++
arch/arm/mach-mvebu/hotplug.c | 30 +++++
arch/arm/mach-mvebu/irq-armada-370-xp.c | 92 ++++++++++++++-
arch/arm/mach-mvebu/platsmp.c | 123 ++++++++++++++++++++
arch/arm/mach-mvebu/pmsu.c | 78 +++++++++++++
arch/arm/mach-mvebu/pmsu.h | 16 +++
arch/arm/mm/Kconfig | 4 +
arch/arm/mm/proc-v7.S | 46 ++++++++
20 files changed, 637 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
create mode 100644 Documentation/devicetree/bindings/arm/coherency-fabric.txt
create mode 100644 arch/arm/mach-mvebu/coherency.c
create mode 100644 arch/arm/mach-mvebu/coherency.h
create mode 100644 arch/arm/mach-mvebu/headsmp.S
create mode 100644 arch/arm/mach-mvebu/hotplug.c
create mode 100644 arch/arm/mach-mvebu/platsmp.c
create mode 100644 arch/arm/mach-mvebu/pmsu.c
create mode 100644 arch/arm/mach-mvebu/pmsu.h
--
1.7.9.5
^ permalink raw reply
* [PATCH 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
From: Gregory CLEMENT @ 2012-10-22 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350925368-24243-1-git-send-email-gregory.clement@free-electrons.com>
From: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
.../devicetree/bindings/arm/coherency-fabric.txt | 16 ++++
arch/arm/boot/dts/armada-370-xp.dtsi | 5 ++
arch/arm/mach-mvebu/Makefile | 2 +-
arch/arm/mach-mvebu/coherency.c | 92 ++++++++++++++++++++
arch/arm/mach-mvebu/coherency.h | 20 +++++
arch/arm/mach-mvebu/common.h | 2 +
6 files changed, 136 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/arm/coherency-fabric.txt
create mode 100644 arch/arm/mach-mvebu/coherency.c
create mode 100644 arch/arm/mach-mvebu/coherency.h
diff --git a/Documentation/devicetree/bindings/arm/coherency-fabric.txt b/Documentation/devicetree/bindings/arm/coherency-fabric.txt
new file mode 100644
index 0000000..2bfbf67
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/coherency-fabric.txt
@@ -0,0 +1,16 @@
+Coherency fabric
+----------------
+Available on Marvell SOCs: Armada 370 and Armada XP
+
+Required properties:
+
+- compatible: "marvell,coherency-fabric"
+- reg: Should contain,coherency fabric registers location and length.
+
+Example:
+
+coherency-fabric at d0020200 {
+ compatible = "marvell,coherency-fabric";
+ reg = <0xd0020200 0xb0>;
+};
+
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 94b4b9e..b0d075b 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -36,6 +36,11 @@
interrupt-controller;
};
+ coherency-fabric at d0020200 {
+ compatible = "marvell,coherency-fabric";
+ reg = <0xd0020200 0xb0>;
+ };
+
soc {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 57f996b..abd6d3b 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -2,4 +2,4 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
-I$(srctree)/arch/arm/plat-orion/include
obj-y += system-controller.o
-obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o
+obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o coherency.o
diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
new file mode 100644
index 0000000..71e27ba
--- /dev/null
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -0,0 +1,92 @@
+/*
+ * Coherency fabric (Aurora) support for Armada 370 and XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Yehuda Yitschak <yehuday@marvell.com>
+ * Gregory Clement <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.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.
+ *
+ * The Armada 370 and Armada XP SOCs have a coherency fabric which is
+ * responsible for ensuring hardware coherency between all CPUs and between
+ * CPUs and I/O masters. This file initializes the coherency fabric and
+ * supplies basic routines for configuring and controlling hardware coherency
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/of_address.h>
+#include <linux/io.h>
+#include <linux/smp.h>
+#include "armada-370-xp.h"
+
+/* Some functions in this file are called very early during SMP
+ * initialization. At that time the device tree framework is not yet
+ * ready, and it is not possible to get the register address to
+ * ioremap it. That's why the pointer below is given with an initial
+ * value matching its virtual mapping
+ */
+static void __iomem *coherency_base = ARMADA_370_XP_REGS_VIRT_BASE + 0x20200;
+
+/* Coherency fabric registers */
+#define COHERENCY_FABRIC_CTL_OFFSET 0x0
+#define COHERENCY_FABRIC_CFG_OFFSET 0x4
+
+static struct of_device_id of_coherency_table[] = {
+ {.compatible = "marvell,coherency-fabric"},
+ { /* end of list */ },
+};
+
+int armada_xp_get_cpu_count(void)
+{
+ int reg, cnt;
+
+ reg = readl(coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
+ cnt = (reg & 0xF) + 1;
+
+ return cnt;
+}
+
+int armada_370_xp_set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
+{
+ int reg;
+
+ if (!coherency_base) {
+ pr_warn("Can't make CPU %d cache coherent.\n", hw_cpu_id);
+ pr_warn("Coherency fabric is not initialized\n");
+ return 1;
+ }
+
+ /* Enable the CPU in coherency fabric */
+ reg = readl(coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
+ reg |= 1 << (24 + hw_cpu_id);
+ writel(reg, coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
+
+ /* Add CPU to SMP group */
+ reg = readl(coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
+ reg |= 1 << (16 + hw_cpu_id + (smp_group_id == 0 ? 8 : 0));
+ writel(reg, coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
+
+ return 0;
+}
+
+int __init armada_370_xp_coherency_init(void)
+{
+ struct device_node *np;
+
+ np = of_find_matching_node(NULL, of_coherency_table);
+ if (np) {
+ pr_info("Initializing Coherency fabric\n");
+ coherency_base = of_iomap(np, 0);
+ }
+
+ return 0;
+}
+
+/* Coherency initialization have to be done before the SMP
+ * initialization of the CPUs*/
+early_initcall(armada_370_xp_coherency_init);
diff --git a/arch/arm/mach-mvebu/coherency.h b/arch/arm/mach-mvebu/coherency.h
new file mode 100644
index 0000000..3c7e5b2
--- /dev/null
+++ b/arch/arm/mach-mvebu/coherency.h
@@ -0,0 +1,20 @@
+/*
+ * arch/arm/mach-mvebu/include/mach/coherency.h
+ *
+ *
+ * Coherency fabric (Aurora) support for Armada 370 and XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * 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.
+ */
+
+#ifndef __MACH_370_XP_COHERENCY_H
+#define __MACH_370_XP_COHERENCY_H
+
+int armada_370_xp_set_cpu_coherent(int cpu_id, int smp_group_id);
+int armada_xp_get_cpu_count(void);
+
+#endif /* __MACH_370_XP_COHERENCY_H */
diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
index 281fab3..ea08919 100644
--- a/arch/arm/mach-mvebu/common.h
+++ b/arch/arm/mach-mvebu/common.h
@@ -21,4 +21,6 @@ void mvebu_clocks_init(void);
void armada_370_xp_init_irq(void);
void armada_370_xp_handle_irq(struct pt_regs *regs);
+
+int armada_370_xp_coherency_init(void);
#endif
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/5] arm: mvebu: Added initial support for power managmement service unit
From: Gregory CLEMENT @ 2012-10-22 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350925368-24243-1-git-send-email-gregory.clement@free-electrons.com>
From: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
.../devicetree/bindings/arm/armada-370-xp-pmsu.txt | 20 +++++
arch/arm/boot/dts/armada-xp.dtsi | 6 ++
arch/arm/mach-mvebu/Makefile | 2 +-
arch/arm/mach-mvebu/common.h | 1 +
arch/arm/mach-mvebu/pmsu.c | 78 ++++++++++++++++++++
arch/arm/mach-mvebu/pmsu.h | 16 ++++
6 files changed, 122 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
create mode 100644 arch/arm/mach-mvebu/pmsu.c
create mode 100644 arch/arm/mach-mvebu/pmsu.h
diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
new file mode 100644
index 0000000..926b4d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
@@ -0,0 +1,20 @@
+Power Management Service Unit(PMSU)
+-----------------------------------
+Available on Marvell SOCs: Armada 370 and Armada XP
+
+Required properties:
+
+- compatible: "marvell,armada-370-xp-pmsu"
+
+- reg: Should contain PMSU registers location and length. First pair
+ for the per-CPU SW Reset Control registers, second pair for the
+ Power Management Service Unit.
+
+Example:
+
+armada-370-xp-pmsu at d0022000 {
+ compatible = "marvell,armada-370-xp-pmsu";
+ reg = <0xd0022100 0x430>,
+ <0xd0020800 0x20>;
+};
+
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index a564b52..f521ed8 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -27,6 +27,12 @@
<0xd0021870 0x58>;
};
+ armada-370-xp-pmsu at d0022000 {
+ compatible = "marvell,armada-370-xp-pmsu";
+ reg = <0xd0022100 0x430>,
+ <0xd0020800 0x20>;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index abd6d3b..8e6e50b 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -2,4 +2,4 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
-I$(srctree)/arch/arm/plat-orion/include
obj-y += system-controller.o
-obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o coherency.o
+obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o coherency.o pmsu.o
diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
index ea08919..74ee0b2 100644
--- a/arch/arm/mach-mvebu/common.h
+++ b/arch/arm/mach-mvebu/common.h
@@ -23,4 +23,5 @@ void armada_370_xp_handle_irq(struct pt_regs *regs);
int armada_370_xp_coherency_init(void);
+int armada_370_xp_pmsu_init(void);
#endif
diff --git a/arch/arm/mach-mvebu/pmsu.c b/arch/arm/mach-mvebu/pmsu.c
new file mode 100644
index 0000000..cee020b
--- /dev/null
+++ b/arch/arm/mach-mvebu/pmsu.c
@@ -0,0 +1,78 @@
+/*
+ * Power Management Service Unit(PMSU) support for Armada 370/XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Yehuda Yitschak <yehuday@marvell.com>
+ * Gregory Clement <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.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.
+ *
+ * The Armada 370 and Armada XP SOCs have a power management service
+ * unit which is responsible for powering down and waking up CPUs and
+ * other SOC units
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/of_address.h>
+#include <linux/io.h>
+#include <linux/smp.h>
+#include <asm/smp_plat.h>
+
+static void __iomem *pmsu_mp_base;
+static void __iomem *pmsu_reset_base;
+
+#define PMSU_BOOT_ADDR_REDIRECT_OFFSET(cpu) ((cpu * 0x100) + 0x24)
+#define PMSU_RESET_CTL_OFFSET(cpu) (cpu * 0x8)
+
+static struct of_device_id of_pmsu_table[] = {
+ {.compatible = "marvell,armada-370-xp-pmsu"},
+ { /* end of list */ },
+};
+
+#ifdef CONFIG_SMP
+int armada_xp_boot_cpu(unsigned int cpu_id, void __iomem *boot_addr)
+{
+ int reg, hw_cpu;
+
+ if (!pmsu_mp_base || !pmsu_reset_base) {
+ pr_warn("Can't boot CPU. PMSU is uninitialized\n");
+ return 1;
+ }
+
+ hw_cpu = cpu_logical_map(cpu_id);
+
+ writel(virt_to_phys(boot_addr), pmsu_mp_base +
+ PMSU_BOOT_ADDR_REDIRECT_OFFSET(hw_cpu));
+
+ /* Make sure value hits memory before reset */
+ dsb();
+
+ /* Release CPU from reset by clearing reset bit*/
+ reg = readl(pmsu_reset_base + PMSU_RESET_CTL_OFFSET(hw_cpu));
+ reg &= (~0x1);
+ writel(reg, pmsu_reset_base + PMSU_RESET_CTL_OFFSET(hw_cpu));
+
+ return 0;
+}
+#endif
+
+int __init armada_370_xp_pmsu_init(void)
+{
+ struct device_node *np;
+
+ np = of_find_matching_node(NULL, of_pmsu_table);
+ if (np) {
+ pr_info("Initializing Power Management Service Unit\n");
+ pmsu_mp_base = of_iomap(np, 0);
+ pmsu_reset_base = of_iomap(np, 1);
+ }
+
+ return 0;
+}
+
+early_initcall(armada_370_xp_pmsu_init);
diff --git a/arch/arm/mach-mvebu/pmsu.h b/arch/arm/mach-mvebu/pmsu.h
new file mode 100644
index 0000000..bafac8e
--- /dev/null
+++ b/arch/arm/mach-mvebu/pmsu.h
@@ -0,0 +1,16 @@
+/*
+ * Power Management Service Unit (PMSU) support for Armada 370/XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * 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.
+ */
+
+#ifndef __MACH_MVEBU_PMSU_H
+#define __MACH_MVEBU_PMSU_H
+
+int armada_xp_boot_cpu(unsigned int cpu_id, void __iomem *phys_addr);
+
+#endif /* __MACH_370_XP_PMSU_H */
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/5] arm: mvebu: Added IPI support via doorbells
From: Gregory CLEMENT @ 2012-10-22 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350925368-24243-1-git-send-email-gregory.clement@free-electrons.com>
From: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-xp.dtsi | 2 +-
arch/arm/mach-mvebu/armada-370-xp.h | 10 ++++
arch/arm/mach-mvebu/irq-armada-370-xp.c | 92 +++++++++++++++++++++++++++++--
3 files changed, 97 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index f521ed8..531619f 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -24,7 +24,7 @@
mpic: interrupt-controller at d0020000 {
reg = <0xd0020a00 0x1d0>,
- <0xd0021870 0x58>;
+ <0xd0021070 0x58>;
};
armada-370-xp-pmsu at d0022000 {
diff --git a/arch/arm/mach-mvebu/armada-370-xp.h b/arch/arm/mach-mvebu/armada-370-xp.h
index aac9beb..dce590d 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.h
+++ b/arch/arm/mach-mvebu/armada-370-xp.h
@@ -19,4 +19,14 @@
#define ARMADA_370_XP_REGS_VIRT_BASE IOMEM(0xfeb00000)
#define ARMADA_370_XP_REGS_SIZE SZ_1M
+#ifndef __ASSEMBLY__
+
+#ifdef CONFIG_SMP
+#include <linux/cpumask.h>
+
+void armada_mpic_send_doorbell(const struct cpumask *mask, unsigned int irq);
+void armada_xp_mpic_smp_cpu_init(void);
+#endif
+#endif
+
#endif /* __MACH_ARMADA_370_XP_H */
diff --git a/arch/arm/mach-mvebu/irq-armada-370-xp.c b/arch/arm/mach-mvebu/irq-armada-370-xp.c
index 5f5f939..549b684 100644
--- a/arch/arm/mach-mvebu/irq-armada-370-xp.c
+++ b/arch/arm/mach-mvebu/irq-armada-370-xp.c
@@ -24,6 +24,7 @@
#include <linux/irqdomain.h>
#include <asm/mach/arch.h>
#include <asm/exception.h>
+#include <asm/smp_plat.h>
/* Interrupt Controller Registers Map */
#define ARMADA_370_XP_INT_SET_MASK_OFFS (0x48)
@@ -35,6 +36,12 @@
#define ARMADA_370_XP_CPU_INTACK_OFFS (0x44)
+#define ARMADA_370_XP_SW_TRIG_INT_OFFS (0x4)
+#define ARMADA_370_XP_IN_DRBEL_MSK_OFFS (0xc)
+#define ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS (0x8)
+
+#define ACTIVE_DOORBELLS (8)
+
static void __iomem *per_cpu_int_base;
static void __iomem *main_int_base;
static struct irq_domain *armada_370_xp_mpic_domain;
@@ -51,11 +58,22 @@ static void armada_370_xp_irq_unmask(struct irq_data *d)
per_cpu_int_base + ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
}
+#ifdef CONFIG_SMP
+static int armada_xp_set_affinity(struct irq_data *d,
+ const struct cpumask *mask_val, bool force)
+{
+ return 0;
+}
+#endif
+
static struct irq_chip armada_370_xp_irq_chip = {
.name = "armada_370_xp_irq",
.irq_mask = armada_370_xp_irq_mask,
.irq_mask_ack = armada_370_xp_irq_mask,
.irq_unmask = armada_370_xp_irq_unmask,
+#ifdef CONFIG_SMP
+ .irq_set_affinity = armada_xp_set_affinity,
+#endif
};
static int armada_370_xp_mpic_irq_map(struct irq_domain *h,
@@ -72,6 +90,41 @@ static int armada_370_xp_mpic_irq_map(struct irq_domain *h,
return 0;
}
+#ifdef CONFIG_SMP
+void armada_mpic_send_doorbell(const struct cpumask *mask, unsigned int irq)
+{
+ int cpu;
+ unsigned long map = 0;
+
+ /* Convert our logical CPU mask into a physical one. */
+ for_each_cpu(cpu, mask)
+ map |= 1 << cpu_logical_map(cpu);
+
+ /*
+ * Ensure that stores to Normal memory are visible to the
+ * other CPUs before issuing the IPI.
+ */
+ dsb();
+
+ /* submit softirq */
+ writel((map << 8) | irq, main_int_base +
+ ARMADA_370_XP_SW_TRIG_INT_OFFS);
+}
+
+void armada_xp_mpic_smp_cpu_init(void)
+{
+ /* Clear pending IPIs */
+ writel(0, per_cpu_int_base + ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS);
+
+ /* Enable first 8 IPIs */
+ writel((1 << ACTIVE_DOORBELLS) - 1, per_cpu_int_base +
+ ARMADA_370_XP_IN_DRBEL_MSK_OFFS);
+
+ /* Unmask IPI interrupt */
+ writel(0, per_cpu_int_base + ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
+}
+#endif /* CONFIG_SMP */
+
static struct irq_domain_ops armada_370_xp_mpic_irq_ops = {
.map = armada_370_xp_mpic_irq_map,
.xlate = irq_domain_xlate_onecell,
@@ -91,13 +144,18 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
control = readl(main_int_base + ARMADA_370_XP_INT_CONTROL);
armada_370_xp_mpic_domain =
- irq_domain_add_linear(node, (control >> 2) & 0x3ff,
- &armada_370_xp_mpic_irq_ops, NULL);
+ irq_domain_add_linear(node, (control >> 2) & 0x3ff,
+ &armada_370_xp_mpic_irq_ops, NULL);
if (!armada_370_xp_mpic_domain)
panic("Unable to add Armada_370_Xp MPIC irq domain (DT)\n");
irq_set_default_host(armada_370_xp_mpic_domain);
+
+#ifdef CONFIG_SMP
+ armada_xp_mpic_smp_cpu_init();
+#endif
+
return 0;
}
@@ -111,14 +169,36 @@ asmlinkage void __exception_irq_entry armada_370_xp_handle_irq(struct pt_regs
ARMADA_370_XP_CPU_INTACK_OFFS);
irqnr = irqstat & 0x3FF;
- if (irqnr < 1023) {
- irqnr =
- irq_find_mapping(armada_370_xp_mpic_domain, irqnr);
+ if (irqnr > 1022)
+ break;
+
+ if (irqnr >= 8) {
+ irqnr = irq_find_mapping(armada_370_xp_mpic_domain,
+ irqnr);
handle_IRQ(irqnr, regs);
continue;
}
+#ifdef CONFIG_SMP
+ /* IPI Handling */
+ if (irqnr == 0) {
+ u32 ipimask, ipinr;
+
+ ipimask = readl_relaxed(per_cpu_int_base +
+ ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS)
+ & 0xFF;
+
+ writel(0x0, per_cpu_int_base +
+ ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS);
+
+ /* Handle all pending doorbells */
+ for (ipinr = 0; ipinr < ACTIVE_DOORBELLS; ipinr++) {
+ if (ipimask & (0x1 << ipinr))
+ handle_IPI(ipinr, regs);
+ }
+ continue;
+ }
+#endif
- break;
} while (1);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/5] arm: mm: Added support for PJ4B cpu and init routines
From: Gregory CLEMENT @ 2012-10-22 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350925368-24243-1-git-send-email-gregory.clement@free-electrons.com>
From: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/mach-mvebu/Kconfig | 2 +-
arch/arm/mm/Kconfig | 4 ++++
arch/arm/mm/proc-v7.S | 43 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 17d246b..9bfaa0c 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -22,7 +22,7 @@ config MVEBU_CLK_CPU
config MACH_ARMADA_370_XP
bool
select ARMADA_370_XP_TIMER
- select CPU_V7
+ select CPU_PJ4B
config MACH_ARMADA_370
bool "Marvell Armada 370 boards"
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 94186b6..3fd629d 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -352,6 +352,10 @@ config CPU_PJ4
select ARM_THUMBEE
select CPU_V7
+config CPU_PJ4B
+ bool
+ select CPU_V7
+
# ARMv6
config CPU_V6
bool "Support ARM V6 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 846d279..1a373c2 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -169,6 +169,39 @@ __v7_ca15mp_setup:
orreq r0, r0, r10 @ Enable CPU-specific SMP bits
mcreq p15, 0, r0, c1, c0, 1
#endif
+
+__v7_pj4b_setup:
+#ifdef CONFIG_CPU_PJ4B
+ /* Auxiliary Debug Modes Control 1 Register */
+ mrc p15, 1, r0, c15, c1, 1
+ orr r0, r0, #(1 << 16) @ Disable data transfer for clean line.
+ orr r0, r0, #(1 << 5) @ Enable the back off of STREX instr
+ orr r0, r0, #(1 << 8) @ Disable Internal Parity Handling
+ bic r0, r0, #(1 << 2) @ Disable Static BP
+ mcr p15, 1, r0, c15, c1, 1
+
+ /* Auxiliary Debug Modes Control 2 Register */
+ mrc p15, 1, r0, c15, c1, 2
+ bic r0, r0, #(1 << 23) @ Enable fast LDR.
+ orr r0, r0, #(1 << 25) @ Dont interleave write and snoop data.
+ orr r0, r0, #(1 << 27) @ Disable Critical Word First feature.
+ orr r0, r0, #(1 << 29) @ Disable outstanding non cacheable request
+ orr r0, r0, #(1 << 30) @ L1 replacement - Strict round robin
+ mcr p15, 1, r0, c15, c1, 2
+
+ /* Auxiliary Functional Modes Control Register 0 */
+ mrc p15, 1, r0, c15, c2, 0
+ orr r0, r0, #(1 << 2) @ Support L1 parity checking
+ orr r0, r0, #(1 << 8) @ Broadcast Cache and TLB maintenance
+ mcr p15, 1, r0, c15, c2, 0
+
+ /* Auxiliary Debug Modes Control 0 Register */
+ mrc p15, 1, r0, c15, c1, 0
+ orr r0, r0, #(1 << 22) @ WFI/WFE - serve the DVM and back to idle
+ mcr p15, 1, r0, c15, c1, 0
+
+#endif /* CONFIG_CPU_PJ4B */
+
__v7_setup:
adr r12, __v7_setup_stack @ the local stack
stmia r12, {r0-r5, r7, r9, r11, lr}
@@ -342,6 +375,16 @@ __v7_ca9mp_proc_info:
.long 0xff0ffff0
__v7_proc __v7_ca9mp_setup
.size __v7_ca9mp_proc_info, . - __v7_ca9mp_proc_info
+
+ /*
+ * Marvell PJ4B processor.
+ */
+ .type __v7_pj4b_proc_info, #object
+__v7_pj4b_proc_info:
+ .long 0x562f5842
+ .long 0xffffffff
+ __v7_proc __v7_pj4b_setup
+ .size __v7_pj4b_proc_info, . - __v7_pj4b_proc_info
#endif /* CONFIG_ARM_LPAE */
/*
--
1.7.9.5
^ permalink raw reply related
* [PATCH 5/5] arm: mvebu: Added SMP support for Armada XP
From: Gregory CLEMENT @ 2012-10-22 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350925368-24243-1-git-send-email-gregory.clement@free-electrons.com>
From: Yehuda Yitschak <yehuday@marvell.com>
1. added smp init functions in platsmp.c
2. added secondary cpu entry point in headsmp.S
3. added hotplog initial support in hotplug.c
4. added SMP support for PJ4B cpu
Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-xp.dtsi | 4 ++
arch/arm/configs/mvebu_defconfig | 3 +
arch/arm/mach-mvebu/Kconfig | 1 +
arch/arm/mach-mvebu/Makefile | 2 +
arch/arm/mach-mvebu/armada-370-xp.c | 1 +
arch/arm/mach-mvebu/common.h | 3 +
arch/arm/mach-mvebu/headsmp.S | 65 ++++++++++++++++++
arch/arm/mach-mvebu/hotplug.c | 30 +++++++++
arch/arm/mach-mvebu/platsmp.c | 123 +++++++++++++++++++++++++++++++++++
arch/arm/mm/proc-v7.S | 3 +
10 files changed, 235 insertions(+)
create mode 100644 arch/arm/mach-mvebu/headsmp.S
create mode 100644 arch/arm/mach-mvebu/hotplug.c
create mode 100644 arch/arm/mach-mvebu/platsmp.c
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 531619f..7f968dc 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -38,24 +38,28 @@
#size-cells = <0>;
cpu at 0 {
+ device_type = "cpu";
compatible = "marvell,sheeva-v7";
reg = <0>;
clocks = <&cpuclk 0>;
};
cpu at 1 {
+ device_type = "cpu";
compatible = "marvell,sheeva-v7";
reg = <1>;
clocks = <&cpuclk 1>;
};
cpu at 2 {
+ device_type = "cpu";
compatible = "marvell,sheeva-v7";
reg = <2>;
clocks = <&cpuclk 2>;
};
cpu at 3 {
+ device_type = "cpu";
compatible = "marvell,sheeva-v7";
reg = <3>;
clocks = <&cpuclk 3>;
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 7bcf850..c0590c6 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -10,6 +10,9 @@ CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_ARCH_MVEBU=y
CONFIG_MACH_ARMADA_370_XP=y
+# CONFIG_SWP_EMULATE is not set
+CONFIG_SMP=y
+# CONFIG_LOCAL_TIMERS is not set
CONFIG_AEABI=y
CONFIG_HIGHMEM=y
CONFIG_USE_OF=y
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 9bfaa0c..d70afe3 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -22,6 +22,7 @@ config MVEBU_CLK_CPU
config MACH_ARMADA_370_XP
bool
select ARMADA_370_XP_TIMER
+ select HAVE_SMP
select CPU_PJ4B
config MACH_ARMADA_370
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 8e6e50b..eb3cbd1 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -3,3 +3,5 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
obj-y += system-controller.o
obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o coherency.o pmsu.o
+obj-$(CONFIG_SMP) += platsmp.o headsmp.o
+obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 2af6ce5..41431a1 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -59,6 +59,7 @@ static const char * const armada_370_xp_dt_board_dt_compat[] = {
};
DT_MACHINE_START(ARMADA_XP_DT, "Marvell Aramada 370/XP (Device Tree)")
+ .smp = smp_ops(armada_xp_smp_ops),
.init_machine = armada_370_xp_dt_init,
.map_io = armada_370_xp_map_io,
.init_irq = armada_370_xp_init_irq,
diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
index 74ee0b2..86484bb 100644
--- a/arch/arm/mach-mvebu/common.h
+++ b/arch/arm/mach-mvebu/common.h
@@ -21,7 +21,10 @@ void mvebu_clocks_init(void);
void armada_370_xp_init_irq(void);
void armada_370_xp_handle_irq(struct pt_regs *regs);
+void armada_xp_cpu_die(unsigned int cpu);
int armada_370_xp_coherency_init(void);
int armada_370_xp_pmsu_init(void);
+void armada_xp_secondary_startup(void);
+extern struct smp_operations armada_xp_smp_ops;
#endif
diff --git a/arch/arm/mach-mvebu/headsmp.S b/arch/arm/mach-mvebu/headsmp.S
new file mode 100644
index 0000000..13187f8
--- /dev/null
+++ b/arch/arm/mach-mvebu/headsmp.S
@@ -0,0 +1,65 @@
+/*
+ * SMP support: Entry point for secondary CPUs
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Yehuda Yitschak <yehuday@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.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.
+ *
+ * This file implements the assembly entry point for secondary CPUs
+ * in an SMP kernel. The only thing we need to do is to add the CPU
+ * to the coherency fabric by writing to 2 registers. Currently these
+ * register addresses are hard coded due to the early initialisation problems.
+ */
+
+#include <linux/linkage.h>
+#include <linux/init.h>
+
+/*
+ * At this stage the secondary CPUs don't have acces yet to the MMU, so
+ * we have to provide physical addresses
+ */
+#define ARMADA_XP_COHERENCY_FABRIC_CTL_REG 0xD0020200
+#define ARMADA_XP_COHERENCY_FABRIC_CFG_REG 0xD0020204
+
+ __INIT
+
+/*
+ * Armada XP specific entry point for secondary CPUs.
+ * We add the CPU to the coherency fabric and then jump to secondary startup
+ */
+
+ENTRY(armada_xp_secondary_startup)
+
+ /* Read CPU id */
+ mrc p15, 0, r1, c0, c0, 5
+ and r1, r1, #0xF
+
+ /* Add CPU to coherency fabric */
+
+ /* Create bit by cpu index */
+ mov r2,r1
+ add r2,r2,#24
+ MOV r3, #1
+ lsl r3, r3, r2
+
+ /* Add CPU to SMP group - Atomic */
+ ldr r0, = ARMADA_XP_COHERENCY_FABRIC_CTL_REG
+ ldr r10, [r0]
+ orr r10 , r10, r3
+ str r10,[r0]
+
+ /* Enable coherency on CPU - Atomic*/
+ ldr r0, = ARMADA_XP_COHERENCY_FABRIC_CFG_REG
+ ldr r10, [r0]
+ orr r10 , r10, r3
+ str r10,[r0]
+
+ b secondary_startup
+
+ENDPROC(armada_xp_secondary_startup)
diff --git a/arch/arm/mach-mvebu/hotplug.c b/arch/arm/mach-mvebu/hotplug.c
new file mode 100644
index 0000000..b228b6a
--- /dev/null
+++ b/arch/arm/mach-mvebu/hotplug.c
@@ -0,0 +1,30 @@
+/*
+ * Symmetric Multi Processing (SMP) support for Armada XP
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.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/kernel.h>
+#include <linux/errno.h>
+#include <linux/smp.h>
+#include <asm/proc-fns.h>
+
+/*
+ * platform-specific code to shutdown a CPU
+ *
+ * Called with IRQs disabled
+ */
+void __ref armada_xp_cpu_die(unsigned int cpu)
+{
+ cpu_do_idle();
+
+ /* We should never return from idle */
+ panic("mvebu: cpu %d unexpectedly exit from shutdown\n", cpu);
+}
diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
new file mode 100644
index 0000000..ef278a2
--- /dev/null
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -0,0 +1,123 @@
+/*
+ * Symmetric Multi Processing (SMP) support for Armada XP
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Yehuda Yitschak <yehuday@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.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.
+ *
+ * The Armada XP SoC has 4 ARMv7 PJ4B CPUs running in full HW coherency
+ * This file implements the routines for preparing the SMP infrastructure
+ * and waking up the secondary CPUs
+ */
+
+#include <linux/init.h>
+#include <linux/smp.h>
+#include <linux/clk.h>
+#include <linux/of.h>
+#include <asm/cacheflush.h>
+#include <asm/smp_plat.h>
+#include "common.h"
+#include "armada-370-xp.h"
+#include "pmsu.h"
+#include "coherency.h"
+
+void __init set_secondary_cpus_clock(void)
+{
+ int cpu;
+ unsigned long rate;
+ struct clk *cpu_clk = NULL;
+ struct device_node *np = NULL;
+
+ cpu = smp_processor_id();
+ np = of_find_node_by_type(np, "cpu");
+ np = NULL;
+ while ((np = of_find_node_by_type(np, "cpu"))) {
+ const u32 *reg;
+ int len;
+ reg = of_get_property(np, "reg", &len);
+ if (!reg || len != 4) {
+ pr_err("%s missing reg property\n", np->full_name);
+ continue;
+ }
+ if (be32_to_cpup(reg) == cpu) {
+ cpu_clk = of_clk_get(np, 0);
+ break;
+ }
+ }
+ WARN_ON(IS_ERR(cpu_clk));
+ rate = clk_get_rate(cpu_clk);
+
+ /* set all the other CPU clk to the same rate than the boot CPU */
+ np = NULL;
+ while ((np = of_find_node_by_type(np, "cpu"))) {
+ const u32 *reg;
+ int len;
+ reg = of_get_property(np, "reg", &len);
+ if (!reg || len != 4) {
+ pr_err("%s missing reg property\n", np->full_name);
+ continue;
+ }
+ if (be32_to_cpup(reg) != cpu) {
+ cpu_clk = of_clk_get(np, 0);
+ clk_set_rate(cpu_clk, rate);
+ }
+ }
+}
+
+static void __cpuinit armada_xp_secondary_init(unsigned int cpu)
+{
+ armada_xp_mpic_smp_cpu_init();
+}
+
+static int __cpuinit armada_xp_boot_secondary(unsigned int cpu,
+ struct task_struct *idle)
+{
+ pr_info("Booting CPU %d\n", cpu);
+
+ armada_xp_boot_cpu(cpu, armada_xp_secondary_startup);
+
+ return 0;
+}
+
+static void __init armada_xp_smp_init_cpus(void)
+{
+ unsigned int i, ncores;
+ ncores = armada_xp_get_cpu_count();
+
+ /* Limit possbile CPUs to defconfig */
+ if (ncores > nr_cpu_ids) {
+ pr_warn("SMP: %d CPUs physically present. Only %d configured.",
+ ncores, nr_cpu_ids);
+ pr_warn("Clipping CPU count to %d\n", nr_cpu_ids);
+ ncores = nr_cpu_ids;
+ }
+
+ for (i = 0; i < ncores; i++)
+ set_cpu_possible(i, true);
+
+ set_smp_cross_call(armada_mpic_send_doorbell);
+}
+
+void __init armada_xp_smp_prepare_cpus(unsigned int max_cpus)
+{
+ set_secondary_cpus_clock();
+ flush_cache_all();
+ armada_370_xp_set_cpu_coherent(cpu_logical_map(smp_processor_id()), 0);
+}
+
+struct smp_operations armada_xp_smp_ops __initdata = {
+ .smp_init_cpus = armada_xp_smp_init_cpus,
+ .smp_prepare_cpus = armada_xp_smp_prepare_cpus,
+ .smp_secondary_init = armada_xp_secondary_init,
+ .smp_boot_secondary = armada_xp_boot_secondary,
+#ifdef CONFIG_HOTPLUG_CPU
+ .cpu_die = armada_xp_cpu_die,
+#endif
+};
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 1a373c2..4add2c4 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -191,6 +191,9 @@ __v7_pj4b_setup:
/* Auxiliary Functional Modes Control Register 0 */
mrc p15, 1, r0, c15, c2, 0
+#ifdef CONFIG_SMP
+ orr r0, r0, #(1 << 1) @ Set SMP mode. Join the coherncy fabric
+#endif
orr r0, r0, #(1 << 2) @ Support L1 parity checking
orr r0, r0, #(1 << 8) @ Broadcast Cache and TLB maintenance
mcr p15, 1, r0, c15, c2, 0
--
1.7.9.5
^ permalink raw reply related
* [PATCH] arm: sched: stop sched_clock() during suspend
From: Kevin Hilman @ 2012-10-22 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350906877-19410-1-git-send-email-balbi@ti.com>
+Colin Cross, Barry Song also
Felipe Balbi <balbi@ti.com> writes:
> The scheduler imposes a requirement to sched_clock()
> which is to stop the clock during suspend, if we don't
> do that IRQ threads will be rescheduled in the future
> which might cause transfers to timeout depending on
> how driver is written.
It's not just about IRQ threads, it's about RT throttling. IOW, not
just IRQ threads will be postponed, but all RT tasks will be throttled
temporarily as well.
The changelog should also mention that this has an inconvenient side
effect of stopping the printk times during suspend. Based on the
original thread where this feature was discussed and introduced, some
platforms wanted to opt out of this behavior[1], so the optional API was
added.
However, in light of RT throttling, this a correctness issue for process
accounting, so I agree that this should be done for all platforms
instead of providing an optional 'needs suspend' version of the API,
even though it means printk times no longer reflect time spent
suspended.
After a discussion with peterz on this topic, it seems that x86
already ensures that sched_clock stops during suspend for similar
reasons[2].
The question then is whether this is a fix that belongs in v3.7.
Technically, it is not a regression, so I think this should probably be
v3.8 material. If that's the decision, then the threaded IRQ support
for the OMAP I2C driver needs to be reverted for v3.7 until this fix is merged.
Kevin
[1] http://marc.info/?l=linux-arm-kernel&m=134307004508708&w=2
[2] http://marc.info/?l=linux-arm-kernel&m=135065529907297&w=2
^ permalink raw reply
* [PATCH 0/7] ARM: OMAP: second set of PRM/CM/CGRM cleanup patches for 3.8
From: Paul Walmsley @ 2012-10-22 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5085389F.6070106@ti.com>
On Mon, 22 Oct 2012, Benoit Cousson wrote:
> What is CGRM? Is it a typo?
That's the OMAP1 Clock Generation and Reset Module that contains the
ARM_SYSST register:
http://www.ti.com/lit/ug/spru678a/spru678a.pdf
- Paul
^ permalink raw reply
* [PATCH 08/10] pinctrl: single: support pinconf generic
From: Tony Lindgren @ 2012-10-22 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAN1soZzE_tTkmPBechvUcdAbWKSScwcaqe_cb0TTmnRJi9gtRg@mail.gmail.com>
* Haojian Zhuang <haojian.zhuang@gmail.com> [121022 03:11]:
> On Sat, Oct 20, 2012 at 3:13 AM, Tony Lindgren <tony@atomide.com> wrote:
> > * Haojian Zhuang <haojian.zhuang@gmail.com> [121018 02:08]:
> >> Add pinconf generic support with POWER SOURCE, BIAS PULL.
> > ...
> >
> >> + case PIN_CONFIG_POWER_SOURCE:
> >> + if (pcs->psmask == PCS_OFF_DISABLED
> >> + || pcs->psshift == PCS_OFF_DISABLED)
> >> + return -ENOTSUPP;
> >> + data &= pcs->psmask;
> >> + data = data >> pcs->psshift;
> >> + *config = data;
> >> + return 0;
> >> + break;
> >
> > Hmm, only slightly related to this patch, mostly a generic
> > question to others: Do others have any mux registers with
> > status bits for things like PIN_CONFIG_POWER_SOURCE?
> >
> > I could use PIN_CONFIG_POWER_SOURCE for controlling the PBIAS
> > for omap MMC. But there's also a status bit that needs to be
> > checked for that. I think there was some other similar mux
> > register for USB PHY that has a status register.
> >
> > So I'm wondering should the checking for status bit be handled
> > in the pinctrl consume driver? Or should we have some bindings
> > for that?
> >
>
> Do you mean that the status register only exists in USB PHY controller or
> MMC controller?
The status register is in the MMC PBIAS register that is mux
related otherwise. From OMAP4470_ES1.0_PUBLIC_TRM_vE.pdf,
Table 19-599. CONTROL_PBIASLITE:
Bits
26 MMC1_PWDNZ
25 MMC1_PBIASLITE_HIZ_MODE
24 MMC1_PBIASLITE_SUPPLY_HI_OUT
23 MMC1_PBIASLITE_VMODE_ERROR then this bit needs to clear..
22 MMC1_PBIASLITE_PWRDNZ
21 MMC1_PBIASLITE_VMODE ..after VMODE bit is set to 3V
> If so, could we use regulator framework in USB PHY or MMC driver?
Yes we could use regulator framework for that that. Or just read the
status in the MMC driver for that bit if nobody else has mixed
mux-regulator needs like this.
The sequence is MMC specific, so from that point of view it would
make sense to have the logic in the MMC driver.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: dt: tegra: ventana: define pinmux for ddc
From: Stephen Warren @ 2012-10-22 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5084F5D1.7050005@nvidia.com>
On 10/22/2012 01:29 AM, Mark Zhang wrote:
> On 10/19/2012 11:48 PM, Stephen Warren wrote:
>> On 10/18/2012 11:58 PM, Mark Zhang wrote:
>>> Define pinmux for DDC. The DDC pinmux in Ventana is 2 pins in I2C2.
>>
>>> +++ b/arch/arm/boot/dts/tegra20-ventana.dts
>>
>>> - ddc {
>>> - nvidia,pins = "ddc", "owc", "spdi", "spdo",
>>> - "uac";
>>> - nvidia,function = "rsvd2";
>>> - };
>>
>> So that removes the entries for 5 pin groups, yet below, entries are
>> only added for the ddc and pta pingroups, so the other 4 pin groups
>> become unconfigured.
>>
>
> Right. So I think it should be changed to:
>
> owc {
> nvidia,pins = "owc", "spdi", "spdo", "uac";
> nvidia,function = "rsvd2";
> };
>
> Is this right?
Looks correct, yes.
>>> +
>>> + state_i2cmux_ddc: pinmux_i2cmux_ddc {
>>> + ddc {
>>> + nvidia,pins = "ddc";
>>> + nvidia,function = "i2c2";
>>> + };
>>> + pta {
>>> + nvidia,pins = "pta";
>>> + nvidia,function = "rsvd4";
>>> + };
>>
>> Does this actually work? The pta pingroup is configured by the "hog"
>> pinctrl state of the pinctrl node itself, so this state should fail to
>> be applied since it attempts to touch the same pingroup.
>
> I know little about kernel pinctrl subsystem. After reading some docs
> and codes, I think what you mean is, in Ventana's pinmux configuration,
> pta pingroup has been defined as "hdmi" function and this can't be
> changed(non-dynamic pinmuxing).
> So I want to know why we have defined pta pingroup as hdmi function?
> Can we remove this definition to make the i2cmux above working?
I don't recall why pta was defined to be HDMI. The issue isn't that this
patch changes the pinmux selection for the pta pingroup, but simply that
both the pinctrl node's state definition, and the new I2C mux node's
state definition both attempt to configure pingroup pta. The solution is
most likely to simply remove the pta configuration from the main pinctrl
node.
^ permalink raw reply
* OMAP baseline test results for v3.7-rc2
From: Paul Walmsley @ 2012-10-22 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50856FEB.30900@ti.com>
Hi Jon
On Mon, 22 Oct 2012, Jon Hunter wrote:
> On 10/20/2012 04:26 PM, Paul Walmsley wrote:
>
> ...
>
> > Other:
> >
> > * 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
> > - Unknown cause; could be due to the lack of hierarchical enable/disable
> > in hwmod code
>
> I am not seeing this on my omap4430 panda. I have an OMAP4430 ES2.3 and
> I am using u-boot release 2012.10. What do you have?
It's documented in the bootlog:
http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/boot/4430es2panda/4430es2panda_log.txt
It's "U-Boot 2012.07-00136-g755de79 (Aug 24 2012 - 14:19:44)" on an
OMAP4430 ES2.0.
- Paul
^ permalink raw reply
* OMAP baseline test results for v3.7-rc2
From: Paul Walmsley @ 2012-10-22 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210221716000.13464@utopia.booyaka.com>
On Mon, 22 Oct 2012, Paul Walmsley wrote:
> On Mon, 22 Oct 2012, Jon Hunter wrote:
>
> > I am not seeing this on my omap4430 panda. I have an OMAP4430 ES2.3 and
> > I am using u-boot release 2012.10. What do you have?
>
> It's documented in the bootlog:
>
> http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/boot/4430es2panda/4430es2panda_log.txt
>
> It's "U-Boot 2012.07-00136-g755de79 (Aug 24 2012 - 14:19:44)" on an
> OMAP4430 ES2.0.
By the way, would be happy to send a copy of the bootloader/MLO if you'd
like it.
- Paul
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Kevin Hilman @ 2012-10-22 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121019193847.GJ1613@blackmetal.musicnaut.iki.fi>
Aaro Koskinen <aaro.koskinen@iki.fi> writes:
> Hi,
>
> On Fri, Oct 19, 2012 at 10:01:36PM +0300, Felipe Balbi wrote:
>> On Fri, Oct 19, 2012 at 10:03:58PM +0300, Aaro Koskinen wrote:
>> > FYI, I saw I2C hangs also on Nokia N900 with v3.7-rc1 (omap_i2c
>> > omap_i2c.1: timeout waiting for bus ready). After several reboots they
>> > disappered (kernel binary was the same), and I have been unable to
>> > reproduce them since.
>>
>> any change you have those logs saved somewhere ? Want to see if it's the
>> same problem triggered by RTC.
>
> I did not save the logs, but now I tried again, I managed to reproduce
> it after couple boots. The log is below, and after that the there's also
> one from OK boot for comparison.
>
> In the error case, the boot never reaches userspace, just silently hangs
> (or maybe I just didn't wait enough long).
Can you try to revert the threaded IRQ conversion to see if things get
to working again? commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde
Thanks,
Kevin
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Jean Pihet @ 2012-10-22 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAORVsuUkU3iTTFcXfYJ=_FntjiTR33Gs4z9OsNEn2Cxq7Ef-qA@mail.gmail.com>
On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
> Hi,
>
> On Sat, Oct 20, 2012 at 8:14 AM, Paul Walmsley <paul@pwsan.com> wrote:
>> Hi Jean
>>
>> On Fri, 19 Oct 2012, Paul Walmsley wrote:
>>
>>> On Thu, 18 Oct 2012, Paul Walmsley wrote:
>>>
>>> > Here are some basic OMAP test results for Linux v3.7-rc1.
>>> > Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/
>>
>> ...
>>
>>> > Failing tests: needing investigation
>>> > ------------------------------------
>>> >
>>> > Boot tests:
>>>
>>> * 3530ES3 Beagle: I2C timeouts during userspace init
>>> - May be related to the threaded IRQ conversion of the I2C driver
>>> - Unknown cause
>>
>> This one turned out to be caused by:
>>
>> commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc
>> Author: Jean Pihet <jean.pihet@newoldbits.com>
>> Date: Thu Sep 20 18:08:03 2012 +0200
>>
>> ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints
>>
>>
>> Reverting this commit causes the problem to go away, but since the OMAP PM
>> constraint code was removed as well, it's unlikely that a simple revert is
>> the right thing to do.
>>
>> Jean could you please investigate and fix this?
> I tried the latest l-o with omap2plus defconfig on my Beagleboard B5
> (ES2.1) and could not reproduce the problem.
> I do not have the I2C error messages at boot, nor at user space start
> up. I tried to read/write the TWL RTC, successfully.
>
> Another difference is the bootloader images. I have the following:
> - Texas Instruments X-Loader 1.4.2 (Feb 3 2009 - 15:34:17)
> - U-Boot 2009.01-dirty (Feb 19 2009 - 12:22:31)
> Could you send your bootloader images?
>
> I noticed you have I2C error messages in U-Boot, could that be the
> cause of the I2C lock-up?
>
> On the PM QoS side the commit 3db11fef moves the I2C code from the
> OMAP PM no-op layer to the PM QoS for CPU and DMA latency, which
> influences the cpuidle states. However CPU_IDLE is not set in
> omap2plus_defconfig so there should not be any effect.
> Do you have CPU_IDLE enabled?
FYI the issue is not present with CPU_IDLE enabled.
Regards,
Jean
>
>>
>>
>> - Paul
>
> Regards,
> Jean
^ permalink raw reply
* [PATCH 0/7] ARM: OMAP: second set of PRM/CM/CGRM cleanup patches for 3.8
From: Benoit Cousson @ 2012-10-22 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210221641310.13464@utopia.booyaka.com>
On 10/22/2012 07:06 PM, Paul Walmsley wrote:
> On Mon, 22 Oct 2012, Benoit Cousson wrote:
>
>> What is CGRM? Is it a typo?
>
> That's the OMAP1 Clock Generation and Reset Module that contains the
> ARM_SYSST register:
Outch, that's pretty old stuff. Thanks for the clarification.
Regards,
Benoit
^ permalink raw reply
* [PATCH 3/5] arm: mvebu: Added IPI support via doorbells
From: Andrew Lunn @ 2012-10-22 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350925368-24243-4-git-send-email-gregory.clement@free-electrons.com>
On Mon, Oct 22, 2012 at 07:02:45PM +0200, Gregory CLEMENT wrote:
> From: Yehuda Yitschak <yehuday@marvell.com>
>
> Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> arch/arm/boot/dts/armada-xp.dtsi | 2 +-
> arch/arm/mach-mvebu/armada-370-xp.h | 10 ++++
> arch/arm/mach-mvebu/irq-armada-370-xp.c | 92 +++++++++++++++++++++++++++++--
> 3 files changed, 97 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
> index f521ed8..531619f 100644
> --- a/arch/arm/boot/dts/armada-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-xp.dtsi
> @@ -24,7 +24,7 @@
>
> mpic: interrupt-controller at d0020000 {
> reg = <0xd0020a00 0x1d0>,
> - <0xd0021870 0x58>;
> + <0xd0021070 0x58>;
> };
Hi Gregory
Is this a bug fix needed for 3.7?
Andrew
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Alan Stern @ 2012-10-22 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50856F41.7000205@wwwdotorg.org>
On Mon, 22 Oct 2012, Stephen Warren wrote:
> On 10/20/2012 04:10 PM, Tony Prisk wrote:
> > Add a binding document for ehci-platform driver.
> > +Optional properties:
> > +- caps-offset : offset to the capabilities register (default = 0)
> > +- has-tt : controller has transaction translator(s).
> > +- has-synopsys-hc-bug : controller has the synopsys hc bug
>
> That would normally be determined by the driver based on the particular
> compatible value that is in device tree.
I don't understand this comment. Isn't "has-synopsys-hc-bug" the
compatible value in question?
> > +- big-endian : descriptors and registers are both big endian. This
> > + is the equivalent of specifying big-endian-desc and big-endian-regs.
> > +OR
> > +- big-endian-desc : descriptors are in big-endian format
> > +- big-endian-regs : mmio is in big-endian format
>
> Hmmm. That looks odd. Presumably if those properties aren't specified,
> the default is little-endian? Shouldn't this be a tri-state: big,
> little, native, with default native? I don't know what the EHCI
> specification mandates here (and if it does mandate something, the
> default should match the specification). Isn't this something that
> readl/writel would take care of, or are there cases where the register
> endianness of just this one HW block mismatches all other HW blocks?
The EHCI spec assumes a PCI implementation; it doesn't consider other
sorts. And it doesn't say anything about the endianness of multi-byte
descriptors in memory.
Yes, there are cases where one HW block has an endianness that doesn't
match other HW blocks. Or to be more accurate, it doesn't match what
the other HW blocks expect. For example, on ARM readl and writel
expect to do byte-swapping but some particular EHCI blocks don't need
it.
Alan Stern
^ permalink raw reply
* [PATCH V4] ARM: implement debug_ll_io_init()
From: Stephen Warren @ 2012-10-22 17:42 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <robherring2@gmail.com>
When using DEBUG_LL, the UART's (or other HW's) registers are mapped
into early page tables based on the results of assembly macro addruart.
Later, when the page tables are replaced, the same virtual address must
remain valid. Historically, this has been ensured by using defines from
<mach/iomap.h> in both the implementation of addruart, and the machine's
.map_io() function. However, with the move to single zImage, we wish to
remove <mach/iomap.h>. To enable this, the macro addruart may be used
when constructing the late page tables too; addruart is exposed as a
C function debug_ll_addr(), and used to set up the required mapping in
debug_ll_io_init(), which may called on an opt-in basis from a machine's
.map_io() function.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
[swarren: Mask map.virtual with PAGE_MASK. Checked for NULL results from
debug_ll_addr (e.g. when selected UART isn't valid). Fixed compile when
either !CONFIG_DEBUG_LL or CONFIG_DEBUG_SEMIHOSTING.]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
This patch is a dependency for the Tegra debug-macro.S rework. I assume it
should go into some arm-soc branch so that if others want to take advantage
of it this kernel cycle, they can.
v4: Fix DEBUG_SEMIHOSTING's debug_ll_addr to actually fill in the "out"
parameters.
v3: New patch.
---
arch/arm/include/asm/mach/map.h | 7 +++++++
arch/arm/kernel/debug.S | 14 ++++++++++++++
arch/arm/mm/mmu.c | 16 ++++++++++++++++
3 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index 195ac2f..2fe141f 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h
@@ -40,6 +40,13 @@ extern void iotable_init(struct map_desc *, int);
extern void vm_reserve_area_early(unsigned long addr, unsigned long size,
void *caller);
+#ifdef CONFIG_DEBUG_LL
+extern void debug_ll_addr(unsigned long *paddr, unsigned long *vaddr);
+extern void debug_ll_io_init(void);
+#else
+static inline void debug_ll_io_init(void) {}
+#endif
+
struct mem_type;
extern const struct mem_type *get_mem_type(unsigned int type);
/*
diff --git a/arch/arm/kernel/debug.S b/arch/arm/kernel/debug.S
index 66f711b..6809200 100644
--- a/arch/arm/kernel/debug.S
+++ b/arch/arm/kernel/debug.S
@@ -100,6 +100,13 @@ ENTRY(printch)
b 1b
ENDPROC(printch)
+ENTRY(debug_ll_addr)
+ addruart r2, r3, ip
+ str r2, [r0]
+ str r3, [r1]
+ mov pc, lr
+ENDPROC(debug_ll_addr)
+
#else
ENTRY(printascii)
@@ -119,4 +126,11 @@ ENTRY(printch)
mov pc, lr
ENDPROC(printch)
+ENTRY(debug_ll_addr)
+ mov r2, #0
+ str r2, [r0]
+ str r2, [r1]
+ mov pc, lr
+ENDPROC(debug_ll_addr)
+
#endif
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 941dfb9..39719bb 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -876,6 +876,22 @@ static void __init pci_reserve_io(void)
#define pci_reserve_io() do { } while (0)
#endif
+#ifdef CONFIG_DEBUG_LL
+void __init debug_ll_io_init(void)
+{
+ struct map_desc map;
+
+ debug_ll_addr(&map.pfn, &map.virtual);
+ if (!map.pfn || !map.virtual)
+ return;
+ map.pfn = __phys_to_pfn(map.pfn);
+ map.virtual &= PAGE_MASK;
+ map.length = PAGE_SIZE;
+ map.type = MT_DEVICE;
+ create_mapping(&map);
+}
+#endif
+
static void * __initdata vmalloc_min =
(void *)(VMALLOC_END - (240 << 20) - VMALLOC_OFFSET);
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Stephen Warren @ 2012-10-22 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1210221324580.1724-100000@iolanthe.rowland.org>
On 10/22/2012 11:34 AM, Alan Stern wrote:
> On Mon, 22 Oct 2012, Stephen Warren wrote:
>
>> On 10/20/2012 04:10 PM, Tony Prisk wrote:
>>> Add a binding document for ehci-platform driver.
>
>>> +Optional properties:
>>> +- caps-offset : offset to the capabilities register (default = 0)
>>> +- has-tt : controller has transaction translator(s).
>>> +- has-synopsys-hc-bug : controller has the synopsys hc bug
>>
>> That would normally be determined by the driver based on the particular
>> compatible value that is in device tree.
>
> I don't understand this comment. Isn't "has-synopsys-hc-bug" the
> compatible value in question?
"compatible value" in this context means that value of the property
named "compatible".
>>> +- big-endian : descriptors and registers are both big endian. This
>>> + is the equivalent of specifying big-endian-desc and big-endian-regs.
>>> +OR
>>> +- big-endian-desc : descriptors are in big-endian format
>>> +- big-endian-regs : mmio is in big-endian format
>>
>> Hmmm. That looks odd. Presumably if those properties aren't specified,
>> the default is little-endian? Shouldn't this be a tri-state: big,
>> little, native, with default native? I don't know what the EHCI
>> specification mandates here (and if it does mandate something, the
>> default should match the specification). Isn't this something that
>> readl/writel would take care of, or are there cases where the register
>> endianness of just this one HW block mismatches all other HW blocks?
>
> The EHCI spec assumes a PCI implementation; it doesn't consider other
> sorts. And it doesn't say anything about the endianness of multi-byte
> descriptors in memory.
OK, so does this binding default to assuming little-endian (which I
assume matches PCI), unless the big-endian properties are given? Is the
case of little-endian EHCI registers on a big-endian CPU a common enough
thing that adding a third state native-endian wouldn't be useful?
^ permalink raw reply
* [PATCH 2/3] PWM: vt8500: Update vt8500 PWM driver support
From: Tony Prisk @ 2012-10-22 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022150835.GA31704@avionic-0098.mockup.avionic-design.de>
On Mon, 2012-10-22 at 17:08 +0200, Thierry Reding wrote:
> On Mon, Oct 22, 2012 at 01:52:08PM +0000, Arnd Bergmann wrote:
> > On Monday 22 October 2012, Thierry Reding wrote:
> > > > As long as we get build warnings for leaving out the __devinit/__devexit
> > > > annotations, I would generally recommend putting them in. If we do a
> > > > patch to remove all of them, a couple extra instances will not cause
> > > > any more troubles than we already have.
> > >
> > > I've never seen any build warnings for leaving __devinit/__devexit out.
> > > Where does that happen?
> >
> > Section mismatches usually result into warnings from modpost, like
> >
> > WARNING: modpost: Found 1 section mismatch(es).
> > To see full details build your kernel with:
> > 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> >
> > Actually doing that gives you an output like this (currently on exynos_defconfig):
> >
> > $ make CONFIG_DEBUG_SECTION_MISMATCH=y
> > WARNING: drivers/pinctrl/built-in.o(.devinit.text+0x124): Section mismatch in reference from the function samsung_pinctrl_probe() to the function .init.text:samsung_gpiolib_register()
> > The function __devinit samsung_pinctrl_probe() references
> > a function __init samsung_gpiolib_register().
> > If samsung_gpiolib_register is only used by samsung_pinctrl_probe then
> > annotate samsung_gpiolib_register with a matching annotation.
> >
> > or like this (now fixed in socfpga_defconfig):
> >
> > WARNING: drivers/net/ethernet/stmicro/stmmac/stmmac.o(.text+0x5d4c): Section mismatch in reference from the function stmmac_pltfr_probe() to the function .devinit.text:stmmac_probe_config_dt()
> > The function stmmac_pltfr_probe() references
> > the function __devinit stmmac_probe_config_dt().
> > This is often because stmmac_pltfr_probe lacks a __devinit
> > annotation or the annotation of stmmac_probe_config_dt is wrong.
> >
> > I believe you normally don't get warnings for functions that could be
> > marked __devinit and only call regular functions, but there are
> > a couple of __devinit infrastructure functions that you can't call
> > from a function that isn't __init or __devinit.
>
> Right. If you get those warnings you shouldn't be dropping the
> annotations. But I don't think that is the case for this driver. Tony,
> can you confirm that the driver still builds properly without warnings
> if you drop the __devinit/__devexit?
>
> Thierry
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Correct - it builds without warnings without __devinit/__devexit.
If it had introduced warnings when I tested it, I would have mentioned
it :)
Regards
Tony P
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Kevin Hilman @ 2012-10-22 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210200614390.9865@utopia.booyaka.com>
Paul Walmsley <paul@pwsan.com> writes:
> Hi Kevin
>
> On Fri, 19 Oct 2012, Paul Walmsley wrote:
>
>> On Thu, 18 Oct 2012, Paul Walmsley wrote:
>>
>> > Here are some basic OMAP test results for Linux v3.7-rc1.
>> > Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/
>
> ...
>
>> > Failing tests: needing investigation
>> > ------------------------------------
>> >
>
> ...
>
>> > PM tests:
>>
>> * 3730 Beagle XM: OPPs do not initialize
>> - Several "find_device_opp: Invalid parameters" messages appear on boot;
>> related warnings follow
>> - Cause unknown
>
> This one seems to be caused by this commit:
>
> commit 24d7b40a60cf19008334bcbcbd98da374d4d9c64
> Author: Kevin Hilman <khilman@ti.com>
> Date: Thu Sep 6 14:03:08 2012 -0700
>
> ARM: OMAP2+: PM: MPU DVFS: use generic CPU device for MPU-SS
>
> Care to take a look at it and fix it?
>
Yup, will fix. Looks like this exposed some initcall ordering issues in
the Beagle board file when adding OPPs.
Kevin
^ permalink raw reply
* [PATCH v3] pwm: vt8500: Update vt8500 PWM driver support
From: Tony Prisk @ 2012-10-22 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022084000.GB29790@avionic-0098.mockup.avionic-design.de>
This patch updates pwm-vt8500.c to support devicetree probing and
make use of the common clock subsystem.
A binding document describing the PWM controller found on
arch-vt8500 is also included.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
.../devicetree/bindings/pwm/vt8500-pwm.txt | 17 ++++
drivers/pwm/pwm-vt8500.c | 83 ++++++++++++++------
2 files changed, 77 insertions(+), 23 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
diff --git a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
new file mode 100644
index 0000000..bcc6367
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
@@ -0,0 +1,17 @@
+VIA/Wondermedia VT8500/WM8xxx series SoC PWM controller
+
+Required properties:
+- compatible: should be "via,vt8500-pwm"
+- reg: physical base address and length of the controller's registers
+- #pwm-cells: should be 2. The first cell specifies the per-chip index
+ of the PWM to use and the second cell is the period in nanoseconds.
+- clocks: phandle to the PWM source clock
+
+Example:
+
+pwm1: pwm at d8220000 {
+ #pwm-cells = <2>;
+ compatible = "via,vt8500-pwm";
+ reg = <0xd8220000 0x1000>;
+ clocks = <&clkpwm>;
+};
diff --git a/drivers/pwm/pwm-vt8500.c b/drivers/pwm/pwm-vt8500.c
index ad14389..ebbc41c 100644
--- a/drivers/pwm/pwm-vt8500.c
+++ b/drivers/pwm/pwm-vt8500.c
@@ -1,7 +1,8 @@
/*
* drivers/pwm/pwm-vt8500.c
*
- * Copyright (C) 2010 Alexey Charkov <alchark@gmail.com>
+ * Copyright (C) 2012 Tony Prisk <linux@prisktech.co.nz>
+ * Copyright (C) 2010 Alexey Charkov <alchark@gmail.com>
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
@@ -21,14 +22,24 @@
#include <linux/io.h>
#include <linux/pwm.h>
#include <linux/delay.h>
+#include <linux/clk.h>
#include <asm/div64.h>
-#define VT8500_NR_PWMS 4
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_address.h>
+
+/*
+ * SoC architecture allocates register space for 4 PWMs but only
+ * 2 are currently implemented.
+ */
+#define VT8500_NR_PWMS 2
struct vt8500_chip {
struct pwm_chip chip;
void __iomem *base;
+ struct clk *clk;
};
#define to_vt8500_chip(chip) container_of(chip, struct vt8500_chip, chip)
@@ -52,7 +63,7 @@ static int vt8500_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
unsigned long long c;
unsigned long period_cycles, prescale, pv, dc;
- c = 25000000/2; /* wild guess --- need to implement clocks */
+ c = clk_get_rate(vt8500->clk);
c = c * period_ns;
do_div(c, 1000000000);
period_cycles = c;
@@ -87,6 +98,11 @@ static int vt8500_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
{
struct vt8500_chip *vt8500 = to_vt8500_chip(chip);
+ if (!clk_enable(vt8500->clk)) {
+ dev_err(chip->dev, "failed to enable clock\n");
+ return -EBUSY;
+ };
+
pwm_busy_wait(vt8500->base + 0x40 + pwm->hwpwm, (1 << 0));
writel(5, vt8500->base + (pwm->hwpwm << 4));
return 0;
@@ -98,6 +114,8 @@ static void vt8500_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
pwm_busy_wait(vt8500->base + 0x40 + pwm->hwpwm, (1 << 0));
writel(0, vt8500->base + (pwm->hwpwm << 4));
+
+ clk_disable(vt8500->clk);
}
static struct pwm_ops vt8500_pwm_ops = {
@@ -107,12 +125,24 @@ static struct pwm_ops vt8500_pwm_ops = {
.owner = THIS_MODULE,
};
-static int __devinit pwm_probe(struct platform_device *pdev)
+static const struct of_device_id vt8500_pwm_dt_ids[] = {
+ { .compatible = "via,vt8500-pwm", },
+ { /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, vt8500_pwm_dt_ids);
+
+static int vt8500_pwm_probe(struct platform_device *pdev)
{
struct vt8500_chip *chip;
struct resource *r;
+ struct device_node *np = pdev->dev.of_node;
int ret;
+ if (!np) {
+ dev_err(&pdev->dev, "invalid devicetree node\n");
+ return -EINVAL;
+ }
+
chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
if (chip == NULL) {
dev_err(&pdev->dev, "failed to allocate memory\n");
@@ -123,6 +153,12 @@ static int __devinit pwm_probe(struct platform_device *pdev)
chip->chip.ops = &vt8500_pwm_ops;
chip->chip.base = -1;
chip->chip.npwm = VT8500_NR_PWMS;
+ chip->clk = devm_clk_get(&pdev->dev, NULL);
+
+ if (IS_ERR_OR_NULL(chip->clk)) {
+ dev_err(&pdev->dev, "clock source not specified\n");
+ return PTR_ERR(chip->clk);
+ }
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (r == NULL) {
@@ -131,18 +167,25 @@ static int __devinit pwm_probe(struct platform_device *pdev)
}
chip->base = devm_request_and_ioremap(&pdev->dev, r);
- if (chip->base == NULL)
+ if (!chip->base)
return -EADDRNOTAVAIL;
+ if (!clk_prepare(chip->clk)) {
+ dev_err(&pdev->dev, "failed to prepare clock\n");
+ return -EBUSY;
+ }
+
ret = pwmchip_add(&chip->chip);
- if (ret < 0)
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to add pwmchip\n");
return ret;
+ }
platform_set_drvdata(pdev, chip);
return ret;
}
-static int __devexit pwm_remove(struct platform_device *pdev)
+static int vt8500_pwm_remove(struct platform_device *pdev)
{
struct vt8500_chip *chip;
@@ -150,28 +193,22 @@ static int __devexit pwm_remove(struct platform_device *pdev)
if (chip == NULL)
return -ENODEV;
+ clk_unprepare(chip->clk);
+
return pwmchip_remove(&chip->chip);
}
-static struct platform_driver pwm_driver = {
+static struct platform_driver vt8500_pwm_driver = {
+ .probe = vt8500_pwm_probe,
+ .remove = vt8500_pwm_remove,
.driver = {
.name = "vt8500-pwm",
.owner = THIS_MODULE,
+ .of_match_table = vt8500_pwm_dt_ids,
},
- .probe = pwm_probe,
- .remove = __devexit_p(pwm_remove),
};
+module_platform_driver(vt8500_pwm_driver);
-static int __init pwm_init(void)
-{
- return platform_driver_register(&pwm_driver);
-}
-arch_initcall(pwm_init);
-
-static void __exit pwm_exit(void)
-{
- platform_driver_unregister(&pwm_driver);
-}
-module_exit(pwm_exit);
-
-MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("VT8500 PWM Driver");
+MODULE_AUTHOR("Tony Prisk <linux@prisktech.co.nz>");
+MODULE_LICENSE("GPL v2");
--
1.7.9.5
^ permalink raw reply related
* [GIT PULL] Renesas ARM-based SoC defconfig for v3.8
From: Nicolas Pitre @ 2012-10-22 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210221412.19486.arnd@arndb.de>
On Mon, 22 Oct 2012, Arnd Bergmann wrote:
> (adding Nico, who did a lot of the work to get rid of PLAT_PHYS_OFFSET)
>
> On Monday 22 October 2012, Simon Horman wrote:
> > On Mon, Oct 22, 2012 at 09:33:51AM +0900, Simon Horman wrote:
> > > On Fri, Oct 19, 2012 at 08:18:50AM +0000, Arnd Bergmann wrote:
> > > > On Friday 19 October 2012, Simon Horman wrote:
> > > > > * A more significant problem seems to be the use of CONFIG_MEMORY_START
> > > > > to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
> > > > >
> > > > > I'm not sure that I see an easy way to get around this one.
> > > >
> > > > ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?
> >
> > I believe that this leaves mach-shmobile with three areas
> > where CONFIG_MEMORY_START/PLAT_PHYS_OFFSET is used.
>
> Hmm, I just noticed that in fact shmobile is the only remaining
> platform that uses CONFIG_MEMORY_START with a per-board or per-soc
> setting.
>
> > * arch/arm/mach-shmobile/headsmp.S
> >
> > This uses PLAT_PHYS_OFFSET.
> >
> > I believe this can be replaced with a run-time calculation. Though I
> > haven't thought about the details yet.
What about this (untested):
diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
index b202c12725..9293319fcb 100644
--- a/arch/arm/mach-shmobile/headsmp.S
+++ b/arch/arm/mach-shmobile/headsmp.S
@@ -64,18 +64,23 @@ ENTRY(v7_invalidate_l1)
mov pc, lr
ENDPROC(v7_invalidate_l1)
-ENTRY(shmobile_invalidate_start)
+ENTRY(shmobile_secondary_entry)
bl v7_invalidate_l1
b secondary_startup
-ENDPROC(shmobile_invalidate_start)
+ENDPROC(shmobile_secondary_entry)
/*
* Reset vector for secondary CPUs.
* This will be mapped at address 0 by SBAR register.
* We need _long_ jump to the physical address.
+ * the loaded address is initialized to the physical address of
+ * shmobile_secondary_entry
+ * in platform_secondary_init().
*/
+ .data
.align 12
+ .arm
ENTRY(shmobile_secondary_vector)
ldr pc, 1f
-1: .long shmobile_invalidate_start - PAGE_OFFSET + PLAT_PHYS_OFFSET
+1: .long 0
ENDPROC(shmobile_secondary_vector)
diff --git a/arch/arm/mach-shmobile/platsmp.c b/arch/arm/mach-shmobile/platsmp.c
index fde0d23121..356f82da16 100644
--- a/arch/arm/mach-shmobile/platsmp.c
+++ b/arch/arm/mach-shmobile/platsmp.c
@@ -76,8 +76,14 @@ int shmobile_platform_cpu_kill(unsigned int cpu)
void __cpuinit platform_secondary_init(unsigned int cpu)
{
+ long shmobile_secondary_address;
+
trace_hardirqs_off();
+ shmobile_secondary_address = (long *)(shmobile_secondary_vector) + 1;
+ *shmobile_secondary_address = virt_to_phys(shmobile_secondary_entry);
+ __cpuc_flush_dcache_area(shmobile_secondary_address, sizeof(long));
+
if (is_sh73a0())
sh73a0_secondary_init(cpu);
> > * arch/arm/boot/compressed/head-shmobile.S
> >
> > This makes use of CONFIG_MEMORY_START.
> > This is only used if CONFIG_ZBOOT_ROM is set.
> >
> > I'm unsure if this can be replaced with a run-time calculation or not.
> > But regardless it is only used if CONFIG_ZBOOT_ROM is set, which is not
> > the default at this time.
This code is meant to be executed from ROM which means a very tailored
kernel configuration. In that case it makes little sense to have
CONFIG_ARM_PATCH_PHYS_VIRT nor CONFIG_AUTO_ZRELADDR turned on anyway.
> Right, you can probably make CONFIG_ZBOOT_ROM_MMCIF and
> CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI depend on !ARM_PATCH_PHYS_VIRT
The right dependency would be CONFIG_AUTO_ZRELADDR, not
ARM_PATCH_PHYS_VIRT. The later concerns the final kernel image, not the
decompressor.
> > * arch/arm/mach-shmobile/Makefile.boot
> >
> > This makes use of CONFIG_MEMORY_START to set zreladdr.
> >
> > I believe that the solution to this is to make use of CONFIG_AUTO_ZRELADDR.
> > However, it is not yet clear to me how that can be used in conjunction
> > with a uImage. As I understand it the boot loader on many of our boards,
> > including the Marzen board which is my first target for this work, boot
> > uImage imagess.
>
> If this doesn't work, we probably also need to find a solution to
> build multiple uImage files from the same vmlinux when building a
> multiplatform kernel.
The right solution to the U-Boot problem is to remove uImage creation
from the kernel entirely. The U-Boot image format should be created at
_installation_ time, not at build time. The fact that the U-Boot image
format is (or was until very recently) inflexible is not Linux's fault.
If the uImage build target is to remain in the kernel, it should be
marked incompatible with a multi-arch config. There is no point
distributing a multi-arch kernel image when wrapped into a uImage
format.
Nicolas
^ permalink raw reply related
* OMAP baseline test results for v3.7-rc2
From: Paul Walmsley @ 2012-10-22 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50857444.9080308@ti.com>
(including the lists in my reply this time, oops; also adding some more
detail)
On Mon, 22 Oct 2012, Jon Hunter wrote:
> On 10/20/2012 04:26 PM, Paul Walmsley wrote:
>
> > Failing tests: fixed by posted patches
> > --------------------------------------
> >
> > Boot tests:
> >
> > * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
> > - due to a GPMC bug
> > - Apparently fixed by http://www.spinics.net/lists/arm-kernel/msg200787.html
>
> This is now addressed and I have verified it is booting on v3.7-rc2. The
> following patch address this boot problem ...
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8119024ef7363591fd958ec89ebfaee7c18209e3
Great, thanks, will update the README. Did you also enable
CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT, or were you able
to pass the DTB from the bootloader?
> > * 4460pandaes: boot fails early
> > - Appears to be timer-related
>
> I tried v3.7-rc2 on my pandaES and it is booting fine for me.
>
> I have an OMAP4460 ES1.1 and u-boot release 2012.10.
Tony's reporting the same thing so maybe this is a bootloader problem.
Just sent you the bootloader/MLO from my board here, maybe you can give it
a quick test if you have a moment. Probably the kernel is implicitly
assuming that the bootloader has enabled something.
> I don't wish to create more work for you, but it could be good to add
> silicon revision, u-boot release (if applicable)
These can be found by clicking through the link at the top of the message.
In this case:
http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/
Click on 'boot' and '4460pandaes'
> and toolchain used for any failures.
This would indeed be useful and will try to figure out a good way to add
that information.
- Paul
^ permalink raw reply
* OMAP baseline test results for v3.7-rc2
From: Paul Walmsley @ 2012-10-22 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210221829270.13464@utopia.booyaka.com>
On Mon, 22 Oct 2012, Paul Walmsley wrote:
> On Mon, 22 Oct 2012, Jon Hunter wrote:
>
> > and toolchain used for any failures.
>
> This would indeed be useful and will try to figure out a good way to add
> that information.
Just realized that some of this appears in the beginning of the bootlogs:
[ 0.000000] Linux version 3.7.0-rc2-00331-g6f0c058 (paul at nozomi) (gcc
version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Sat Oct 20 14:04:56
MDT 2012
Not the easiest information to find, but maybe it serves your needs?
- Paul
^ 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