Skip to contentSkip to conversation

ARM: EXYNOS: reset Little cores when cpu is up

PATCH New Chanho Park 4 participants 8 messages Sep 1, 2015 – Sep 14, 2015

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH v2 1/1 ARM: EXYNOS: reset Little cores when cpu is up

The cpu booting of exynos5422 has been still broken since we discussed it in last year[1]. This patch is inspired from Odroid XU3
code (Actually, it was from samsung exynos vendor kernel)[2]. This weird reset code was founded exynos5420 octa cores series SoCs and only required for the first boot core is the Little core (Cortex A7). Some of the exynos5420 boards and all of the exynos5422 boards will require this code.

There is two ways to check the little core is the first cpu. One is checking GPG2CON[1] GPIO value and the other is checking the cluster number of the first cpu. I selected the latter because it's more easier than the former.

[1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html [2]:https://patchwork.kernel.org/patch/6782891/

Cc Kevin Hilman <[email protected]>
Cc Javier Martinez Canillas <[email protected]>
Cc Krzysztof Kozlowski <[email protected]>

---
Changes from v1:
.kfc to Little (Cortex A7) and eagle to big (Cortex A15) .append comments about waiting SPARE2 register

Changes since RFC:
.drop checking soc_is_exynos5800 to extend this codes to
exynos5420/5422 boards.
.kfc cores will be reset only if the cpu0 is kfc core. .Rebase top of the kukjin's for-next branch

 arch/arm/mach-exynos/mcpm-exynos.c | 25 ++++++++++++++++++++++++-
 arch/arm/mach-exynos/regs-pmu.h    |  6 ++++++
 2 files changed, 30 insertions(+), 1 deletion(-)
arch/arm/mach-exynos/mcpm-exynos.c +24 -1
index 9bdf547..8926621 100644
@@ -20,6 +20,7 @@
 #include <asm/cputype.h>
 #include <asm/cp15.h>
 #include <asm/mcpm.h>
+#include <asm/smp_plat.h>
 
 #include "regs-pmu.h"
 #include "common.h"
@@ -70,7 +71,29 @@ static int exynos_cpu_powerup(unsigned int cpu, unsigned int cluster)
 		cluster >= EXYNOS5420_NR_CLUSTERS)
 		return -EINVAL;
 
-	exynos_cpu_power_up(cpunr);
+	if (!exynos_cpu_power_state(cpunr)) {
+		exynos_cpu_power_up(cpunr);
+
+		/* This assumes the cluster number of the big cores(Cortex A15)
+		 * is 0 and the Little cores(Cortex A7) is 1.
+		 * When the system was booted from the Little core,
+		 * they should be reset during power up cpu.
+		 */
+		if (cluster &&
+		    cluster == MPIDR_AFFINITY_LEVEL(cpu_logical_map(0), 1)) {
+			/* Before we reset the Little cores, we should wait
+			 * the SPARE2 register is set to 1 because the init
+			 * codes of the iROM will set the register after
+			 * initialization.
+			 */
+			while (!pmu_raw_readl(S5P_PMU_SPARE2))
+				udelay(10);
+
+			pmu_raw_writel(EXYNOS5420_KFC_CORE_RESET(cpu),
+					EXYNOS_SWRESET);
+		}
+	}
+
 	return 0;
 }
 
arch/arm/mach-exynos/regs-pmu.h +6 -0
index b761433..fba9068 100644
@@ -513,6 +513,12 @@ static inline unsigned int exynos_pmu_cpunr(unsigned int mpidr)
 #define SPREAD_ENABLE						0xF
 #define SPREAD_USE_STANDWFI					0xF
 
+#define EXYNOS5420_KFC_CORE_RESET0				BIT(8)
+#define EXYNOS5420_KFC_ETM_RESET0				BIT(20)
+
+#define EXYNOS5420_KFC_CORE_RESET(_nr)				\
+	((EXYNOS5420_KFC_CORE_RESET0 | EXYNOS5420_KFC_ETM_RESET0) << (_nr))
+
 #define EXYNOS5420_BB_CON1					0x0784
 #define EXYNOS5420_BB_SEL_EN					BIT(31)
 #define EXYNOS5420_BB_PMOS_EN					BIT(7)
Signature · 1 line
2.1.0
#1 lore raw

