Re: [PATCH v3 3/4] ARM: EXYNOS: add Exynos Dual Cluster Support
(time_before(jiffies, timeout)); return -EDEADLK; } But, as i mentioned, this is no good using while here. Now thinking about the problem. Thank you, Tarek Dakhran -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/4] ARM: dts: Add initial device tree support for EXYNOS5410
Hi,
On 10.11.2013 22:02, Tomasz Figa wrote:
Hi,
Please see my comments inline.
On Thursday 07 of November 2013 12:12:49 Vyacheslav Tyrtov wrote:
From: Tarek Dakhran t.dakh...@samsung.com
Add initial device tree nodes for EXYNOS5410 SoC and SMDK5410 board.
Signed-off-by: Tarek Dakhran t.dakh...@samsung.com
Signed-off-by: Vyacheslav Tyrtov v.tyr...@samsung.com
---
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/exynos5410-smdk5410.dts | 65 ++
arch/arm/boot/dts/exynos5410.dtsi | 209 ++
3 files changed, 275 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5410-smdk5410.dts
create mode 100644 arch/arm/boot/dts/exynos5410.dtsi
[snip]
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
new file mode 100644
index 000..06ae479
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -0,0 +1,65 @@
+/*
+ * SAMSUNG SMDK5410 board device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+#include exynos5410.dtsi
+/ {
+ model = Samsung SMDK5410 board based on EXYNOS5410;
+ compatible = samsung,smdk5410, samsung,exynos5410;
+
+ memory {
+ reg = 0x4000 0x8000;
+ };
+
+ chosen {
+ bootargs = console=ttySAC2,115200;
+ };
+
+ oscclk: oscclk {
coding style: According to ePAPR recommendation, node name should
represent hardware type, not particular instance of hardware.
So instead, the preferred way would be to specify the clock using
following layout:
clocks {
compatible = simple-bus;
#address-cells = 1;
#size-cells = 0;
oscclk: clock@0 {
compatible = fixed-clock;
reg = 0;
#clock-cells = 0;
clock-frequency = 2400;
clock-output-names = fin_pll;
};
};
+ compatible = fixed-clock;
+ #clock-cells = 0;
+ clock-frequency = 2400;
+ clock-output-names = fin_pll;
+ };
[snip]
+
+};
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
new file mode 100644
index 000..9921b66
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -0,0 +1,209 @@
+/*
+ * SAMSUNG EXYNOS5410 SoC device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SAMSUNG EXYNOS5410 SoC device nodes are listed in this file.
+ * EXYNOS5410 based board files can include this file and provide
+ * values for board specfic bindings.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include dt-bindings/clock/exynos5410.h
+#include exynos5.dtsi
+/ {
[snip]
+ clock: clock-controller@1001 {
+ compatible = samsung,exynos5410-clock;
+ reg = 0x1001 0x3;
+ #clock-cells = 1;
+ };
+
+ mct@101C {
A generic name would be: timer@101C
+ compatible = samsung,exynos4210-mct;
+ reg = 0x101C 0xB00;
+ interrupt-controller;
+ #interrups-cells = 1;
MCT is not an interrupt controller, so both interrupt-controller and
#interrupt-cells properties are incorrect. I guess that's due to the
broken example in the documentation, that I already posted patches to fix.
+ interrupt-parent = mct_map;
+ interrupts = 0, 1, 2, 3,
+ 4, 5, 6, 7,
+ 8, 9, 10, 11;
+ clocks = oscclk, clock CLK_MCT;
+ clock-names = fin_pll, mct;
+
+ mct_map: mct-map {
Again, interrupt-map would be a better name for this node.
+ #interrupt-cells = 1;
+ #address-cells = 0;
+ #size-cells = 0;
+ interrupt-map = 0 combiner 23 3,
+ 1 combiner 23 4,
+ 2 combiner 25 2,
+ 3 combiner 25 3,
+ 4 gic 0 120 0,
+ 5 gic 0 121 0,
+ 6 gic 0 122 0,
+ 7 gic 0 123 0,
+ 8 gic 0 128 0,
+ 9 gic 0 129 0,
+ 10
Re: [PATCH v3 3/4] ARM: EXYNOS: add Exynos Dual Cluster Support
On 07.11.2013 17:01, Dave Martin wrote:
On Thu, Nov 07, 2013 at 08:12:48AM +, Vyacheslav Tyrtov wrote:
From: Tarek Dakhran t.dakh...@samsung.com
Add EDCS(Exynos Dual Cluster Support) for Samsung Exynos5410 SoC.
This enables all 8 cores, 4 x A7 and 4 x A15 run at the same time.
Signed-off-by: Tarek Dakhran t.dakh...@samsung.com
Signed-off-by: Vyacheslav Tyrtov v.tyr...@samsung.com
---
arch/arm/mach-exynos/Makefile | 2 +
arch/arm/mach-exynos/edcs.c | 278 ++
2 files changed, 280 insertions(+)
create mode 100644 arch/arm/mach-exynos/edcs.c
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 5369615..ba6efdb 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -34,3 +34,5 @@ AFLAGS_exynos-smc.o :=-Wa,-march=armv7-a$(plus_sec)
obj-$(CONFIG_MACH_EXYNOS4_DT) += mach-exynos4-dt.o
obj-$(CONFIG_MACH_EXYNOS5_DT) += mach-exynos5-dt.o
+
+obj-$(CONFIG_SOC_EXYNOS5410) += edcs.o
diff --git a/arch/arm/mach-exynos/edcs.c b/arch/arm/mach-exynos/edcs.c
new file mode 100644
index 000..980bfdd
--- /dev/null
+++ b/arch/arm/mach-exynos/edcs.c
@@ -0,0 +1,278 @@
+/*
+ * arch/arm/mach-exynos/edcs.c - exynos dual cluster power management support
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * Author: Tarek Dakhran t.dakh...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * EDCS(exynos dual cluster support) for Exynos5410 SoC.
+ */
+
+#include linux/init.h
+#include linux/io.h
+#include linux/of_address.h
+#include linux/spinlock.h
+#include linux/errno.h
+#include linux/irqchip/arm-gic.h
+
+#include asm/mcpm.h
+#include asm/proc-fns.h
+#include asm/cacheflush.h
+#include asm/cputype.h
+#include asm/cp15.h
+
+#include linux/arm-cci.h
+#include mach/regs-pmu.h
+
+#define EDCS_CPUS_PER_CLUSTER 4
+#define EDCS_CLUSTERS 2
+
+/* Exynos5410 power management registers */
+#define EDCS_CORE_CONFIGURATION(_nr) (S5P_ARM_CORE0_CONFIGURATION\
+ + ((_nr) * 0x80))
+#define EDCS_CORE_STATUS(_nr) (EDCS_CORE_CONFIGURATION(_nr) + 0x4)
+#define EDCS_CORE_OPTION(_nr) (EDCS_CORE_CONFIGURATION(_nr) + 0x8)
+
+#define REG_CPU_STATE_ADDR0(S5P_VA_SYSRAM_NS + 0x28)
+#define REG_CPU_STATE_ADDR(_nr)(REG_CPU_STATE_ADDR0 + \
+(_nr) * EDCS_CPUS_PER_CLUSTER)
+
+#define SECONDARY_RESET(1 1)
+#define REG_ENTRY_ADDR (S5P_VA_SYSRAM_NS + 0x1c)
+
+static arch_spinlock_t edcs_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+
+static int edcs_use_count[EDCS_CPUS_PER_CLUSTER][EDCS_CLUSTERS];
+static int core_count[EDCS_CLUSTERS];
+
+static void exynos_core_power_control(unsigned int cpu, unsigned int cluster,
+ bool enable)
+{
+ unsigned int offset = cluster * MAX_CPUS_PER_CLUSTER + cpu;
+ int value = enable ? S5P_CORE_LOCAL_PWR_EN : 0;
+
+ if ((readl_relaxed(EDCS_CORE_STATUS(offset)) 0x3) != value) {
I wonder if there is a race here.
If there is a pending powerdown which has reached the __mcpm_cpu_down()
stage, then the kernel has no way to know what is still pending. This
means that when calling exynos_power_up(cpu, cluster) after a successful
call to exynos_power_down(same cpu, cluster), there is a chance that
the CPU still gets powered down, because of the pending
exynos_core_power_control() on the outbound side.
This isn't an issue for TC2, because TC2's power controller queues
requests and services them in order, so a new powerup request cannot
race with a powerdown request in that way.
For exynos5410, it looks like the kernel needs to do that sequencing,
based on my guess about what the EDCS_CORE_STATUS() bits tell us.
I think that for correct behaviour we would need to wait for the race to
be resolved here, but only if a powerdown might be pending.
This implies that something like a call to the power_down_finish()
method (which you would need to write -- see my comments below) is
needed in exynos_core_power_up().
It might make sense to have a per-cpu flag that tracks whether a
powerdown is pending. The flag could be set after
__mcpm_cpu_going_down() is called, and cleared in the powered_up()
method (which you would need to add).
Maybe we should always just poll and wait, though. exynos_power_up()
should never be called for a CPU that the kernel thinks is already up,
so it should either be down already (in which case we will poll the
status once and then continue), or a power down is pending (in which
case we must wait, but we know the wait will terminate). This would
be simpler than tracking a power down pending flag for each CPU.
+ wmb();
+ writel_relaxed(value
Re: [PATCH v3 3/4] ARM: EXYNOS: add Exynos Dual Cluster Support
Hi,
On 11.11.2013 11:58, Tarek Dakhran wrote:
On Thu, Nov 07, 2013 at 11:51:49AM -0500, Nicolas Pitre wrote:
Samsung people: could you give us more info on the behavior of the power
controller please?
Nicolas
This is how the power controller works on exynos5410. For example for
CORE0.
ARM_CORE0_STATUS register indicates the power state of Core 0 part of
processor core.
0x3 indicates that power to Core 0 is turned-on. 0x0 indicates that
power to Core 0 is turned-off.
All other values indicate that the power On/Off sequence of Core 0 in
progress.
To turn Off the power of Core 0 power domain:
1. Set the LOCAL_POWER_CFG field of ARM_CORE0_CONFIGURATION register
to 0x3.
2. After PMU detects a change in the LOCAL_POWER_CFG field, it waits
for the execution of WFI.
3. After Core 0 executes the WFI instruction, PMU starts the
power-down sequence.
4. The Status field of ARM_CORE0_STATUS register indicates the
completion of the sequence.
That's why in the v1 of this patch exynos_core_power_control function
was implemented as:
static int exynos_core_power_control(unsigned int cpu, unsigned int
cluster, int enable)
{
unsigned long timeout = jiffies + msecs_to_jiffies(10);
unsigned int offset = cluster * MAX_CPUS_PER_CLUSTER + cpu;
int value = enable ? S5P_CORE_LOCAL_PWR_EN : 0;
if ((__raw_readl(EXYNOS5410_CORE_STATUS(offset)) 0x3) == value)
return 0;
__raw_writel(value, EXYNOS5410_CORE_CONFIGURATION(offset));
do {
if ((__raw_readl(EXYNOS5410_CORE_STATUS(offset)) 0x3)
== value)
return 0;
} while (time_before(jiffies, timeout));
return -EDEADLK;
}
But, as i mentioned, this is no good using while here.
Now thinking about the problem.
Thank you,
Tarek Dakhran
What do you think about this way of solving the problem with races?
Add new edcs_power_controller_wait function.
static void edcs_power_controller_wait(unsigned int cpu, unsigned int
cluster){
unsigned long timeout = jiffies + msecs_to_jiffies(10);
unsigned int offset = cluster * EDCS_CPUS_PER_CLUSTER + cpu;
void __iomem *status_reg = EDCS_CORE_STATUS(offset);
/* wait till core power controller finish the work */
do {
if ((readl_relaxed(status_reg) 3) ==
edcs_use_count[cpu][cluster] ? 3 : 0)
return;
} while (time_before(jiffies, timeout));
/* Should never get here */
BUG();
}
Use it in:
static void exynos_core_power_up(unsigned int cpu, unsigned int cluster)
{
exynos_core_power_control(cpu, cluster, true);
edcs_power_controller_wait(cpu, cluster);
}
and in:
static void exynos_power_down(void)
{
bool last_man = false, skip_wfi = false;
unsigned int mpidr = read_cpuid_mpidr();
unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
pr_debug(%s: CORE%d on CLUSTER %d\n, __func__, cpu, cluster);
BUG_ON(cpu = EDCS_CPUS_PER_CLUSTER || cluster = EDCS_CLUSTERS);
__mcpm_cpu_going_down(cpu, cluster);
arch_spin_lock(edcs_lock);
BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
edcs_use_count[cpu][cluster]--;
if (edcs_use_count[cpu][cluster] == 0) {
exynos_core_power_down(cpu, cluster);
--core_count[cluster];
if (core_count[cluster] == 0)
last_man = true;
[snip]
__mcpm_cpu_down(cpu, cluster);
if (!skip_wfi){
wfi();
}
edcs_power_controller_wait(cpu, cluster);
}
Comments appreciated. Thanks.
Best regards,
Tarek Dakhran.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] clk: exynos5410: register clocks using common clock framework
Hi,
On 01.11.2013 20:58, Tomasz Figa wrote:
Hi,
On Monday 14 of October 2013 19:08:23 Vyacheslav Tyrtov wrote:
From: Tarek Dakhran
The EXYNOS5410 clocks are statically listed and registered
using the Samsung specific common clock helper functions.
Signed-off-by: Tarek Dakhran
Signed-off-by: Vyacheslav Tyrtov
---
.../devicetree/bindings/clock/exynos5410-clock.txt | 37 +++
drivers/clk/samsung/Makefile | 1 +
drivers/clk/samsung/clk-exynos5410.c | 251
+ include/dt-bindings/clock/exynos5410.h
| 175 ++ 4 files changed, 464 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/exynos5410-clock.txt create
mode 100644 drivers/clk/samsung/clk-exynos5410.c
create mode 100644 include/dt-bindings/clock/exynos5410.h
The driver looks pretty good now, thanks for addressing my comments to
previous version. There are still few issues remaining, though. Please see
my comments inline.
[snip]
diff --git a/drivers/clk/samsung/clk-exynos5410.c
b/drivers/clk/samsung/clk-exynos5410.c new file mode 100644
index 000..c5eba08
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos5410.c
[snip]
+static struct of_device_id ext_clk_match[] __initdata = {
+ { .compatible = "samsung,clock-oscclk", .data = (void *)0, },
+ { },
+};
I don't see anything in binding documentation mentioning this compatible
value. Anyway, since there is already a generic binding for fixed rate
clocks, this shouldn't be needed at all.
+
+/* register exynos5410 clocks */
+static void __init exynos5410_clk_init(struct device_node *np)
+{
+ void __iomem *reg_base;
+
+ reg_base = of_iomap(np, 0);
+ if (!reg_base)
+ panic("%s: failed to map registers\n", __func__);
+
+ samsung_clk_init(np, reg_base, CLK_NR_CLKS,
+ exynos5410_clk_regs,
ARRAY_SIZE(exynos5410_clk_regs),
+ NULL, 0);
+ samsung_clk_of_register_fixed_ext(exynos5410_frt_ext_clks,
+ ARRAY_SIZE(exynos5410_frt_ext_clks),
+ ext_clk_match);
This call could be dropped after moving to generic fixed rate clock
bindings.
Best regards,
Tomasz
Already done. Will be added in patch v3.
Thank you for comments, Tomasz.
Best regards,
Tarek Dakhran
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] clk: exynos5410: register clocks using common clock framework
Hi,
On 01.11.2013 20:58, Tomasz Figa wrote:
Hi,
On Monday 14 of October 2013 19:08:23 Vyacheslav Tyrtov wrote:
From: Tarek Dakhran t.dakh...@samsung.com
The EXYNOS5410 clocks are statically listed and registered
using the Samsung specific common clock helper functions.
Signed-off-by: Tarek Dakhran t.dakh...@samsung.com
Signed-off-by: Vyacheslav Tyrtov v.tyr...@samsung.com
---
.../devicetree/bindings/clock/exynos5410-clock.txt | 37 +++
drivers/clk/samsung/Makefile | 1 +
drivers/clk/samsung/clk-exynos5410.c | 251
+ include/dt-bindings/clock/exynos5410.h
| 175 ++ 4 files changed, 464 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/exynos5410-clock.txt create
mode 100644 drivers/clk/samsung/clk-exynos5410.c
create mode 100644 include/dt-bindings/clock/exynos5410.h
The driver looks pretty good now, thanks for addressing my comments to
previous version. There are still few issues remaining, though. Please see
my comments inline.
[snip]
diff --git a/drivers/clk/samsung/clk-exynos5410.c
b/drivers/clk/samsung/clk-exynos5410.c new file mode 100644
index 000..c5eba08
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos5410.c
[snip]
+static struct of_device_id ext_clk_match[] __initdata = {
+ { .compatible = samsung,clock-oscclk, .data = (void *)0, },
+ { },
+};
I don't see anything in binding documentation mentioning this compatible
value. Anyway, since there is already a generic binding for fixed rate
clocks, this shouldn't be needed at all.
+
+/* register exynos5410 clocks */
+static void __init exynos5410_clk_init(struct device_node *np)
+{
+ void __iomem *reg_base;
+
+ reg_base = of_iomap(np, 0);
+ if (!reg_base)
+ panic(%s: failed to map registers\n, __func__);
+
+ samsung_clk_init(np, reg_base, CLK_NR_CLKS,
+ exynos5410_clk_regs,
ARRAY_SIZE(exynos5410_clk_regs),
+ NULL, 0);
+ samsung_clk_of_register_fixed_ext(exynos5410_frt_ext_clks,
+ ARRAY_SIZE(exynos5410_frt_ext_clks),
+ ext_clk_match);
This call could be dropped after moving to generic fixed rate clock
bindings.
Best regards,
Tomasz
Already done. Will be added in patch v3.
Thank you for comments, Tomasz.
Best regards,
Tarek Dakhran
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] ARM: EXYNOS: add Exynos Dual Cluster Support
On 17.10.2013 19:46, Dave Martin wrote:
On Mon, Oct 14, 2013 at 07:08:24PM +0400, Vyacheslav Tyrtov wrote:
From: Tarek Dakhran
Add EDCS(Exynos Dual Cluster Support) for Samsung Exynos5410 SoC.
This enables all 8 cores, 4 x A7 and 4 x A15 run at the same time.
Signed-off-by: Tarek Dakhran
Signed-off-by: Vyacheslav Tyrtov
---
arch/arm/mach-exynos/Makefile | 2 +
arch/arm/mach-exynos/edcs.c | 270 ++
2 files changed, 272 insertions(+)
create mode 100644 arch/arm/mach-exynos/edcs.c
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 5369615..ba6efdb 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -34,3 +34,5 @@ AFLAGS_exynos-smc.o :=-Wa,-march=armv7-a$(plus_sec)
obj-$(CONFIG_MACH_EXYNOS4_DT) += mach-exynos4-dt.o
obj-$(CONFIG_MACH_EXYNOS5_DT) += mach-exynos5-dt.o
+
+obj-$(CONFIG_SOC_EXYNOS5410) += edcs.o
diff --git a/arch/arm/mach-exynos/edcs.c b/arch/arm/mach-exynos/edcs.c
new file mode 100644
index 000..e304bd9
--- /dev/null
+++ b/arch/arm/mach-exynos/edcs.c
@@ -0,0 +1,270 @@
+/*
+ * arch/arm/mach-exynos/edcs.c - exynos dual cluster power management support
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * Author: Tarek Dakhran
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * EDCS(exynos dual cluster support) for Exynos5410 SoC.
+ */
+
[snip]
+#define EDCS_CORE_STATUS(_nr) (EDCS_CORE_CONFIGURATION(_nr) + 0x4)
+#define EDCS_CORE_OPTION(_nr) (EDCS_CORE_CONFIGURATION(_nr) + 0x8)
+
+#define REG_CPU_STATE_ADDR0(S5P_VA_SYSRAM_NS + 0x28)
Is there any reason why S5P_VA_SYSRAM_NS needs to be a static mapping?
What do you mean by "static mapping"?
+#define REG_CPU_STATE_ADDR(_nr)(REG_CPU_STATE_ADDR0 + \
+_nr * EDCS_CPUS_PER_CLUSTER)
+
+static arch_spinlock_t edcs_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+
+static int edcs_use_count[EDCS_CPUS_PER_CLUSTER][EDCS_CLUSTERS];
+static int core_count[EDCS_CLUSTERS];
+
+static void exynos_core_power_control(unsigned int cpu, unsigned int cluster,
+ bool enable)
+{
+ unsigned int offset = cluster * EDCS_CPUS_PER_CLUSTER + cpu;
+ int value = enable ? S5P_CORE_LOCAL_PWR_EN : 0;
+
+ if ((__raw_readl(EDCS_CORE_STATUS(offset)) & 0x3) != value)
+ __raw_writel(value, EDCS_CORE_CONFIGURATION(offset));
I think you need to replace all the __raw_readl() / __raw_writel() calls
in this file with readl_relaxed() / writel_relaxed().
This ensures little-endian byte order, so that BE8 kernels will work.
Will be done.
+}
+
+static void exynos_core_power_up(unsigned int cpu, unsigned int cluster)
+{
+ exynos_core_power_control(cpu, cluster, true);
+}
[snip]
+
+ edcs_use_count[cpu][cluster]++;
+ if (edcs_use_count[cpu][cluster] == 1) {
+ ++core_count[cluster];
+ set_boot_flag(cpu, 0x2);
0x2 looks like a magic number. Can we have a #define for that?
Will be done.
If the boot flag is read by the inbound CPU or by a peripheral then
there are memory ordering issues to take into account. Otherwise, can't
the inbound CPU come online and race with the write to the boot flag?
Inbound CPU doesn't write the boot flag.
What is the memory type of REG_STATE_ADDR()?
Same type as S5P_VA_SYSRAM_NS.
This 4K region is mapped as follows:
static struct map_desc exynos5410_iodesc[] __initdata = {
{
.virtual= (unsigned long)S5P_VA_SYSRAM_NS,
.pfn= __phys_to_pfn(EXYNOS5410_PA_SYSRAM_NS),
.length = SZ_4K,
.type = MT_DEVICE,
},
};
+ exynos_core_power_up(cpu, cluster);
+ } else if (edcs_use_count[cpu][cluster] != 2) {
+ /*
+* The only possible values are:
+* 0 = CPU down
+* 1 = CPU (still) up
+* 2 = CPU requested to be up before it had a chance
+* to actually make itself down.
+* Any other value is a bug.
+*/
+ BUG();
+ }
+
+ arch_spin_unlock(_lock);
+ local_irq_enable();
+
+ return 0;
+}
+static void exynos_power_down(void)
+{
+ unsigned int mpidr, cpu, cluster;
+ bool last_man = false, skip_wfi = false;
+
+ mpidr = read_cpuid_mpidr();
+ cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+ pr_debug("%s: cpu %u cluster %u\n", __func__, cpu, cluster);
+ BUG_ON(cpu >= EDCS_CPUS_PER_CLUSTER || cluster >= EDCS_CLUSTERS);
+
+ __mcpm_cpu_going_down(cpu, cluster);
Re: [PATCH v2 3/4] ARM: EXYNOS: add Exynos Dual Cluster Support
On 17.10.2013 19:46, Dave Martin wrote:
On Mon, Oct 14, 2013 at 07:08:24PM +0400, Vyacheslav Tyrtov wrote:
From: Tarek Dakhran t.dakh...@samsung.com
Add EDCS(Exynos Dual Cluster Support) for Samsung Exynos5410 SoC.
This enables all 8 cores, 4 x A7 and 4 x A15 run at the same time.
Signed-off-by: Tarek Dakhran t.dakh...@samsung.com
Signed-off-by: Vyacheslav Tyrtov v.tyr...@samsung.com
---
arch/arm/mach-exynos/Makefile | 2 +
arch/arm/mach-exynos/edcs.c | 270 ++
2 files changed, 272 insertions(+)
create mode 100644 arch/arm/mach-exynos/edcs.c
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 5369615..ba6efdb 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -34,3 +34,5 @@ AFLAGS_exynos-smc.o :=-Wa,-march=armv7-a$(plus_sec)
obj-$(CONFIG_MACH_EXYNOS4_DT) += mach-exynos4-dt.o
obj-$(CONFIG_MACH_EXYNOS5_DT) += mach-exynos5-dt.o
+
+obj-$(CONFIG_SOC_EXYNOS5410) += edcs.o
diff --git a/arch/arm/mach-exynos/edcs.c b/arch/arm/mach-exynos/edcs.c
new file mode 100644
index 000..e304bd9
--- /dev/null
+++ b/arch/arm/mach-exynos/edcs.c
@@ -0,0 +1,270 @@
+/*
+ * arch/arm/mach-exynos/edcs.c - exynos dual cluster power management support
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * Author: Tarek Dakhran t.dakh...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * EDCS(exynos dual cluster support) for Exynos5410 SoC.
+ */
+
[snip]
+#define EDCS_CORE_STATUS(_nr) (EDCS_CORE_CONFIGURATION(_nr) + 0x4)
+#define EDCS_CORE_OPTION(_nr) (EDCS_CORE_CONFIGURATION(_nr) + 0x8)
+
+#define REG_CPU_STATE_ADDR0(S5P_VA_SYSRAM_NS + 0x28)
Is there any reason why S5P_VA_SYSRAM_NS needs to be a static mapping?
What do you mean by static mapping?
+#define REG_CPU_STATE_ADDR(_nr)(REG_CPU_STATE_ADDR0 + \
+_nr * EDCS_CPUS_PER_CLUSTER)
+
+static arch_spinlock_t edcs_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+
+static int edcs_use_count[EDCS_CPUS_PER_CLUSTER][EDCS_CLUSTERS];
+static int core_count[EDCS_CLUSTERS];
+
+static void exynos_core_power_control(unsigned int cpu, unsigned int cluster,
+ bool enable)
+{
+ unsigned int offset = cluster * EDCS_CPUS_PER_CLUSTER + cpu;
+ int value = enable ? S5P_CORE_LOCAL_PWR_EN : 0;
+
+ if ((__raw_readl(EDCS_CORE_STATUS(offset)) 0x3) != value)
+ __raw_writel(value, EDCS_CORE_CONFIGURATION(offset));
I think you need to replace all the __raw_readl() / __raw_writel() calls
in this file with readl_relaxed() / writel_relaxed().
This ensures little-endian byte order, so that BE8 kernels will work.
Will be done.
+}
+
+static void exynos_core_power_up(unsigned int cpu, unsigned int cluster)
+{
+ exynos_core_power_control(cpu, cluster, true);
+}
[snip]
+
+ edcs_use_count[cpu][cluster]++;
+ if (edcs_use_count[cpu][cluster] == 1) {
+ ++core_count[cluster];
+ set_boot_flag(cpu, 0x2);
0x2 looks like a magic number. Can we have a #define for that?
Will be done.
If the boot flag is read by the inbound CPU or by a peripheral then
there are memory ordering issues to take into account. Otherwise, can't
the inbound CPU come online and race with the write to the boot flag?
Inbound CPU doesn't write the boot flag.
What is the memory type of REG_STATE_ADDR()?
Same type as S5P_VA_SYSRAM_NS.
This 4K region is mapped as follows:
static struct map_desc exynos5410_iodesc[] __initdata = {
{
.virtual= (unsigned long)S5P_VA_SYSRAM_NS,
.pfn= __phys_to_pfn(EXYNOS5410_PA_SYSRAM_NS),
.length = SZ_4K,
.type = MT_DEVICE,
},
};
+ exynos_core_power_up(cpu, cluster);
+ } else if (edcs_use_count[cpu][cluster] != 2) {
+ /*
+* The only possible values are:
+* 0 = CPU down
+* 1 = CPU (still) up
+* 2 = CPU requested to be up before it had a chance
+* to actually make itself down.
+* Any other value is a bug.
+*/
+ BUG();
+ }
+
+ arch_spin_unlock(edcs_lock);
+ local_irq_enable();
+
+ return 0;
+}
+static void exynos_power_down(void)
+{
+ unsigned int mpidr, cpu, cluster;
+ bool last_man = false, skip_wfi = false;
+
+ mpidr = read_cpuid_mpidr();
+ cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+ pr_debug(%s: cpu %u cluster %u\n, __func__, cpu, cluster);
+ BUG_ON(cpu = EDCS_CPUS_PER_CLUSTER || cluster = EDCS_CLUSTERS
Re: [PATCH v2 0/4] Exynos 5410 Dual cluster support
On 17.10.2013 17:04, Aliaksei Katovich wrote: hi Kevin; Vyacheslav Tyrtov writes: The series of patches represent support of Exynos 5410 SoC The Exynos 5410 is the first Samsung SoC based on bigLITTLE architecture. Patches allow all 8 CPU cores (4 x A7 and 4 x A15) to run at the same time Patches add new platform description, support of clock controller, dual cluster support and device tree for Exynos 5410 Has been build on v3.12-rc5. Has been tested on Exynos 5410 reference board (exynos_defconfig). Has anyone tried this on the exynos5410 based odroid-xu yet? I tried booting this on my recently arrived odroid-xu, but am not getting it to boot. I am able to boot my odroid-xu+e to busybox with these patches applied against 3.12-rc5: exynos_defconfig and exynos5410-smdk5410.dtb were used. However there seem to be some issues with virq allocations, like this: Starting kernel ... [0.00] [] (unwind_backtrace+0x0/0xf8) from [] (show_stack+0x10/0x14) [0.00] [] (show_stack+0x10/0x14) from [] (dump_stack+0x6c/0xac) [0.00] [] (dump_stack+0x6c/0xac) from [] (warn_slowpath_common+0x64/0x88) [0.00] [] (warn_slowpath_common+0x64/0x88) from [] (warn_slowpath_fmt+0x30/0x40) [0.00] [] (warn_slowpath_fmt+0x30/0x40) from [] (irq_domain_associate+0x128/0x1a8) [0.00] [] (irq_domain_associate+0x128/0x1a8) from [] (irq_domain_associate_many+0x30/0x3c ) [0.00] [] (irq_domain_associate_many+0x30/0x3c) from [] (irq_domain_add_simple+0x78/0x90) [0.00] [] (irq_domain_add_simple+0x78/0x90) from [] (combiner_of_init+0xb4/0x198) [0.00] [] (combiner_of_init+0xb4/0x198) from [] (of_irq_init+0x278/0x2a0) [0.00] [] (of_irq_init+0x278/0x2a0) from [] (start_kernel+0x18c/0x384) [0.00] [] (start_kernel+0x18c/0x384) from [<40008074>] (0x40008074) [0.00] ---[ end trace 1b75b31a2719edcd ]--- [0.00] [ cut here ] [0.00] WARNING: CPU: 0 PID: 0 at kernel/irq/irqdomain.c:278 irq_domain_associate+0x128/0x1a8() [0.00] error: virq337 is not allocated [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW 3.12.0-rc5-4-g1cb405f #1 [0.00] [] (unwind_backtrace+0x0/0xf8) from [] (show_stack+0x10/0x14) [0.00] [] (show_stack+0x10/0x14) from [] (dump_stack+0x6c/0xac) [0.00] [] (dump_stack+0x6c/0xac) from [] (warn_slowpath_common+0x64/0x88) [0.00] [] (warn_slowpath_common+0x64/0x88) from [] (warn_slowpath_fmt+0x30/0x40) [0.00] [] (warn_slowpath_fmt+0x30/0x40) from [] (irq_domain_associate+0x128/0x1a8) [0.00] [] (irq_domain_associate+0x128/0x1a8) from [] (irq_domain_associate_many+0x30/0x3c ) [0.00] [] (irq_domain_associate_many+0x30/0x3c) from [] (irq_domain_add_simple+0x78/0x90) [0.00] [] (irq_domain_add_simple+0x78/0x90) from [] (combiner_of_init+0xb4/0x198) [0.00] [] (combiner_of_init+0xb4/0x198) from [] (of_irq_init+0x278/0x2a0) [0.00] [] (of_irq_init+0x278/0x2a0) from [] (start_kernel+0x18c/0x384) [0.00] [] (start_kernel+0x18c/0x384) from [<40008074>] (0x40008074) [0.00] ---[ end trace 1b75b31a2719edce ]--- [0.00] [ cut here ] You can check full boot log here http://sprunge.us/NKcU -- Aliaksei I'm not yet terribly familiar with this SoC, what are the settings needed for DEBUG_LL on this board? Thanks, Kevin ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Also change NR_CPUS to 8 in kernel config, so you will get 8 cores booted instead of 2. Best regards, Tarek Dakhran -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/4] Exynos 5410 Dual cluster support
On 17.10.2013 17:04, Aliaksei Katovich wrote: hi Kevin; Vyacheslav Tyrtov writes: The series of patches represent support of Exynos 5410 SoC The Exynos 5410 is the first Samsung SoC based on bigLITTLE architecture. Patches allow all 8 CPU cores (4 x A7 and 4 x A15) to run at the same time Patches add new platform description, support of clock controller, dual cluster support and device tree for Exynos 5410 Has been build on v3.12-rc5. Has been tested on Exynos 5410 reference board (exynos_defconfig). Has anyone tried this on the exynos5410 based odroid-xu yet? I tried booting this on my recently arrived odroid-xu, but am not getting it to boot. I am able to boot my odroid-xu+e to busybox with these patches applied against 3.12-rc5: exynos_defconfig and exynos5410-smdk5410.dtb were used. However there seem to be some issues with virq allocations, like this: Starting kernel ... [0.00] [] (unwind_backtrace+0x0/0xf8) from [] (show_stack+0x10/0x14) [0.00] [] (show_stack+0x10/0x14) from [] (dump_stack+0x6c/0xac) [0.00] [] (dump_stack+0x6c/0xac) from [] (warn_slowpath_common+0x64/0x88) [0.00] [] (warn_slowpath_common+0x64/0x88) from [] (warn_slowpath_fmt+0x30/0x40) [0.00] [] (warn_slowpath_fmt+0x30/0x40) from [] (irq_domain_associate+0x128/0x1a8) [0.00] [] (irq_domain_associate+0x128/0x1a8) from [] (irq_domain_associate_many+0x30/0x3c ) [0.00] [] (irq_domain_associate_many+0x30/0x3c) from [] (irq_domain_add_simple+0x78/0x90) [0.00] [] (irq_domain_add_simple+0x78/0x90) from [] (combiner_of_init+0xb4/0x198) [0.00] [] (combiner_of_init+0xb4/0x198) from [] (of_irq_init+0x278/0x2a0) [0.00] [] (of_irq_init+0x278/0x2a0) from [] (start_kernel+0x18c/0x384) [0.00] [] (start_kernel+0x18c/0x384) from [<40008074>] (0x40008074) [0.00] ---[ end trace 1b75b31a2719edcd ]--- [0.00] [ cut here ] [0.00] WARNING: CPU: 0 PID: 0 at kernel/irq/irqdomain.c:278 irq_domain_associate+0x128/0x1a8() [0.00] error: virq337 is not allocated [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW 3.12.0-rc5-4-g1cb405f #1 [0.00] [] (unwind_backtrace+0x0/0xf8) from [] (show_stack+0x10/0x14) [0.00] [] (show_stack+0x10/0x14) from [] (dump_stack+0x6c/0xac) [0.00] [] (dump_stack+0x6c/0xac) from [] (warn_slowpath_common+0x64/0x88) [0.00] [] (warn_slowpath_common+0x64/0x88) from [] (warn_slowpath_fmt+0x30/0x40) [0.00] [] (warn_slowpath_fmt+0x30/0x40) from [] (irq_domain_associate+0x128/0x1a8) [0.00] [] (irq_domain_associate+0x128/0x1a8) from [] (irq_domain_associate_many+0x30/0x3c ) [0.00] [] (irq_domain_associate_many+0x30/0x3c) from [] (irq_domain_add_simple+0x78/0x90) [0.00] [] (irq_domain_add_simple+0x78/0x90) from [] (combiner_of_init+0xb4/0x198) [0.00] [] (combiner_of_init+0xb4/0x198) from [] (of_irq_init+0x278/0x2a0) [0.00] [] (of_irq_init+0x278/0x2a0) from [] (start_kernel+0x18c/0x384) [0.00] [] (start_kernel+0x18c/0x384) from [<40008074>] (0x40008074) [0.00] ---[ end trace 1b75b31a2719edce ]--- [0.00] [ cut here ] You can check full boot log here http://sprunge.us/NKcU -- Aliaksei I'm not yet terribly familiar with this SoC, what are the settings needed for DEBUG_LL on this board? Thanks, Kevin ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel This will be fixed in 3.13. Now you can just change "irq_base = 160" to "irq_base = 256" in "static int __init combiner_of_init(struct device_node *np, struct device_node *parent)" function in "drivers/irqchip/exynos-combiner.c" Best regards, Tarek Dakhran -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/4] Exynos 5410 Dual cluster support
On 17.10.2013 17:04, Aliaksei Katovich wrote: hi Kevin; Vyacheslav Tyrtov v.tyr...@samsung.com writes: The series of patches represent support of Exynos 5410 SoC The Exynos 5410 is the first Samsung SoC based on bigLITTLE architecture. Patches allow all 8 CPU cores (4 x A7 and 4 x A15) to run at the same time Patches add new platform description, support of clock controller, dual cluster support and device tree for Exynos 5410 Has been build on v3.12-rc5. Has been tested on Exynos 5410 reference board (exynos_defconfig). Has anyone tried this on the exynos5410 based odroid-xu yet? I tried booting this on my recently arrived odroid-xu, but am not getting it to boot. I am able to boot my odroid-xu+e to busybox with these patches applied against 3.12-rc5: exynos_defconfig and exynos5410-smdk5410.dtb were used. However there seem to be some issues with virq allocations, like this: snippet Starting kernel ... [0.00] [c0014d48] (unwind_backtrace+0x0/0xf8) from [c00117d0] (show_stack+0x10/0x14) [0.00] [c00117d0] (show_stack+0x10/0x14) from [c0363488] (dump_stack+0x6c/0xac) [0.00] [c0363488] (dump_stack+0x6c/0xac) from [c001e330] (warn_slowpath_common+0x64/0x88) [0.00] [c001e330] (warn_slowpath_common+0x64/0x88) from [c001e3e8] (warn_slowpath_fmt+0x30/0x40) [0.00] [c001e3e8] (warn_slowpath_fmt+0x30/0x40) from [c005a1b4] (irq_domain_associate+0x128/0x1a8) [0.00] [c005a1b4] (irq_domain_associate+0x128/0x1a8) from [c005a508] (irq_domain_associate_many+0x30/0x3c ) [0.00] [c005a508] (irq_domain_associate_many+0x30/0x3c) from [c005a768] (irq_domain_add_simple+0x78/0x90) [0.00] [c005a768] (irq_domain_add_simple+0x78/0x90) from [c04b044c] (combiner_of_init+0xb4/0x198) [0.00] [c04b044c] (combiner_of_init+0xb4/0x198) from [c04b6938] (of_irq_init+0x278/0x2a0) [0.00] [c04b6938] (of_irq_init+0x278/0x2a0) from [c049b8fc] (start_kernel+0x18c/0x384) [0.00] [c049b8fc] (start_kernel+0x18c/0x384) from [40008074] (0x40008074) [0.00] ---[ end trace 1b75b31a2719edcd ]--- [0.00] [ cut here ] [0.00] WARNING: CPU: 0 PID: 0 at kernel/irq/irqdomain.c:278 irq_domain_associate+0x128/0x1a8() [0.00] error: virq337 is not allocated [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW 3.12.0-rc5-4-g1cb405f #1 [0.00] [c0014d48] (unwind_backtrace+0x0/0xf8) from [c00117d0] (show_stack+0x10/0x14) [0.00] [c00117d0] (show_stack+0x10/0x14) from [c0363488] (dump_stack+0x6c/0xac) [0.00] [c0363488] (dump_stack+0x6c/0xac) from [c001e330] (warn_slowpath_common+0x64/0x88) [0.00] [c001e330] (warn_slowpath_common+0x64/0x88) from [c001e3e8] (warn_slowpath_fmt+0x30/0x40) [0.00] [c001e3e8] (warn_slowpath_fmt+0x30/0x40) from [c005a1b4] (irq_domain_associate+0x128/0x1a8) [0.00] [c005a1b4] (irq_domain_associate+0x128/0x1a8) from [c005a508] (irq_domain_associate_many+0x30/0x3c ) [0.00] [c005a508] (irq_domain_associate_many+0x30/0x3c) from [c005a768] (irq_domain_add_simple+0x78/0x90) [0.00] [c005a768] (irq_domain_add_simple+0x78/0x90) from [c04b044c] (combiner_of_init+0xb4/0x198) [0.00] [c04b044c] (combiner_of_init+0xb4/0x198) from [c04b6938] (of_irq_init+0x278/0x2a0) [0.00] [c04b6938] (of_irq_init+0x278/0x2a0) from [c049b8fc] (start_kernel+0x18c/0x384) [0.00] [c049b8fc] (start_kernel+0x18c/0x384) from [40008074] (0x40008074) [0.00] ---[ end trace 1b75b31a2719edce ]--- [0.00] [ cut here ] /snippet You can check full boot log here http://sprunge.us/NKcU -- Aliaksei I'm not yet terribly familiar with this SoC, what are the settings needed for DEBUG_LL on this board? Thanks, Kevin ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel This will be fixed in 3.13. Now you can just change irq_base = 160 to irq_base = 256 in static int __init combiner_of_init(struct device_node *np, struct device_node *parent) function in drivers/irqchip/exynos-combiner.c Best regards, Tarek Dakhran -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/4] Exynos 5410 Dual cluster support
On 17.10.2013 17:04, Aliaksei Katovich wrote: hi Kevin; Vyacheslav Tyrtov v.tyr...@samsung.com writes: The series of patches represent support of Exynos 5410 SoC The Exynos 5410 is the first Samsung SoC based on bigLITTLE architecture. Patches allow all 8 CPU cores (4 x A7 and 4 x A15) to run at the same time Patches add new platform description, support of clock controller, dual cluster support and device tree for Exynos 5410 Has been build on v3.12-rc5. Has been tested on Exynos 5410 reference board (exynos_defconfig). Has anyone tried this on the exynos5410 based odroid-xu yet? I tried booting this on my recently arrived odroid-xu, but am not getting it to boot. I am able to boot my odroid-xu+e to busybox with these patches applied against 3.12-rc5: exynos_defconfig and exynos5410-smdk5410.dtb were used. However there seem to be some issues with virq allocations, like this: snippet Starting kernel ... [0.00] [c0014d48] (unwind_backtrace+0x0/0xf8) from [c00117d0] (show_stack+0x10/0x14) [0.00] [c00117d0] (show_stack+0x10/0x14) from [c0363488] (dump_stack+0x6c/0xac) [0.00] [c0363488] (dump_stack+0x6c/0xac) from [c001e330] (warn_slowpath_common+0x64/0x88) [0.00] [c001e330] (warn_slowpath_common+0x64/0x88) from [c001e3e8] (warn_slowpath_fmt+0x30/0x40) [0.00] [c001e3e8] (warn_slowpath_fmt+0x30/0x40) from [c005a1b4] (irq_domain_associate+0x128/0x1a8) [0.00] [c005a1b4] (irq_domain_associate+0x128/0x1a8) from [c005a508] (irq_domain_associate_many+0x30/0x3c ) [0.00] [c005a508] (irq_domain_associate_many+0x30/0x3c) from [c005a768] (irq_domain_add_simple+0x78/0x90) [0.00] [c005a768] (irq_domain_add_simple+0x78/0x90) from [c04b044c] (combiner_of_init+0xb4/0x198) [0.00] [c04b044c] (combiner_of_init+0xb4/0x198) from [c04b6938] (of_irq_init+0x278/0x2a0) [0.00] [c04b6938] (of_irq_init+0x278/0x2a0) from [c049b8fc] (start_kernel+0x18c/0x384) [0.00] [c049b8fc] (start_kernel+0x18c/0x384) from [40008074] (0x40008074) [0.00] ---[ end trace 1b75b31a2719edcd ]--- [0.00] [ cut here ] [0.00] WARNING: CPU: 0 PID: 0 at kernel/irq/irqdomain.c:278 irq_domain_associate+0x128/0x1a8() [0.00] error: virq337 is not allocated [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW 3.12.0-rc5-4-g1cb405f #1 [0.00] [c0014d48] (unwind_backtrace+0x0/0xf8) from [c00117d0] (show_stack+0x10/0x14) [0.00] [c00117d0] (show_stack+0x10/0x14) from [c0363488] (dump_stack+0x6c/0xac) [0.00] [c0363488] (dump_stack+0x6c/0xac) from [c001e330] (warn_slowpath_common+0x64/0x88) [0.00] [c001e330] (warn_slowpath_common+0x64/0x88) from [c001e3e8] (warn_slowpath_fmt+0x30/0x40) [0.00] [c001e3e8] (warn_slowpath_fmt+0x30/0x40) from [c005a1b4] (irq_domain_associate+0x128/0x1a8) [0.00] [c005a1b4] (irq_domain_associate+0x128/0x1a8) from [c005a508] (irq_domain_associate_many+0x30/0x3c ) [0.00] [c005a508] (irq_domain_associate_many+0x30/0x3c) from [c005a768] (irq_domain_add_simple+0x78/0x90) [0.00] [c005a768] (irq_domain_add_simple+0x78/0x90) from [c04b044c] (combiner_of_init+0xb4/0x198) [0.00] [c04b044c] (combiner_of_init+0xb4/0x198) from [c04b6938] (of_irq_init+0x278/0x2a0) [0.00] [c04b6938] (of_irq_init+0x278/0x2a0) from [c049b8fc] (start_kernel+0x18c/0x384) [0.00] [c049b8fc] (start_kernel+0x18c/0x384) from [40008074] (0x40008074) [0.00] ---[ end trace 1b75b31a2719edce ]--- [0.00] [ cut here ] /snippet You can check full boot log here http://sprunge.us/NKcU -- Aliaksei I'm not yet terribly familiar with this SoC, what are the settings needed for DEBUG_LL on this board? Thanks, Kevin ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Also change NR_CPUS to 8 in kernel config, so you will get 8 cores booted instead of 2. Best regards, Tarek Dakhran -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