PATCH v2 1/1 ARM: EXYNOS: reset Little cores when cpu is up

Hi All,

Quoted 98 lines · Chanho Park

The cpu booting of exynos5422 has been still broken since we discussed it in last year[1]. This patch is inspired from Odroid XU3
code (Actually, it was from samsung exynos vendor kernel)[2]. This weird reset code was founded exynos5420 octa cores series SoCs and only required for the first boot core is the Little core (Cortex A7). Some of the exynos5420 boards and all of the exynos5422 boards will require this code.

There is two ways to check the little core is the first cpu. One is checking GPG2CON[1] GPIO value and the other is checking the cluster number of the first cpu. I selected the latter because it's more easier than the former.

[1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html [2]:https://patchwork.kernel.org/patch/6782891/

Cc Kevin Hilman <[email protected]>
Cc Javier Martinez Canillas <[email protected]>
Cc Krzysztof Kozlowski <[email protected]>

---
Changes from v1:
.kfc to Little (Cortex A7) and eagle to big (Cortex A15) .append comments about waiting SPARE2 register

Changes since RFC:
.drop checking soc_is_exynos5800 to extend this codes to
exynos5420/5422 boards.
.kfc cores will be reset only if the cpu0 is kfc core. .Rebase top of the kukjin's for-next branch

 arch/arm/mach-exynos/mcpm-exynos.c | 25 ++++++++++++++++++++++++-
 arch/arm/mach-exynos/regs-pmu.h    |  6 ++++++
 2 files changed, 30 insertions(+), 1 deletion(-)
arch/arm/mach-exynos/mcpm-exynos.c +24 -1
index 9bdf547..8926621 100644
@@ -20,6 +20,7 @@
 #include <asm/cputype.h>
 #include <asm/cp15.h>
 #include <asm/mcpm.h>
+#include <asm/smp_plat.h>
 
 #include "regs-pmu.h"
 #include "common.h"
@@ -70,7 +71,29 @@ static int exynos_cpu_powerup(unsigned int cpu, unsigned int cluster)
                cluster >= EXYNOS5420_NR_CLUSTERS)
                return -EINVAL;
 
-       exynos_cpu_power_up(cpunr);
+       if (!exynos_cpu_power_state(cpunr)) {
+               exynos_cpu_power_up(cpunr);
+
+               /* This assumes the cluster number of the big cores(Cortex A15)
+                * is 0 and the Little cores(Cortex A7) is 1.
+                * When the system was booted from the Little core,
+                * they should be reset during power up cpu.
+                */
+               if (cluster &&
+                   cluster == MPIDR_AFFINITY_LEVEL(cpu_logical_map(0), 1)) {
+                       /* Before we reset the Little cores, we should wait
+                        * the SPARE2 register is set to 1 because the init
+                        * codes of the iROM will set the register after
+                        * initialization.
+                        */
+                       while (!pmu_raw_readl(S5P_PMU_SPARE2))
+                               udelay(10);
+
+                       pmu_raw_writel(EXYNOS5420_KFC_CORE_RESET(cpu),
+                                       EXYNOS_SWRESET);
+               }
+       }
+
        return 0;
 }
 
arch/arm/mach-exynos/regs-pmu.h +6 -1
index b761433..fba9068 100644
@@ -513,6 +513,12 @@ static inline unsigned int exynos_pmu_cpunr(unsigned int mpidr)
 #define SPREAD_ENABLE                                          0xF
 #define SPREAD_USE_STANDWFI                                    0xF
 
+#define EXYNOS5420_KFC_CORE_RESET0                             BIT(8)
+#define EXYNOS5420_KFC_ETM_RESET0                              BIT(20)
+
+#define EXYNOS5420_KFC_CORE_RESET(_nr)                         \
+       ((EXYNOS5420_KFC_CORE_RESET0 | EXYNOS5420_KFC_ETM_RESET0) << (_nr))
+
 #define EXYNOS5420_BB_CON1                                     0x0784
 #define EXYNOS5420_BB_SEL_EN                                   BIT(31)
 #define EXYNOS5420_BB_PMOS_EN                                  BIT(7)
--
Quoted 2 lines

2.1.0

Looking at the following patch

https://github.com/tobiasjakobi/linux-odroid/commit/c25aae8a02c0e3132df581d1d12be1d6738a08d6

You should also consider some similar logic for platform_do_lowpower and exynos_boot_secondary.
In that same way to address CPUIdle issue.

I am just trying to put my observation. I may be wrong.

-Anand Moon

Quoted 4 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

#2 lore raw

PATCH v2 1/1 ARM: EXYNOS: reset Little cores when cpu is up

In reply to Chanho Park
Quoted 32 lines · Chanho Park

The cpu booting of exynos5422 has been still broken since we discussed it in last year[1]. This patch is inspired from Odroid XU3
code (Actually, it was from samsung exynos vendor kernel)[2]. This weird reset code was founded exynos5420 octa cores series SoCs and only required for the first boot core is the Little core (Cortex A7). Some of the exynos5420 boards and all of the exynos5422 boards will require this code.

There is two ways to check the little core is the first cpu. One is checking GPG2CON[1] GPIO value and the other is checking the cluster number of the first cpu. I selected the latter because it's more easier than the former.

[1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html [2]:https://patchwork.kernel.org/patch/6782891/

Cc Kevin Hilman <[email protected]>
Cc Javier Martinez Canillas <[email protected]>
Cc Krzysztof Kozlowski <[email protected]>

---
Changes from v1:
.kfc to Little (Cortex A7) and eagle to big (Cortex A15) .append comments about waiting SPARE2 register

Changes since RFC:
.drop checking soc_is_exynos5800 to extend this codes to
exynos5420/5422 boards.
.kfc cores will be reset only if the cpu0 is kfc core. .Rebase top of the kukjin's for-next branch

Quoted 3 lines
 arch/arm/mach-exynos/mcpm-exynos.c | 25 ++++++++++++++++++++++++-
 arch/arm/mach-exynos/regs-pmu.h    |  6 ++++++
 2 files changed, 30 insertions(+), 1 deletion(-)

Thanks for updating the patch. Remaining minor nit about comment style (/* on first line) can be fixed while applying.

The patch works good, after disabling bL switcher I have 8 cores running:

Tested on Odroid XU4:

It's 4.3 merge window so the patch will go probably to v4.4.

Best regards,
Krzysztof

Quoted 62 lines
arch/arm/mach-exynos/mcpm-exynos.c +24 -1
index 9bdf547..8926621 100644
@@ -20,6 +20,7 @@
 #include <asm/cputype.h>
 #include <asm/cp15.h>
 #include <asm/mcpm.h>
+#include <asm/smp_plat.h>
 
 #include "regs-pmu.h"
 #include "common.h"
@@ -70,7 +71,29 @@ static int exynos_cpu_powerup(unsigned int cpu, unsigned int cluster)
 		cluster >= EXYNOS5420_NR_CLUSTERS)
 		return -EINVAL;
 
-	exynos_cpu_power_up(cpunr);
+	if (!exynos_cpu_power_state(cpunr)) {
+		exynos_cpu_power_up(cpunr);
+
+		/* This assumes the cluster number of the big cores(Cortex A15)
+		 * is 0 and the Little cores(Cortex A7) is 1.
+		 * When the system was booted from the Little core,
+		 * they should be reset during power up cpu.
+		 */
+		if (cluster &&
+		    cluster == MPIDR_AFFINITY_LEVEL(cpu_logical_map(0), 1)) {
+			/* Before we reset the Little cores, we should wait
+			 * the SPARE2 register is set to 1 because the init
+			 * codes of the iROM will set the register after
+			 * initialization.
+			 */
+			while (!pmu_raw_readl(S5P_PMU_SPARE2))
+				udelay(10);
+
+			pmu_raw_writel(EXYNOS5420_KFC_CORE_RESET(cpu),
+					EXYNOS_SWRESET);
+		}
+	}
+
 	return 0;
 }
 
arch/arm/mach-exynos/regs-pmu.h +6 -0
index b761433..fba9068 100644
@@ -513,6 +513,12 @@ static inline unsigned int exynos_pmu_cpunr(unsigned int mpidr)
 #define SPREAD_ENABLE						0xF
 #define SPREAD_USE_STANDWFI					0xF
 
+#define EXYNOS5420_KFC_CORE_RESET0				BIT(8)
+#define EXYNOS5420_KFC_ETM_RESET0				BIT(20)
+
+#define EXYNOS5420_KFC_CORE_RESET(_nr)				\
+	((EXYNOS5420_KFC_CORE_RESET0 | EXYNOS5420_KFC_ETM_RESET0) << (_nr))
+
 #define EXYNOS5420_BB_CON1					0x0784
 #define EXYNOS5420_BB_SEL_EN					BIT(31)
 #define EXYNOS5420_BB_PMOS_EN					BIT(7)
#3 lore raw

PATCH v2 1/1 ARM: EXYNOS: reset Little cores when cpu is up

Hello Krzysztof,

Quoted 40 lines · Krzysztof Kozlowski
Quoted 32 lines · Chanho Park

The cpu booting of exynos5422 has been still broken since we discussed it in last year[1]. This patch is inspired from Odroid XU3
code (Actually, it was from samsung exynos vendor kernel)[2]. This weird reset code was founded exynos5420 octa cores series SoCs and only required for the first boot core is the Little core (Cortex A7). Some of the exynos5420 boards and all of the exynos5422 boards will require this code.

There is two ways to check the little core is the first cpu. One is checking GPG2CON[1] GPIO value and the other is checking the cluster number of the first cpu. I selected the latter because it's more easier than the former.

[1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html [2]:https://patchwork.kernel.org/patch/6782891/

Cc Kevin Hilman <[email protected]>
Cc Javier Martinez Canillas <[email protected]>
Cc Krzysztof Kozlowski <[email protected]>

---
Changes from v1:
.kfc to Little (Cortex A7) and eagle to big (Cortex A15) .append comments about waiting SPARE2 register

Changes since RFC:
.drop checking soc_is_exynos5800 to extend this codes to
exynos5420/5422 boards.
.kfc cores will be reset only if the cpu0 is kfc core. .Rebase top of the kukjin's for-next branch

Quoted 3 lines
 arch/arm/mach-exynos/mcpm-exynos.c | 25 ++++++++++++++++++++++++-
 arch/arm/mach-exynos/regs-pmu.h    |  6 ++++++
 2 files changed, 30 insertions(+), 1 deletion(-)

Thanks for updating the patch. Remaining minor nit about comment style (/* on first line) can be fixed while applying.

Quoted 8 lines

The patch works good, after disabling bL switcher I have 8 cores running:

Tested on Odroid XU4:

It's 4.3 merge window so the patch will go probably to v4.4.

Isn't this material for the v4.3 -rc cycle since it's fixing a bug (CPUs not booting)? So I don't think that's necessary to wait for v4.4.

But I was expecting another re-spin as from Abhilash's latest comments [0], it seems the same workaround is needed in arch/arm/mach-exynos/platsmp.c to avoid the CPU's not booting issue when CCI is disabled in DT and the MCPM backend is bypassed.

Although I guess that could be also made as a follow up patch.

Quoted 4 lines

Best regards,
Krzysztof

[0]: http://www.spinics.net/lists/arm-kernel/msg442399.html

Best regards,

Signature · 3 lines
Javier Martinez Canillas
Open Source Group
Samsung Research America
#4 lore raw

PATCH v2 1/1 ARM: EXYNOS: reset Little cores when cpu is up

Quoted 49 lines · Javier Martinez Canillas

Hello Krzysztof,

Quoted 46 lines · Krzysztof Kozlowski
Quoted 32 lines · Chanho Park

The cpu booting of exynos5422 has been still broken since we discussed it in last year[1]. This patch is inspired from Odroid XU3
code (Actually, it was from samsung exynos vendor kernel)[2]. This weird reset code was founded exynos5420 octa cores series SoCs and only required for the first boot core is the Little core (Cortex A7). Some of the exynos5420 boards and all of the exynos5422 boards will require this code.

There is two ways to check the little core is the first cpu. One is checking GPG2CON[1] GPIO value and the other is checking the cluster number of the first cpu. I selected the latter because it's more easier than the former.

[1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html [2]:https://patchwork.kernel.org/patch/6782891/

Cc Kevin Hilman <[email protected]>
Cc Javier Martinez Canillas <[email protected]>
Cc Krzysztof Kozlowski <[email protected]>

---
Changes from v1:
.kfc to Little (Cortex A7) and eagle to big (Cortex A15) .append comments about waiting SPARE2 register

Changes since RFC:
.drop checking soc_is_exynos5800 to extend this codes to
exynos5420/5422 boards.
.kfc cores will be reset only if the cpu0 is kfc core. .Rebase top of the kukjin's for-next branch

Quoted 3 lines
 arch/arm/mach-exynos/mcpm-exynos.c | 25 ++++++++++++++++++++++++-
 arch/arm/mach-exynos/regs-pmu.h    |  6 ++++++
 2 files changed, 30 insertions(+), 1 deletion(-)

Thanks for updating the patch. Remaining minor nit about comment style (/* on first line) can be fixed while applying.

The patch works good, after disabling bL switcher I have 8 cores running:

Tested on Odroid XU4:

Quoted 5 lines
Quoted 2 lines

It's 4.3 merge window so the patch will go probably to v4.4.

Isn't this material for the v4.3 -rc cycle since it's fixing a bug (CPUs not booting)? So I don't think that's necessary to wait for v4.4.

It is a bug fix but:
1. Not a fix for regression introduced in current merge window,
2. There may be more subtle issues like the one mentioned below, not found yet (probably no one tested it with all possible configurations),

so I don't think rushing with the patch to mainline is good idea.

However your comment reminds me about stable. This actually looks like a candidate for stable.

Quoted 7 lines

But I was expecting another re-spin as from Abhilash's latest comments [0], it seems the same workaround is needed in arch/arm/mach-exynos/platsmp.c to avoid the CPU's not booting issue when CCI is disabled in DT and the MCPM backend is bypassed.

Although I guess that could be also made as a follow up patch.

Chanho patch fixes only MCPM path. Regular path (platsmp, firmware) is not affected so I would expect a following patch.

Best regards,
Krzysztof

Quoted 10 lines
Quoted 5 lines

Best regards,
Krzysztof

[0]: http://www.spinics.net/lists/arm-kernel/msg442399.html

Best regards,

#5 lore raw

PATCH v2 1/1 ARM: EXYNOS: reset Little cores when cpu is up

Hello Krzysztof,

Quoted 50 lines · Krzysztof Kozlowski
Quoted 49 lines · Javier Martinez Canillas

Hello Krzysztof,

Quoted 46 lines · Krzysztof Kozlowski
Quoted 32 lines · Chanho Park

The cpu booting of exynos5422 has been still broken since we discussed it in last year[1]. This patch is inspired from Odroid XU3
code (Actually, it was from samsung exynos vendor kernel)[2]. This weird reset code was founded exynos5420 octa cores series SoCs and only required for the first boot core is the Little core (Cortex A7). Some of the exynos5420 boards and all of the exynos5422 boards will require this code.

There is two ways to check the little core is the first cpu. One is checking GPG2CON[1] GPIO value and the other is checking the cluster number of the first cpu. I selected the latter because it's more easier than the former.

[1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html [2]:https://patchwork.kernel.org/patch/6782891/

Cc Kevin Hilman <[email protected]>
Cc Javier Martinez Canillas <[email protected]>
Cc Krzysztof Kozlowski <[email protected]>

---
Changes from v1:
.kfc to Little (Cortex A7) and eagle to big (Cortex A15) .append comments about waiting SPARE2 register

Changes since RFC:
.drop checking soc_is_exynos5800 to extend this codes to
exynos5420/5422 boards.
.kfc cores will be reset only if the cpu0 is kfc core. .Rebase top of the kukjin's for-next branch

Quoted 3 lines
 arch/arm/mach-exynos/mcpm-exynos.c | 25 ++++++++++++++++++++++++-
 arch/arm/mach-exynos/regs-pmu.h    |  6 ++++++
 2 files changed, 30 insertions(+), 1 deletion(-)

Thanks for updating the patch. Remaining minor nit about comment style (/* on first line) can be fixed while applying.

The patch works good, after disabling bL switcher I have 8 cores running:

Tested on Odroid XU4:

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

It's 4.3 merge window so the patch will go probably to v4.4.

Isn't this material for the v4.3 -rc cycle since it's fixing a bug (CPUs not booting)? So I don't think that's necessary to wait for v4.4.

It is a bug fix but:
1. Not a fix for regression introduced in current merge window,

I thought the -rc cycle was for stabilization and fix not only regressions introduced during the merge window but also long standing issues.

Quoted 3 lines

2. There may be more subtle issues like the one mentioned below, not found yet (probably no one tested it with all possible configurations),

Right, this is indeed a better reason to wait for v4.4.

Quoted 2 lines

so I don't think rushing with the patch to mainline is good idea.

Yes, agreed.

Quoted 9 lines

However your comment reminds me about stable. This actually looks like a candidate for stable.

Quoted 6 lines

But I was expecting another re-spin as from Abhilash's latest comments [0], it seems the same workaround is needed in arch/arm/mach-exynos/platsmp.c to avoid the CPU's not booting issue when CCI is disabled in DT and the MCPM backend is bypassed.

Quoted 5 lines
Quoted 1 line

Although I guess that could be also made as a follow up patch.

Chanho patch fixes only MCPM path. Regular path (platsmp, firmware) is not affected so I would expect a following patch.

Ok, hopefully the non MCPM path can also be fixed before v4.4.

Quoted 4 lines

Best regards,
Krzysztof

Quoted 1 line

Best regards,

Signature · 3 lines
Javier Martinez Canillas
Open Source Group
Samsung Research America
#6 lore raw

PATCH v2 1/1 ARM: EXYNOS: reset Little cores when cpu is up

Quoted 56 lines · Javier Martinez Canillas

Hello Krzysztof,

Quoted 53 lines · Krzysztof Kozlowski
Quoted 52 lines · Javier Martinez Canillas

Hello Krzysztof,

Quoted 48 lines · Krzysztof Kozlowski
Quoted 32 lines · Chanho Park

The cpu booting of exynos5422 has been still broken since we discussed it in last year[1]. This patch is inspired from Odroid XU3
code (Actually, it was from samsung exynos vendor kernel)[2]. This weird reset code was founded exynos5420 octa cores series SoCs and only required for the first boot core is the Little core (Cortex A7). Some of the exynos5420 boards and all of the exynos5422 boards will require this code.

There is two ways to check the little core is the first cpu. One is checking GPG2CON[1] GPIO value and the other is checking the cluster number of the first cpu. I selected the latter because it's more easier than the former.

[1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html [2]:https://patchwork.kernel.org/patch/6782891/

Cc Kevin Hilman <[email protected]>
Cc Javier Martinez Canillas <[email protected]>
Cc Krzysztof Kozlowski <[email protected]>

---
Changes from v1:
.kfc to Little (Cortex A7) and eagle to big (Cortex A15) .append comments about waiting SPARE2 register

Changes since RFC:
.drop checking soc_is_exynos5800 to extend this codes to
exynos5420/5422 boards.
.kfc cores will be reset only if the cpu0 is kfc core. .Rebase top of the kukjin's for-next branch

Quoted 3 lines
 arch/arm/mach-exynos/mcpm-exynos.c | 25 ++++++++++++++++++++++++-
 arch/arm/mach-exynos/regs-pmu.h    |  6 ++++++
 2 files changed, 30 insertions(+), 1 deletion(-)

Thanks for updating the patch. Remaining minor nit about comment style (/* on first line) can be fixed while applying.

The patch works good, after disabling bL switcher I have 8 cores running:

Tested on Odroid XU4:

It's 4.3 merge window so the patch will go probably to v4.4.

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

Isn't this material for the v4.3 -rc cycle since it's fixing a bug (CPUs not booting)? So I don't think that's necessary to wait for v4.4.

It is a bug fix but:
1. Not a fix for regression introduced in current merge window,

I thought the -rc cycle was for stabilization and fix not only regressions introduced during the merge window but also long standing issues.

It's all subtle. Sometimes it also depends on the mood of maintainer... A lot of fixes for different issues are merged in -rc and in the same time they are rejected because they are too late and they don't fix regression from merge window. Anyway I used the argument #1 in combination with #2.

Best regards,
Krzysztof

Quoted 36 lines
Quoted 4 lines

2. There may be more subtle issues like the one mentioned below, not found yet (probably no one tested it with all possible configurations),

Right, this is indeed a better reason to wait for v4.4.

Quoted 2 lines

so I don't think rushing with the patch to mainline is good idea.

Yes, agreed.

Quoted 9 lines

However your comment reminds me about stable. This actually looks like a candidate for stable.

Quoted 6 lines

But I was expecting another re-spin as from Abhilash's latest comments [0], it seems the same workaround is needed in arch/arm/mach-exynos/platsmp.c to avoid the CPU's not booting issue when CCI is disabled in DT and the MCPM backend is bypassed.

Quoted 5 lines
Quoted 1 line

Although I guess that could be also made as a follow up patch.

Chanho patch fixes only MCPM path. Regular path (platsmp, firmware) is not affected so I would expect a following patch.

Ok, hopefully the non MCPM path can also be fixed before v4.4.

Quoted 4 lines

Best regards,
Krzysztof

Quoted 1 line

Best regards,

#7 lore raw

PATCH v2 1/1 ARM: EXYNOS: reset Little cores when cpu is up

Quoted 66 lines · Krzysztof Kozlowski
Quoted 56 lines · Javier Martinez Canillas

Hello Krzysztof,

Quoted 53 lines · Krzysztof Kozlowski
Quoted 52 lines · Javier Martinez Canillas

Hello Krzysztof,

Quoted 48 lines · Krzysztof Kozlowski
Quoted 32 lines · Chanho Park

The cpu booting of exynos5422 has been still broken since we discussed it in last year[1]. This patch is inspired from Odroid XU3
code (Actually, it was from samsung exynos vendor kernel)[2]. This weird reset code was founded exynos5420 octa cores series SoCs and only required for the first boot core is the Little core (Cortex A7). Some of the exynos5420 boards and all of the exynos5422 boards will require this code.

There is two ways to check the little core is the first cpu. One is checking GPG2CON[1] GPIO value and the other is checking the cluster number of the first cpu. I selected the latter because it's more easier than the former.

[1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html [2]:https://patchwork.kernel.org/patch/6782891/

Cc Kevin Hilman <[email protected]>
Cc Javier Martinez Canillas <[email protected]>
Cc Krzysztof Kozlowski <[email protected]>

---
Changes from v1:
.kfc to Little (Cortex A7) and eagle to big (Cortex A15) .append comments about waiting SPARE2 register

Changes since RFC:
.drop checking soc_is_exynos5800 to extend this codes to
exynos5420/5422 boards.
.kfc cores will be reset only if the cpu0 is kfc core. .Rebase top of the kukjin's for-next branch

Quoted 3 lines
 arch/arm/mach-exynos/mcpm-exynos.c | 25 ++++++++++++++++++++++++-
 arch/arm/mach-exynos/regs-pmu.h    |  6 ++++++
 2 files changed, 30 insertions(+), 1 deletion(-)

Thanks for updating the patch. Remaining minor nit about comment style (/* on first line) can be fixed while applying.

The patch works good, after disabling bL switcher I have 8 cores running:

Tested on Odroid XU4:

It's 4.3 merge window so the patch will go probably to v4.4.

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

Isn't this material for the v4.3 -rc cycle since it's fixing a bug (CPUs not booting)? So I don't think that's necessary to wait for v4.4.

It is a bug fix but:
1. Not a fix for regression introduced in current merge window,

I thought the -rc cycle was for stabilization and fix not only regressions introduced during the merge window but also long standing issues.

Quoted 23 lines

It's all subtle. Sometimes it also depends on the mood of maintainer... A lot of fixes for different issues are merged in -rc and in the same time they are rejected because they are too late and they don't fix regression from merge window. Anyway I used the argument #1 in combination with #2.

Best regards,
Krzysztof

Quoted 14 lines
Quoted 4 lines

2. There may be more subtle issues like the one mentioned below, not found yet (probably no one tested it with all possible configurations),

Right, this is indeed a better reason to wait for v4.4.

Quoted 2 lines

so I don't think rushing with the patch to mainline is good idea.

Yes, agreed.

Quoted 2 lines

However your comment reminds me about stable. This actually looks like a candidate for stable.

I applied the patch to my repo marking it as stable backport for v4.1+. Earlier kernels would require manual backporting/rebasing.

It should be in linux-next soon. Let's see how it turns out. If no one complains than I actually agree with Javier's opinion of sending this to v4.3.

Best regards,
Krzysztof