* [PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
@ 2013-02-18 13:46 ` Magnus Damm
0 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-18 13:46 UTC (permalink / raw)
To: linux-arm-kernel
ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
[PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
[PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
[PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
[PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
[PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
[PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
[PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
[PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
Finalize the SCU rework by performing minor fixes and converting
the r8a7779 SMP code to make use of common scu_power_mode() code
and the early SCU setup code in headsmp-scu.S.
Also, to save a few line remove hotplug.c while at it.
The only remaining itch to scratch here is to fix up CPU Hotplug
of CPU0 on r8a7779, but for that to happen we first need to start
accounting for spurious interrupts during shut down.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
No known dependencies apart from previous SMP cleanup series
"[PATCH 00/06] ARM: shmobile: SMP Cortex-A9 SCU rework"
Written against -next in renesas.git.
arch/arm/mach-shmobile/Makefile | 1
arch/arm/mach-shmobile/headsmp-scu.S | 3
arch/arm/mach-shmobile/hotplug.c | 64 ---------
arch/arm/mach-shmobile/include/mach/common.h | 10 -
arch/arm/mach-shmobile/smp-r8a7779.c | 173 +++++++++++++-------------
arch/arm/mach-shmobile/smp-sh73a0.c | 11 +
6 files changed, 99 insertions(+), 163 deletions(-)
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
2013-02-18 13:46 ` Magnus Damm
@ 2013-02-18 13:46 ` Magnus Damm
-1 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-18 13:46 UTC (permalink / raw)
To: linux-arm-kernel
From: Magnus Damm <damm@opensource.se>
Rework the early SCU setup code in headsmp-scu.S to read
the base address in the same way as we use to fetch the
address of the invalidation function.
Reported-by: Bastian Hecht <hechtb@gmail.com>
Signed-off-by: Magnus Damm <damm@opensource.se>
---
Tested on r8a7779. Feel free to add incrementally or fold into:
[PATCH 05/06] ARM: shmobile: Common shmobile_scu_base in headsmp-scu.S
Bastian, does this solve your problem?
arch/arm/mach-shmobile/headsmp-scu.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- 0001/arch/arm/mach-shmobile/headsmp-scu.S
+++ work/arch/arm/mach-shmobile/headsmp-scu.S 2013-02-18 16:17:58.000000000 +0900
@@ -39,7 +39,7 @@ ENTRY(shmobile_secondary_vector_scu)
mrc p15, 0, r0, c0, c0, 5 @ read MIPDR
and r0, r0, #3 @ mask out cpu ID
lsl r0, r0, #3 @ we will shift by cpu_id * 8 bits
- ldr r1, =shmobile_scu_base
+ ldr r1, 2f
ldr r1, [r1] @ SCU base address
ldr r2, [r1, #8] @ SCU Power Status Register
mov r3, #3
@@ -48,6 +48,7 @@ ENTRY(shmobile_secondary_vector_scu)
ldr pc, 1f
1: .long shmobile_invalidate_start - PAGE_OFFSET + PLAT_PHYS_OFFSET
+2: .long shmobile_scu_base - PAGE_OFFSET + PLAT_PHYS_OFFSET
ENDPROC(shmobile_secondary_vector_scu)
.text
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
@ 2013-02-18 13:46 ` Magnus Damm
0 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-18 13:46 UTC (permalink / raw)
To: linux-arm-kernel
From: Magnus Damm <damm@opensource.se>
Rework the early SCU setup code in headsmp-scu.S to read
the base address in the same way as we use to fetch the
address of the invalidation function.
Reported-by: Bastian Hecht <hechtb@gmail.com>
Signed-off-by: Magnus Damm <damm@opensource.se>
---
Tested on r8a7779. Feel free to add incrementally or fold into:
[PATCH 05/06] ARM: shmobile: Common shmobile_scu_base in headsmp-scu.S
Bastian, does this solve your problem?
arch/arm/mach-shmobile/headsmp-scu.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- 0001/arch/arm/mach-shmobile/headsmp-scu.S
+++ work/arch/arm/mach-shmobile/headsmp-scu.S 2013-02-18 16:17:58.000000000 +0900
@@ -39,7 +39,7 @@ ENTRY(shmobile_secondary_vector_scu)
mrc p15, 0, r0, c0, c0, 5 @ read MIPDR
and r0, r0, #3 @ mask out cpu ID
lsl r0, r0, #3 @ we will shift by cpu_id * 8 bits
- ldr r1, =shmobile_scu_base
+ ldr r1, 2f
ldr r1, [r1] @ SCU base address
ldr r2, [r1, #8] @ SCU Power Status Register
mov r3, #3
@@ -48,6 +48,7 @@ ENTRY(shmobile_secondary_vector_scu)
ldr pc, 1f
1: .long shmobile_invalidate_start - PAGE_OFFSET + PLAT_PHYS_OFFSET
+2: .long shmobile_scu_base - PAGE_OFFSET + PLAT_PHYS_OFFSET
ENDPROC(shmobile_secondary_vector_scu)
.text
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
2013-02-18 13:46 ` Magnus Damm
@ 2013-02-18 14:57 ` Bastian Hecht
-1 siblings, 0 replies; 46+ messages in thread
From: Bastian Hecht @ 2013-02-18 14:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi Magnus,
yes using the physical address works.
Thanks,
Bastian
2013/2/18 Magnus Damm <magnus.damm@gmail.com>:
> From: Magnus Damm <damm@opensource.se>
>
> Rework the early SCU setup code in headsmp-scu.S to read
> the base address in the same way as we use to fetch the
> address of the invalidation function.
>
> Reported-by: Bastian Hecht <hechtb@gmail.com>
> Signed-off-by: Magnus Damm <damm@opensource.se>
> ---
>
> Tested on r8a7779. Feel free to add incrementally or fold into:
> [PATCH 05/06] ARM: shmobile: Common shmobile_scu_base in headsmp-scu.S
>
> Bastian, does this solve your problem?
>
> arch/arm/mach-shmobile/headsmp-scu.S | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- 0001/arch/arm/mach-shmobile/headsmp-scu.S
> +++ work/arch/arm/mach-shmobile/headsmp-scu.S 2013-02-18 16:17:58.000000000 +0900
> @@ -39,7 +39,7 @@ ENTRY(shmobile_secondary_vector_scu)
> mrc p15, 0, r0, c0, c0, 5 @ read MIPDR
> and r0, r0, #3 @ mask out cpu ID
> lsl r0, r0, #3 @ we will shift by cpu_id * 8 bits
> - ldr r1, =shmobile_scu_base
> + ldr r1, 2f
> ldr r1, [r1] @ SCU base address
> ldr r2, [r1, #8] @ SCU Power Status Register
> mov r3, #3
> @@ -48,6 +48,7 @@ ENTRY(shmobile_secondary_vector_scu)
>
> ldr pc, 1f
> 1: .long shmobile_invalidate_start - PAGE_OFFSET + PLAT_PHYS_OFFSET
> +2: .long shmobile_scu_base - PAGE_OFFSET + PLAT_PHYS_OFFSET
> ENDPROC(shmobile_secondary_vector_scu)
>
> .text
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
@ 2013-02-18 14:57 ` Bastian Hecht
0 siblings, 0 replies; 46+ messages in thread
From: Bastian Hecht @ 2013-02-18 14:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi Magnus,
yes using the physical address works.
Thanks,
Bastian
2013/2/18 Magnus Damm <magnus.damm@gmail.com>:
> From: Magnus Damm <damm@opensource.se>
>
> Rework the early SCU setup code in headsmp-scu.S to read
> the base address in the same way as we use to fetch the
> address of the invalidation function.
>
> Reported-by: Bastian Hecht <hechtb@gmail.com>
> Signed-off-by: Magnus Damm <damm@opensource.se>
> ---
>
> Tested on r8a7779. Feel free to add incrementally or fold into:
> [PATCH 05/06] ARM: shmobile: Common shmobile_scu_base in headsmp-scu.S
>
> Bastian, does this solve your problem?
>
> arch/arm/mach-shmobile/headsmp-scu.S | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- 0001/arch/arm/mach-shmobile/headsmp-scu.S
> +++ work/arch/arm/mach-shmobile/headsmp-scu.S 2013-02-18 16:17:58.000000000 +0900
> @@ -39,7 +39,7 @@ ENTRY(shmobile_secondary_vector_scu)
> mrc p15, 0, r0, c0, c0, 5 @ read MIPDR
> and r0, r0, #3 @ mask out cpu ID
> lsl r0, r0, #3 @ we will shift by cpu_id * 8 bits
> - ldr r1, =shmobile_scu_base
> + ldr r1, 2f
> ldr r1, [r1] @ SCU base address
> ldr r2, [r1, #8] @ SCU Power Status Register
> mov r3, #3
> @@ -48,6 +48,7 @@ ENTRY(shmobile_secondary_vector_scu)
>
> ldr pc, 1f
> 1: .long shmobile_invalidate_start - PAGE_OFFSET + PLAT_PHYS_OFFSET
> +2: .long shmobile_scu_base - PAGE_OFFSET + PLAT_PHYS_OFFSET
> ENDPROC(shmobile_secondary_vector_scu)
>
> .text
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
2013-02-18 13:46 ` Magnus Damm
@ 2013-02-18 13:47 ` Magnus Damm
-1 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-18 13:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Magnus Damm <damm@opensource.se>
Rework the IOMEM() usage for the SCU base address in the
case of sh73a0. Removes recently introduced build warnings:
arch/arm/mach-shmobile/smp-sh73a0.c:45:15: warning: initialization makes integer from pointer without a cast [enabled by default]
arch/arm/mach-shmobile/smp-sh73a0.c:45:15: warning: (near initialization for 'twd_local_timer.res[0].start') [enabled by default]
arch/arm/mach-shmobile/smp-sh73a0.c:45:15: warning: initialization makes integer from pointer without a cast [enabled by default]
/arch/arm/mach-shmobile/smp-sh73a0.c:45:15: warning: (near initialization for 'twd_local_timer.res[0].end') [enabled by default]
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/smp-sh73a0.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 0001/arch/arm/mach-shmobile/smp-sh73a0.c
+++ work/arch/arm/mach-shmobile/smp-sh73a0.c 2013-02-18 16:24:05.000000000 +0900
@@ -39,7 +39,7 @@
#define PSTR_SHUTDOWN_MODE 3
-#define SH73A0_SCU_BASE IOMEM(0xf0000000)
+#define SH73A0_SCU_BASE 0xf0000000
#ifdef CONFIG_HAVE_ARM_TWD
static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, SH73A0_SCU_BASE + 0x600, 29);
@@ -81,7 +81,7 @@ static void __init sh73a0_smp_prepare_cp
static void __init sh73a0_smp_init_cpus(void)
{
/* setup sh73a0 specific SCU base */
- shmobile_scu_base = SH73A0_SCU_BASE;
+ shmobile_scu_base = IOMEM(SH73A0_SCU_BASE);
shmobile_smp_init_cpus(scu_get_core_count(shmobile_scu_base));
}
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
@ 2013-02-18 13:47 ` Magnus Damm
0 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-18 13:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Magnus Damm <damm@opensource.se>
Rework the IOMEM() usage for the SCU base address in the
case of sh73a0. Removes recently introduced build warnings:
arch/arm/mach-shmobile/smp-sh73a0.c:45:15: warning: initialization makes integer from pointer without a cast [enabled by default]
arch/arm/mach-shmobile/smp-sh73a0.c:45:15: warning: (near initialization for 'twd_local_timer.res[0].start') [enabled by default]
arch/arm/mach-shmobile/smp-sh73a0.c:45:15: warning: initialization makes integer from pointer without a cast [enabled by default]
/arch/arm/mach-shmobile/smp-sh73a0.c:45:15: warning: (near initialization for 'twd_local_timer.res[0].end') [enabled by default]
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/smp-sh73a0.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 0001/arch/arm/mach-shmobile/smp-sh73a0.c
+++ work/arch/arm/mach-shmobile/smp-sh73a0.c 2013-02-18 16:24:05.000000000 +0900
@@ -39,7 +39,7 @@
#define PSTR_SHUTDOWN_MODE 3
-#define SH73A0_SCU_BASE IOMEM(0xf0000000)
+#define SH73A0_SCU_BASE 0xf0000000
#ifdef CONFIG_HAVE_ARM_TWD
static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, SH73A0_SCU_BASE + 0x600, 29);
@@ -81,7 +81,7 @@ static void __init sh73a0_smp_prepare_cp
static void __init sh73a0_smp_init_cpus(void)
{
/* setup sh73a0 specific SCU base */
- shmobile_scu_base = SH73A0_SCU_BASE;
+ shmobile_scu_base = IOMEM(SH73A0_SCU_BASE);
shmobile_smp_init_cpus(scu_get_core_count(shmobile_scu_base));
}
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
2013-02-18 13:47 ` Magnus Damm
@ 2013-02-18 14:39 ` Arnd Bergmann
-1 siblings, 0 replies; 46+ messages in thread
From: Arnd Bergmann @ 2013-02-18 14:39 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 18 February 2013, Magnus Damm wrote:
> #define PSTR_SHUTDOWN_MODE 3
>
> -#define SH73A0_SCU_BASE IOMEM(0xf0000000)
> +#define SH73A0_SCU_BASE 0xf0000000
>
> #ifdef CONFIG_HAVE_ARM_TWD
> static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, SH73A0_SCU_BASE + 0x600, 29);
> @@ -81,7 +81,7 @@ static void __init sh73a0_smp_prepare_cp
> static void __init sh73a0_smp_init_cpus(void)
> {
> /* setup sh73a0 specific SCU base */
> - shmobile_scu_base = SH73A0_SCU_BASE;
> + shmobile_scu_base = IOMEM(SH73A0_SCU_BASE);
>
> shmobile_smp_init_cpus(scu_get_core_count(shmobile_scu_base));
> }
Ok, this gets rid of the warning, but I'm a bit worried about
how it is hardwiring the fact that the SCU physical address has
the same bit pattern as the __iomem token.
While I realize that you already rely on this in a lot of places
in the shmobile code, I see a red light going off every time I read
code like this, and it is not any more logical than the previous
version.
It would be nice to keep these address spaces separate at least
in new code, mostly in order to not confuse reviewers with code
that is based on assumptions which are not generally true, but also
to be more flexible with the virtual memory layout. On a related
topic, you are using an entire 256 MB section of your virtual
address space for sh73a0 and sh7372 and 160 MB for r8a7740. Putting
less of that into the identity mapped area would free up space for
vmalloc, but it's hard to prove that doing this is correct when
you have all sorts of code using a hardcoded virtual MMIO address
token.
Arnd
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
@ 2013-02-18 14:39 ` Arnd Bergmann
0 siblings, 0 replies; 46+ messages in thread
From: Arnd Bergmann @ 2013-02-18 14:39 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 18 February 2013, Magnus Damm wrote:
> #define PSTR_SHUTDOWN_MODE 3
>
> -#define SH73A0_SCU_BASE IOMEM(0xf0000000)
> +#define SH73A0_SCU_BASE 0xf0000000
>
> #ifdef CONFIG_HAVE_ARM_TWD
> static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, SH73A0_SCU_BASE + 0x600, 29);
> @@ -81,7 +81,7 @@ static void __init sh73a0_smp_prepare_cp
> static void __init sh73a0_smp_init_cpus(void)
> {
> /* setup sh73a0 specific SCU base */
> - shmobile_scu_base = SH73A0_SCU_BASE;
> + shmobile_scu_base = IOMEM(SH73A0_SCU_BASE);
>
> shmobile_smp_init_cpus(scu_get_core_count(shmobile_scu_base));
> }
Ok, this gets rid of the warning, but I'm a bit worried about
how it is hardwiring the fact that the SCU physical address has
the same bit pattern as the __iomem token.
While I realize that you already rely on this in a lot of places
in the shmobile code, I see a red light going off every time I read
code like this, and it is not any more logical than the previous
version.
It would be nice to keep these address spaces separate at least
in new code, mostly in order to not confuse reviewers with code
that is based on assumptions which are not generally true, but also
to be more flexible with the virtual memory layout. On a related
topic, you are using an entire 256 MB section of your virtual
address space for sh73a0 and sh7372 and 160 MB for r8a7740. Putting
less of that into the identity mapped area would free up space for
vmalloc, but it's hard to prove that doing this is correct when
you have all sorts of code using a hardcoded virtual MMIO address
token.
Arnd
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
2013-02-18 14:39 ` Arnd Bergmann
@ 2013-02-18 14:44 ` Arnd Bergmann
-1 siblings, 0 replies; 46+ messages in thread
From: Arnd Bergmann @ 2013-02-18 14:44 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 18 February 2013, Arnd Bergmann wrote:
> Ok, this gets rid of the warning, but I'm a bit worried about
> how it is hardwiring the fact that the SCU physical address has
> the same bit pattern as the __iomem token.
>
> While I realize that you already rely on this in a lot of places
> in the shmobile code, I see a red light going off every time I read
> code like this, and it is not any more logical than the previous
> version.
>
> It would be nice to keep these address spaces separate at least
> in new code, mostly in order to not confuse reviewers with code
> that is based on assumptions which are not generally true, but also
> to be more flexible with the virtual memory layout. On a related
> topic, you are using an entire 256 MB section of your virtual
> address space for sh73a0 and sh7372 and 160 MB for r8a7740. Putting
> less of that into the identity mapped area would free up space for
> vmalloc, but it's hard to prove that doing this is correct when
> you have all sorts of code using a hardcoded virtual MMIO address
> token.
To clarify my rant: I'm absolutely fine with this code going in
for now, but I'd like to see a long-term plan about what to do
with the hardcoded virtual address hacks.
Arnd
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
@ 2013-02-18 14:44 ` Arnd Bergmann
0 siblings, 0 replies; 46+ messages in thread
From: Arnd Bergmann @ 2013-02-18 14:44 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 18 February 2013, Arnd Bergmann wrote:
> Ok, this gets rid of the warning, but I'm a bit worried about
> how it is hardwiring the fact that the SCU physical address has
> the same bit pattern as the __iomem token.
>
> While I realize that you already rely on this in a lot of places
> in the shmobile code, I see a red light going off every time I read
> code like this, and it is not any more logical than the previous
> version.
>
> It would be nice to keep these address spaces separate at least
> in new code, mostly in order to not confuse reviewers with code
> that is based on assumptions which are not generally true, but also
> to be more flexible with the virtual memory layout. On a related
> topic, you are using an entire 256 MB section of your virtual
> address space for sh73a0 and sh7372 and 160 MB for r8a7740. Putting
> less of that into the identity mapped area would free up space for
> vmalloc, but it's hard to prove that doing this is correct when
> you have all sorts of code using a hardcoded virtual MMIO address
> token.
To clarify my rant: I'm absolutely fine with this code going in
for now, but I'd like to see a long-term plan about what to do
with the hardcoded virtual address hacks.
Arnd
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
2013-02-18 14:44 ` Arnd Bergmann
@ 2013-02-25 14:30 ` Magnus Damm
-1 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-25 14:30 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Feb 18, 2013 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 18 February 2013, Arnd Bergmann wrote:
>> Ok, this gets rid of the warning, but I'm a bit worried about
>> how it is hardwiring the fact that the SCU physical address has
>> the same bit pattern as the __iomem token.
>>
>> While I realize that you already rely on this in a lot of places
>> in the shmobile code, I see a red light going off every time I read
>> code like this, and it is not any more logical than the previous
>> version.
>>
>> It would be nice to keep these address spaces separate at least
>> in new code, mostly in order to not confuse reviewers with code
>> that is based on assumptions which are not generally true, but also
>> to be more flexible with the virtual memory layout. On a related
>> topic, you are using an entire 256 MB section of your virtual
>> address space for sh73a0 and sh7372 and 160 MB for r8a7740. Putting
>> less of that into the identity mapped area would free up space for
>> vmalloc, but it's hard to prove that doing this is correct when
>> you have all sorts of code using a hardcoded virtual MMIO address
>> token.
>
> To clarify my rant: I'm absolutely fine with this code going in
> for now, but I'd like to see a long-term plan about what to do
> with the hardcoded virtual address hacks.
Thanks for the clarification.
For mach-shmobile the three major components that rely on entity
mapped memory maps are SMP, clocks and power domains. The clocks
should really be moved in the common direction and I intend to get
people to focus on that in the not too distant future (next 6 months).
Power domains should be rather easy to convert. SMP tends to be a bit
of a headache because last time I checked I couldn't use ioremap() at
->smp_init_cpus() time. What I recall is that ioremap() hanged instead
of returning something.
Anyway, if I track down the ioremap() issue, would it be possible for
you to check if it can be reproduced on some other sub-architecture?
Thanks,
/ magnus
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
@ 2013-02-25 14:30 ` Magnus Damm
0 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-25 14:30 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Feb 18, 2013 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 18 February 2013, Arnd Bergmann wrote:
>> Ok, this gets rid of the warning, but I'm a bit worried about
>> how it is hardwiring the fact that the SCU physical address has
>> the same bit pattern as the __iomem token.
>>
>> While I realize that you already rely on this in a lot of places
>> in the shmobile code, I see a red light going off every time I read
>> code like this, and it is not any more logical than the previous
>> version.
>>
>> It would be nice to keep these address spaces separate at least
>> in new code, mostly in order to not confuse reviewers with code
>> that is based on assumptions which are not generally true, but also
>> to be more flexible with the virtual memory layout. On a related
>> topic, you are using an entire 256 MB section of your virtual
>> address space for sh73a0 and sh7372 and 160 MB for r8a7740. Putting
>> less of that into the identity mapped area would free up space for
>> vmalloc, but it's hard to prove that doing this is correct when
>> you have all sorts of code using a hardcoded virtual MMIO address
>> token.
>
> To clarify my rant: I'm absolutely fine with this code going in
> for now, but I'd like to see a long-term plan about what to do
> with the hardcoded virtual address hacks.
Thanks for the clarification.
For mach-shmobile the three major components that rely on entity
mapped memory maps are SMP, clocks and power domains. The clocks
should really be moved in the common direction and I intend to get
people to focus on that in the not too distant future (next 6 months).
Power domains should be rather easy to convert. SMP tends to be a bit
of a headache because last time I checked I couldn't use ioremap() at
->smp_init_cpus() time. What I recall is that ioremap() hanged instead
of returning something.
Anyway, if I track down the ioremap() issue, would it be possible for
you to check if it can be reproduced on some other sub-architecture?
Thanks,
/ magnus
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
2013-02-25 14:30 ` Magnus Damm
@ 2013-02-26 10:18 ` Arnd Bergmann
-1 siblings, 0 replies; 46+ messages in thread
From: Arnd Bergmann @ 2013-02-26 10:18 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 25 February 2013, Magnus Damm wrote:
> For mach-shmobile the three major components that rely on entity
> mapped memory maps are SMP, clocks and power domains. The clocks
> should really be moved in the common direction and I intend to get
> people to focus on that in the not too distant future (next 6 months).
> Power domains should be rather easy to convert. SMP tends to be a bit
> of a headache because last time I checked I couldn't use ioremap() at
> ->smp_init_cpus() time. What I recall is that ioremap() hanged instead
> of returning something.
>
> Anyway, if I track down the ioremap() issue, would it be possible for
> you to check if it can be reproduced on some other sub-architecture?
You are right that ioremap cannot be used from ->smp_init_cpus() and any
code called from there needs to use a static mapping for accessing
MMIO registers. There is nothing wrong with that. There are in fact
three distinct reasons why people use static MMIO mappings with
iotable_init():
1. For MMIO registers that need to be accessed before ioremap works.
This usually means the SMP startup and the early printk (which I
believe shmobile is not using).
2. For getting hugetlb mappings of MMIO registers into the kernel
address space. If you have a lot of registers in the same area,
using a single TLB to map them is more efficient, even when
accessing the registers through ioremap from a device driver.
3. For hardcoding the virtual address to a location that is passed
to device drivers as compile-time constants.
The first two are absolutely fine, there are no objections to those.
The third one is tradtitionally used on a lot of the older platforms,
but with the multiplatform work, we are moving away from it, towards
passing resources in the platform device (ideally from DT, but that
is an orthogonal question here). AFAICT, shmobile is the only "modern"
platform that still relies on fixed virtual addresses, and it is the
only one I know that uses a mapping where the virtual address equals
the physical address.
Arnd
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
@ 2013-02-26 10:18 ` Arnd Bergmann
0 siblings, 0 replies; 46+ messages in thread
From: Arnd Bergmann @ 2013-02-26 10:18 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 25 February 2013, Magnus Damm wrote:
> For mach-shmobile the three major components that rely on entity
> mapped memory maps are SMP, clocks and power domains. The clocks
> should really be moved in the common direction and I intend to get
> people to focus on that in the not too distant future (next 6 months).
> Power domains should be rather easy to convert. SMP tends to be a bit
> of a headache because last time I checked I couldn't use ioremap() at
> ->smp_init_cpus() time. What I recall is that ioremap() hanged instead
> of returning something.
>
> Anyway, if I track down the ioremap() issue, would it be possible for
> you to check if it can be reproduced on some other sub-architecture?
You are right that ioremap cannot be used from ->smp_init_cpus() and any
code called from there needs to use a static mapping for accessing
MMIO registers. There is nothing wrong with that. There are in fact
three distinct reasons why people use static MMIO mappings with
iotable_init():
1. For MMIO registers that need to be accessed before ioremap works.
This usually means the SMP startup and the early printk (which I
believe shmobile is not using).
2. For getting hugetlb mappings of MMIO registers into the kernel
address space. If you have a lot of registers in the same area,
using a single TLB to map them is more efficient, even when
accessing the registers through ioremap from a device driver.
3. For hardcoding the virtual address to a location that is passed
to device drivers as compile-time constants.
The first two are absolutely fine, there are no objections to those.
The third one is tradtitionally used on a lot of the older platforms,
but with the multiplatform work, we are moving away from it, towards
passing resources in the platform device (ideally from DT, but that
is an orthogonal question here). AFAICT, shmobile is the only "modern"
platform that still relies on fixed virtual addresses, and it is the
only one I know that uses a mapping where the virtual address equals
the physical address.
Arnd
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
2013-02-26 10:18 ` Arnd Bergmann
@ 2013-02-26 15:20 ` Magnus Damm
-1 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-26 15:20 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 26, 2013 at 7:18 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 25 February 2013, Magnus Damm wrote:
>> For mach-shmobile the three major components that rely on entity
>> mapped memory maps are SMP, clocks and power domains. The clocks
>> should really be moved in the common direction and I intend to get
>> people to focus on that in the not too distant future (next 6 months).
>> Power domains should be rather easy to convert. SMP tends to be a bit
>> of a headache because last time I checked I couldn't use ioremap() at
>> ->smp_init_cpus() time. What I recall is that ioremap() hanged instead
>> of returning something.
>>
>> Anyway, if I track down the ioremap() issue, would it be possible for
>> you to check if it can be reproduced on some other sub-architecture?
>
> You are right that ioremap cannot be used from ->smp_init_cpus() and any
> code called from there needs to use a static mapping for accessing
> MMIO registers. There is nothing wrong with that. There are in fact
> three distinct reasons why people use static MMIO mappings with
> iotable_init():
>
> 1. For MMIO registers that need to be accessed before ioremap works.
> This usually means the SMP startup and the early printk (which I
> believe shmobile is not using).
Thanks for describing these.
Is there any particular reason why SMP startup needs to happen earlier
than ioremap() is available?
From a hardware point of view on Cortex-A9 the SCU needs to be enabled
and the number of available cores need to be determined. The SCU
enabling can probably happen later and the number of cores are already
limited to the kernel configuration maximum number of cores setting,
so it should be possible to use that to size any early per-cpu
variables if needed. So I wonder why we're not enabling SMP later than
we actually do? Using maxcpus=1 and late CPU hotplug from user space
is certainly working fine.
Regarding early printk, you are correct that we're not using that ARM
specific debug output. Instead we are relying on earlyprintk via early
platform devices. This way we are not only multi-soc and multi-subarch
already, we are also multi-arch. For really early console output we
rely on the clocks and pin function being initialized by the boot
loader and we also require 1:1 entity mappings so we can use printouts
before ioremap() is functional. So yes, we like using 1:1 virt-phys
memory maps for early printouts.
We do not use early printk with DT at this point. If we would be able
to move the SMP init later then perhaps we could debug SMP issues with
serial ports described by DT in the future?
> 2. For getting hugetlb mappings of MMIO registers into the kernel
> address space. If you have a lot of registers in the same area,
> using a single TLB to map them is more efficient, even when
> accessing the registers through ioremap from a device driver.
Sure.
> 3. For hardcoding the virtual address to a location that is passed
> to device drivers as compile-time constants.
>
> The first two are absolutely fine, there are no objections to those.
Ok. As you probably can tell by now - I would like to get rid of the
SMP case if possible.
> The third one is tradtitionally used on a lot of the older platforms,
> but with the multiplatform work, we are moving away from it, towards
> passing resources in the platform device (ideally from DT, but that
> is an orthogonal question here). AFAICT, shmobile is the only "modern"
> platform that still relies on fixed virtual addresses, and it is the
> only one I know that uses a mapping where the virtual address equals
> the physical address.
The 1:1 mapping is deliberately chosen to be simple. So in the case
when people do register I/O without ioremap() then at least we can
look up the address in the data sheet. I've seen too many examples of
people not using ioremap and instead inventing their own magic mapping
table with undocumented hard coded address that map to something even
more unknown. Of course we should be aiming at using ioremap(). If we
for some reason can't then we should use 1:1 mappings.
While I agree to move more towards using ioremap(), I can't really see
how this affects our multiplatform situation. Our device drivers have
always been using the driver model and we do never export any virtual
addresses in any header files. If you have any particular area that
you think needs work related to ioremap() then perhaps we can get
together on next conference and talk it through?
As I mentioned before, from my point of view the main limiting factor
for mach-shmobile multiplatform at this point is the clock framework.
The SH clock framework does already support ioremap() though, so it is
just a matter of making the clock code actually use it. And while
we're doing that we may as well solve the multiplatform issue to and
move towards common clocks.
Thanks,
/ magnus
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
@ 2013-02-26 15:20 ` Magnus Damm
0 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-26 15:20 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 26, 2013 at 7:18 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 25 February 2013, Magnus Damm wrote:
>> For mach-shmobile the three major components that rely on entity
>> mapped memory maps are SMP, clocks and power domains. The clocks
>> should really be moved in the common direction and I intend to get
>> people to focus on that in the not too distant future (next 6 months).
>> Power domains should be rather easy to convert. SMP tends to be a bit
>> of a headache because last time I checked I couldn't use ioremap() at
>> ->smp_init_cpus() time. What I recall is that ioremap() hanged instead
>> of returning something.
>>
>> Anyway, if I track down the ioremap() issue, would it be possible for
>> you to check if it can be reproduced on some other sub-architecture?
>
> You are right that ioremap cannot be used from ->smp_init_cpus() and any
> code called from there needs to use a static mapping for accessing
> MMIO registers. There is nothing wrong with that. There are in fact
> three distinct reasons why people use static MMIO mappings with
> iotable_init():
>
> 1. For MMIO registers that need to be accessed before ioremap works.
> This usually means the SMP startup and the early printk (which I
> believe shmobile is not using).
Thanks for describing these.
Is there any particular reason why SMP startup needs to happen earlier
than ioremap() is available?
>From a hardware point of view on Cortex-A9 the SCU needs to be enabled
and the number of available cores need to be determined. The SCU
enabling can probably happen later and the number of cores are already
limited to the kernel configuration maximum number of cores setting,
so it should be possible to use that to size any early per-cpu
variables if needed. So I wonder why we're not enabling SMP later than
we actually do? Using maxcpus=1 and late CPU hotplug from user space
is certainly working fine.
Regarding early printk, you are correct that we're not using that ARM
specific debug output. Instead we are relying on earlyprintk via early
platform devices. This way we are not only multi-soc and multi-subarch
already, we are also multi-arch. For really early console output we
rely on the clocks and pin function being initialized by the boot
loader and we also require 1:1 entity mappings so we can use printouts
before ioremap() is functional. So yes, we like using 1:1 virt-phys
memory maps for early printouts.
We do not use early printk with DT at this point. If we would be able
to move the SMP init later then perhaps we could debug SMP issues with
serial ports described by DT in the future?
> 2. For getting hugetlb mappings of MMIO registers into the kernel
> address space. If you have a lot of registers in the same area,
> using a single TLB to map them is more efficient, even when
> accessing the registers through ioremap from a device driver.
Sure.
> 3. For hardcoding the virtual address to a location that is passed
> to device drivers as compile-time constants.
>
> The first two are absolutely fine, there are no objections to those.
Ok. As you probably can tell by now - I would like to get rid of the
SMP case if possible.
> The third one is tradtitionally used on a lot of the older platforms,
> but with the multiplatform work, we are moving away from it, towards
> passing resources in the platform device (ideally from DT, but that
> is an orthogonal question here). AFAICT, shmobile is the only "modern"
> platform that still relies on fixed virtual addresses, and it is the
> only one I know that uses a mapping where the virtual address equals
> the physical address.
The 1:1 mapping is deliberately chosen to be simple. So in the case
when people do register I/O without ioremap() then at least we can
look up the address in the data sheet. I've seen too many examples of
people not using ioremap and instead inventing their own magic mapping
table with undocumented hard coded address that map to something even
more unknown. Of course we should be aiming at using ioremap(). If we
for some reason can't then we should use 1:1 mappings.
While I agree to move more towards using ioremap(), I can't really see
how this affects our multiplatform situation. Our device drivers have
always been using the driver model and we do never export any virtual
addresses in any header files. If you have any particular area that
you think needs work related to ioremap() then perhaps we can get
together on next conference and talk it through?
As I mentioned before, from my point of view the main limiting factor
for mach-shmobile multiplatform at this point is the clock framework.
The SH clock framework does already support ioremap() though, so it is
just a matter of making the clock code actually use it. And while
we're doing that we may as well solve the multiplatform issue to and
move towards common clocks.
Thanks,
/ magnus
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
2013-02-26 15:20 ` Magnus Damm
@ 2013-02-26 16:12 ` Arnd Bergmann
-1 siblings, 0 replies; 46+ messages in thread
From: Arnd Bergmann @ 2013-02-26 16:12 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 26 February 2013, Magnus Damm wrote:
> On Tue, Feb 26, 2013 at 7:18 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday 25 February 2013, Magnus Damm wrote:
> > You are right that ioremap cannot be used from ->smp_init_cpus() and any
> > code called from there needs to use a static mapping for accessing
> > MMIO registers. There is nothing wrong with that. There are in fact
> > three distinct reasons why people use static MMIO mappings with
> > iotable_init():
> >
> > 1. For MMIO registers that need to be accessed before ioremap works.
> > This usually means the SMP startup and the early printk (which I
> > believe shmobile is not using).
>
> Thanks for describing these.
>
> Is there any particular reason why SMP startup needs to happen earlier
> than ioremap() is available?
I think it's mostly traditional reason I think.
> From a hardware point of view on Cortex-A9 the SCU needs to be enabled
> and the number of available cores need to be determined. The SCU
> enabling can probably happen later and the number of cores are already
> limited to the kernel configuration maximum number of cores setting,
> so it should be possible to use that to size any early per-cpu
> variables if needed. So I wonder why we're not enabling SMP later than
> we actually do? Using maxcpus=1 and late CPU hotplug from user space
> is certainly working fine.
AFAIK, on Cortex-A15 we already rely on getting the number of cores from
the device tree, which is also available at the right time, without
the need for an early mapping. It would not be hard to do the same
on Cortex-A9. Then again, the static mapping there does not do harm
as I said.
> Regarding early printk, you are correct that we're not using that ARM
> specific debug output. Instead we are relying on earlyprintk via early
> platform devices. This way we are not only multi-soc and multi-subarch
> already, we are also multi-arch. For really early console output we
> rely on the clocks and pin function being initialized by the boot
> loader and we also require 1:1 entity mappings so we can use printouts
> before ioremap() is functional. So yes, we like using 1:1 virt-phys
> memory maps for early printouts.
Ok.
> We do not use early printk with DT at this point. If we would be able
> to move the SMP init later then perhaps we could debug SMP issues with
> serial ports described by DT in the future?
>
> > 3. For hardcoding the virtual address to a location that is passed
> > to device drivers as compile-time constants.
> >
> > The first two are absolutely fine, there are no objections to those.
>
> Ok. As you probably can tell by now - I would like to get rid of the
> SMP case if possible.
I would certainly welcome a patch that moves the SMP initialization
to a later point. I'm not sure if it requires changes to architecture
independent code, but it does sound like a good idea.
> > The third one is tradtitionally used on a lot of the older platforms,
> > but with the multiplatform work, we are moving away from it, towards
> > passing resources in the platform device (ideally from DT, but that
> > is an orthogonal question here). AFAICT, shmobile is the only "modern"
> > platform that still relies on fixed virtual addresses, and it is the
> > only one I know that uses a mapping where the virtual address equals
> > the physical address.
>
> The 1:1 mapping is deliberately chosen to be simple. So in the case
> when people do register I/O without ioremap() then at least we can
> look up the address in the data sheet. I've seen too many examples of
> people not using ioremap and instead inventing their own magic mapping
> table with undocumented hard coded address that map to something even
> more unknown. Of course we should be aiming at using ioremap(). If we
> for some reason can't then we should use 1:1 mappings.
Well, I would argue that when someone doesn't understand the basic
interfaces we expose to device drivers, they probably shouldn't
be writing kernel code. ;)
> While I agree to move more towards using ioremap(), I can't really see
> how this affects our multiplatform situation. Our device drivers have
> always been using the driver model and we do never export any virtual
> addresses in any header files. If you have any particular area that
> you think needs work related to ioremap() then perhaps we can get
> together on next conference and talk it through?
It may not be as bad as I thought. I know that at least the intc
controller is fundamentally built around this assumption (I tried changing
it, and that didn't end well), but that may be the only one, following
the recent cleanup of the pfc driver.
The main worry is probably that people will take the platform code
as example when writing device drivers, and that uses hardcoded
IOMEM() macros. There are probably a couple of instances where that
is the best solution, but for those, I would suggest using offsets
from a base register that gets passed into iotable_init() rather
than literal numbers.
> As I mentioned before, from my point of view the main limiting factor
> for mach-shmobile multiplatform at this point is the clock framework.
> The SH clock framework does already support ioremap() though, so it is
> just a matter of making the clock code actually use it. And while
> we're doing that we may as well solve the multiplatform issue to and
> move towards common clocks.
Ok, good to hear.
Arnd
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
@ 2013-02-26 16:12 ` Arnd Bergmann
0 siblings, 0 replies; 46+ messages in thread
From: Arnd Bergmann @ 2013-02-26 16:12 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 26 February 2013, Magnus Damm wrote:
> On Tue, Feb 26, 2013 at 7:18 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday 25 February 2013, Magnus Damm wrote:
> > You are right that ioremap cannot be used from ->smp_init_cpus() and any
> > code called from there needs to use a static mapping for accessing
> > MMIO registers. There is nothing wrong with that. There are in fact
> > three distinct reasons why people use static MMIO mappings with
> > iotable_init():
> >
> > 1. For MMIO registers that need to be accessed before ioremap works.
> > This usually means the SMP startup and the early printk (which I
> > believe shmobile is not using).
>
> Thanks for describing these.
>
> Is there any particular reason why SMP startup needs to happen earlier
> than ioremap() is available?
I think it's mostly traditional reason I think.
> From a hardware point of view on Cortex-A9 the SCU needs to be enabled
> and the number of available cores need to be determined. The SCU
> enabling can probably happen later and the number of cores are already
> limited to the kernel configuration maximum number of cores setting,
> so it should be possible to use that to size any early per-cpu
> variables if needed. So I wonder why we're not enabling SMP later than
> we actually do? Using maxcpus=1 and late CPU hotplug from user space
> is certainly working fine.
AFAIK, on Cortex-A15 we already rely on getting the number of cores from
the device tree, which is also available at the right time, without
the need for an early mapping. It would not be hard to do the same
on Cortex-A9. Then again, the static mapping there does not do harm
as I said.
> Regarding early printk, you are correct that we're not using that ARM
> specific debug output. Instead we are relying on earlyprintk via early
> platform devices. This way we are not only multi-soc and multi-subarch
> already, we are also multi-arch. For really early console output we
> rely on the clocks and pin function being initialized by the boot
> loader and we also require 1:1 entity mappings so we can use printouts
> before ioremap() is functional. So yes, we like using 1:1 virt-phys
> memory maps for early printouts.
Ok.
> We do not use early printk with DT at this point. If we would be able
> to move the SMP init later then perhaps we could debug SMP issues with
> serial ports described by DT in the future?
>
> > 3. For hardcoding the virtual address to a location that is passed
> > to device drivers as compile-time constants.
> >
> > The first two are absolutely fine, there are no objections to those.
>
> Ok. As you probably can tell by now - I would like to get rid of the
> SMP case if possible.
I would certainly welcome a patch that moves the SMP initialization
to a later point. I'm not sure if it requires changes to architecture
independent code, but it does sound like a good idea.
> > The third one is tradtitionally used on a lot of the older platforms,
> > but with the multiplatform work, we are moving away from it, towards
> > passing resources in the platform device (ideally from DT, but that
> > is an orthogonal question here). AFAICT, shmobile is the only "modern"
> > platform that still relies on fixed virtual addresses, and it is the
> > only one I know that uses a mapping where the virtual address equals
> > the physical address.
>
> The 1:1 mapping is deliberately chosen to be simple. So in the case
> when people do register I/O without ioremap() then at least we can
> look up the address in the data sheet. I've seen too many examples of
> people not using ioremap and instead inventing their own magic mapping
> table with undocumented hard coded address that map to something even
> more unknown. Of course we should be aiming at using ioremap(). If we
> for some reason can't then we should use 1:1 mappings.
Well, I would argue that when someone doesn't understand the basic
interfaces we expose to device drivers, they probably shouldn't
be writing kernel code. ;)
> While I agree to move more towards using ioremap(), I can't really see
> how this affects our multiplatform situation. Our device drivers have
> always been using the driver model and we do never export any virtual
> addresses in any header files. If you have any particular area that
> you think needs work related to ioremap() then perhaps we can get
> together on next conference and talk it through?
It may not be as bad as I thought. I know that at least the intc
controller is fundamentally built around this assumption (I tried changing
it, and that didn't end well), but that may be the only one, following
the recent cleanup of the pfc driver.
The main worry is probably that people will take the platform code
as example when writing device drivers, and that uses hardcoded
IOMEM() macros. There are probably a couple of instances where that
is the best solution, but for those, I would suggest using offsets
from a base register that gets passed into iotable_init() rather
than literal numbers.
> As I mentioned before, from my point of view the main limiting factor
> for mach-shmobile multiplatform at this point is the clock framework.
> The SH clock framework does already support ioremap() though, so it is
> just a matter of making the clock code actually use it. And while
> we're doing that we may as well solve the multiplatform issue to and
> move towards common clocks.
Ok, good to hear.
Arnd
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
2013-02-26 16:12 ` Arnd Bergmann
@ 2013-03-06 7:15 ` Magnus Damm
-1 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-03-06 7:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
On Wed, Feb 27, 2013 at 1:12 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 26 February 2013, Magnus Damm wrote:
>> On Tue, Feb 26, 2013 at 7:18 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Monday 25 February 2013, Magnus Damm wrote:
>> > You are right that ioremap cannot be used from ->smp_init_cpus() and any
>> > code called from there needs to use a static mapping for accessing
>> > MMIO registers. There is nothing wrong with that. There are in fact
>> > three distinct reasons why people use static MMIO mappings with
>> > iotable_init():
>> >
>> > 1. For MMIO registers that need to be accessed before ioremap works.
>> > This usually means the SMP startup and the early printk (which I
>> > believe shmobile is not using).
>>
>> Thanks for describing these.
>>
>> Is there any particular reason why SMP startup needs to happen earlier
>> than ioremap() is available?
>
> I think it's mostly traditional reason I think.
I think so too.
>> From a hardware point of view on Cortex-A9 the SCU needs to be enabled
>> and the number of available cores need to be determined. The SCU
>> enabling can probably happen later and the number of cores are already
>> limited to the kernel configuration maximum number of cores setting,
>> so it should be possible to use that to size any early per-cpu
>> variables if needed. So I wonder why we're not enabling SMP later than
>> we actually do? Using maxcpus=1 and late CPU hotplug from user space
>> is certainly working fine.
>
> AFAIK, on Cortex-A15 we already rely on getting the number of cores from
> the device tree, which is also available at the right time, without
> the need for an early mapping. It would not be hard to do the same
> on Cortex-A9. Then again, the static mapping there does not do harm
> as I said.
I understand that you feel that static mapping in the case of SMP is acceptable.
>> Regarding early printk, you are correct that we're not using that ARM
>> specific debug output. Instead we are relying on earlyprintk via early
>> platform devices. This way we are not only multi-soc and multi-subarch
>> already, we are also multi-arch. For really early console output we
>> rely on the clocks and pin function being initialized by the boot
>> loader and we also require 1:1 entity mappings so we can use printouts
>> before ioremap() is functional. So yes, we like using 1:1 virt-phys
>> memory maps for early printouts.
>
> Ok.
>
>> We do not use early printk with DT at this point. If we would be able
>> to move the SMP init later then perhaps we could debug SMP issues with
>> serial ports described by DT in the future?
>>
>> > 3. For hardcoding the virtual address to a location that is passed
>> > to device drivers as compile-time constants.
>> >
>> > The first two are absolutely fine, there are no objections to those.
>>
>> Ok. As you probably can tell by now - I would like to get rid of the
>> SMP case if possible.
>
> I would certainly welcome a patch that moves the SMP initialization
> to a later point. I'm not sure if it requires changes to architecture
> independent code, but it does sound like a good idea.
Good to hear that that this may be a move in the right direction!
>> > The third one is tradtitionally used on a lot of the older platforms,
>> > but with the multiplatform work, we are moving away from it, towards
>> > passing resources in the platform device (ideally from DT, but that
>> > is an orthogonal question here). AFAICT, shmobile is the only "modern"
>> > platform that still relies on fixed virtual addresses, and it is the
>> > only one I know that uses a mapping where the virtual address equals
>> > the physical address.
>>
>> The 1:1 mapping is deliberately chosen to be simple. So in the case
>> when people do register I/O without ioremap() then at least we can
>> look up the address in the data sheet. I've seen too many examples of
>> people not using ioremap and instead inventing their own magic mapping
>> table with undocumented hard coded address that map to something even
>> more unknown. Of course we should be aiming at using ioremap(). If we
>> for some reason can't then we should use 1:1 mappings.
>
> Well, I would argue that when someone doesn't understand the basic
> interfaces we expose to device drivers, they probably shouldn't
> be writing kernel code. ;)
I am not sure how this is related to device drivers actually. The
example I was thinking about was snapshot-style development on some
ancient kernel version. In that case the developers simply seemed to
follow the at-that-point common coding style in the ARM architecture.
I am happy to see that the ARM architecture code is getting cleaner
bit by bit.
>> While I agree to move more towards using ioremap(), I can't really see
>> how this affects our multiplatform situation. Our device drivers have
>> always been using the driver model and we do never export any virtual
>> addresses in any header files. If you have any particular area that
>> you think needs work related to ioremap() then perhaps we can get
>> together on next conference and talk it through?
>
> It may not be as bad as I thought. I know that at least the intc
> controller is fundamentally built around this assumption (I tried changing
> it, and that didn't end well), but that may be the only one, following
> the recent cleanup of the pfc driver.
Uhm, I am not sure where you got that idea about the INTC driver.
Allow me to clarify.
Regarding the shared INTC code base I recall implementing ioremap()
support there 2010, feel free to search the archives for "[PATCH] sh:
INTC ioremap support V2".
As for actual SoC support, this varies with interrupt controller and
SoC. It is basically a matter of if I/O memory windows are passed to
the INTC driver or not.
A typical example would be sh7372 that has two interrupt controllers:
INTCA and INTCS. In intc-sh7372.c you have the following:
INTCA (no resources - using the 0xe6xxxxxx 1:1 mapping):
static DECLARE_INTC_DESC(intca_desc, "sh7372-intca",
intca_vectors, intca_groups,
intca_mask_registers, intca_prio_registers,
NULL);
INTCS (resources - relies on ioremap()):
static struct resource intcs_resources[] __initdata = {
[0] = {
.start = 0xffd20000,
.end = 0xffd201ff,
.flags = IORESOURCE_MEM,
},
[1] = {
.start = 0xffd50000,
.end = 0xffd501ff,
.flags = IORESOURCE_MEM,
}
};
static struct intc_desc intcs_desc __initdata = {
.name = "sh7372-intcs",
.force_enable = ENABLED_INTCS,
.skip_syscore_suspend = true,
.resource = intcs_resources,
.num_resources = ARRAY_SIZE(intcs_resources),
.hw = INTC_HW_DESC(intcs_vectors, intcs_groups, intcs_mask_registers,
intcs_prio_registers, NULL, NULL),
};
Adding I/O memory resources to the already existing INTC controllers
is not a particularly difficult task. Would you like us to perform
such a change?
> The main worry is probably that people will take the platform code
> as example when writing device drivers, and that uses hardcoded
> IOMEM() macros. There are probably a couple of instances where that
> is the best solution, but for those, I would suggest using offsets
> from a base register that gets passed into iotable_init() rather
> than literal numbers.
If you look at all our regular device drivers we use a base register +
offset. In such cases that kind of design makes a lot of sense.
In the case of INTC and PFC we do not follow this style. This since
each version of the hardware block varies quite a bit and there often
are a couple of I/O memory windows associated with each hardware block
instance. So the design has been to use the same physical addresses as
are described in the data sheet, and for bit fields and register width
follow the same type of representation as the data sheet to allow easy
development and validation.
Keep in mind that in arch/sh and arch/arm we have over 30 different
variants of INTC hardware blocks.
So to summarize, INTC, PFC and CPG (clocks) have ioremap support
included in the actual driver code. If the SoC makes use of it or not
is a different question. =)
>> As I mentioned before, from my point of view the main limiting factor
>> for mach-shmobile multiplatform at this point is the clock framework.
>> The SH clock framework does already support ioremap() though, so it is
>> just a matter of making the clock code actually use it. And while
>> we're doing that we may as well solve the multiplatform issue to and
>> move towards common clocks.
>
> Ok, good to hear.
So how would you like to proceed with this matter?
Thanks,
/ magnus
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
@ 2013-03-06 7:15 ` Magnus Damm
0 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-03-06 7:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
On Wed, Feb 27, 2013 at 1:12 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 26 February 2013, Magnus Damm wrote:
>> On Tue, Feb 26, 2013 at 7:18 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Monday 25 February 2013, Magnus Damm wrote:
>> > You are right that ioremap cannot be used from ->smp_init_cpus() and any
>> > code called from there needs to use a static mapping for accessing
>> > MMIO registers. There is nothing wrong with that. There are in fact
>> > three distinct reasons why people use static MMIO mappings with
>> > iotable_init():
>> >
>> > 1. For MMIO registers that need to be accessed before ioremap works.
>> > This usually means the SMP startup and the early printk (which I
>> > believe shmobile is not using).
>>
>> Thanks for describing these.
>>
>> Is there any particular reason why SMP startup needs to happen earlier
>> than ioremap() is available?
>
> I think it's mostly traditional reason I think.
I think so too.
>> From a hardware point of view on Cortex-A9 the SCU needs to be enabled
>> and the number of available cores need to be determined. The SCU
>> enabling can probably happen later and the number of cores are already
>> limited to the kernel configuration maximum number of cores setting,
>> so it should be possible to use that to size any early per-cpu
>> variables if needed. So I wonder why we're not enabling SMP later than
>> we actually do? Using maxcpus=1 and late CPU hotplug from user space
>> is certainly working fine.
>
> AFAIK, on Cortex-A15 we already rely on getting the number of cores from
> the device tree, which is also available at the right time, without
> the need for an early mapping. It would not be hard to do the same
> on Cortex-A9. Then again, the static mapping there does not do harm
> as I said.
I understand that you feel that static mapping in the case of SMP is acceptable.
>> Regarding early printk, you are correct that we're not using that ARM
>> specific debug output. Instead we are relying on earlyprintk via early
>> platform devices. This way we are not only multi-soc and multi-subarch
>> already, we are also multi-arch. For really early console output we
>> rely on the clocks and pin function being initialized by the boot
>> loader and we also require 1:1 entity mappings so we can use printouts
>> before ioremap() is functional. So yes, we like using 1:1 virt-phys
>> memory maps for early printouts.
>
> Ok.
>
>> We do not use early printk with DT at this point. If we would be able
>> to move the SMP init later then perhaps we could debug SMP issues with
>> serial ports described by DT in the future?
>>
>> > 3. For hardcoding the virtual address to a location that is passed
>> > to device drivers as compile-time constants.
>> >
>> > The first two are absolutely fine, there are no objections to those.
>>
>> Ok. As you probably can tell by now - I would like to get rid of the
>> SMP case if possible.
>
> I would certainly welcome a patch that moves the SMP initialization
> to a later point. I'm not sure if it requires changes to architecture
> independent code, but it does sound like a good idea.
Good to hear that that this may be a move in the right direction!
>> > The third one is tradtitionally used on a lot of the older platforms,
>> > but with the multiplatform work, we are moving away from it, towards
>> > passing resources in the platform device (ideally from DT, but that
>> > is an orthogonal question here). AFAICT, shmobile is the only "modern"
>> > platform that still relies on fixed virtual addresses, and it is the
>> > only one I know that uses a mapping where the virtual address equals
>> > the physical address.
>>
>> The 1:1 mapping is deliberately chosen to be simple. So in the case
>> when people do register I/O without ioremap() then at least we can
>> look up the address in the data sheet. I've seen too many examples of
>> people not using ioremap and instead inventing their own magic mapping
>> table with undocumented hard coded address that map to something even
>> more unknown. Of course we should be aiming at using ioremap(). If we
>> for some reason can't then we should use 1:1 mappings.
>
> Well, I would argue that when someone doesn't understand the basic
> interfaces we expose to device drivers, they probably shouldn't
> be writing kernel code. ;)
I am not sure how this is related to device drivers actually. The
example I was thinking about was snapshot-style development on some
ancient kernel version. In that case the developers simply seemed to
follow the at-that-point common coding style in the ARM architecture.
I am happy to see that the ARM architecture code is getting cleaner
bit by bit.
>> While I agree to move more towards using ioremap(), I can't really see
>> how this affects our multiplatform situation. Our device drivers have
>> always been using the driver model and we do never export any virtual
>> addresses in any header files. If you have any particular area that
>> you think needs work related to ioremap() then perhaps we can get
>> together on next conference and talk it through?
>
> It may not be as bad as I thought. I know that at least the intc
> controller is fundamentally built around this assumption (I tried changing
> it, and that didn't end well), but that may be the only one, following
> the recent cleanup of the pfc driver.
Uhm, I am not sure where you got that idea about the INTC driver.
Allow me to clarify.
Regarding the shared INTC code base I recall implementing ioremap()
support there 2010, feel free to search the archives for "[PATCH] sh:
INTC ioremap support V2".
As for actual SoC support, this varies with interrupt controller and
SoC. It is basically a matter of if I/O memory windows are passed to
the INTC driver or not.
A typical example would be sh7372 that has two interrupt controllers:
INTCA and INTCS. In intc-sh7372.c you have the following:
INTCA (no resources - using the 0xe6xxxxxx 1:1 mapping):
static DECLARE_INTC_DESC(intca_desc, "sh7372-intca",
intca_vectors, intca_groups,
intca_mask_registers, intca_prio_registers,
NULL);
INTCS (resources - relies on ioremap()):
static struct resource intcs_resources[] __initdata = {
[0] = {
.start = 0xffd20000,
.end = 0xffd201ff,
.flags = IORESOURCE_MEM,
},
[1] = {
.start = 0xffd50000,
.end = 0xffd501ff,
.flags = IORESOURCE_MEM,
}
};
static struct intc_desc intcs_desc __initdata = {
.name = "sh7372-intcs",
.force_enable = ENABLED_INTCS,
.skip_syscore_suspend = true,
.resource = intcs_resources,
.num_resources = ARRAY_SIZE(intcs_resources),
.hw = INTC_HW_DESC(intcs_vectors, intcs_groups, intcs_mask_registers,
intcs_prio_registers, NULL, NULL),
};
Adding I/O memory resources to the already existing INTC controllers
is not a particularly difficult task. Would you like us to perform
such a change?
> The main worry is probably that people will take the platform code
> as example when writing device drivers, and that uses hardcoded
> IOMEM() macros. There are probably a couple of instances where that
> is the best solution, but for those, I would suggest using offsets
> from a base register that gets passed into iotable_init() rather
> than literal numbers.
If you look at all our regular device drivers we use a base register +
offset. In such cases that kind of design makes a lot of sense.
In the case of INTC and PFC we do not follow this style. This since
each version of the hardware block varies quite a bit and there often
are a couple of I/O memory windows associated with each hardware block
instance. So the design has been to use the same physical addresses as
are described in the data sheet, and for bit fields and register width
follow the same type of representation as the data sheet to allow easy
development and validation.
Keep in mind that in arch/sh and arch/arm we have over 30 different
variants of INTC hardware blocks.
So to summarize, INTC, PFC and CPG (clocks) have ioremap support
included in the actual driver code. If the SoC makes use of it or not
is a different question. =)
>> As I mentioned before, from my point of view the main limiting factor
>> for mach-shmobile multiplatform at this point is the clock framework.
>> The SH clock framework does already support ioremap() though, so it is
>> just a matter of making the clock code actually use it. And while
>> we're doing that we may as well solve the multiplatform issue to and
>> move towards common clocks.
>
> Ok, good to hear.
So how would you like to proceed with this matter?
Thanks,
/ magnus
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
2013-02-18 13:46 ` Magnus Damm
@ 2013-02-18 13:47 ` Magnus Damm
-1 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-18 13:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Magnus Damm <damm@opensource.se>
Rework the IOMEM() usage for the SCU base address in the
case of r8a7779. Adjusts the TWD to use R8A7779_SCU_BASE.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/smp-r8a7779.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- 0003/arch/arm/mach-shmobile/smp-r8a7779.c
+++ work/arch/arm/mach-shmobile/smp-r8a7779.c 2013-02-18 16:21:10.000000000 +0900
@@ -32,7 +32,7 @@
#include <asm/smp_twd.h>
#define AVECR IOMEM(0xfe700040)
-#define R8A7779_SCU_BASE IOMEM(0xf0000000)
+#define R8A7779_SCU_BASE 0xf0000000
static struct r8a7779_pm_ch r8a7779_ch_cpu1 = {
.chan_offs = 0x40, /* PWRSR0 .. PWRER0 */
@@ -59,8 +59,7 @@ static struct r8a7779_pm_ch *r8a7779_ch_
};
#ifdef CONFIG_HAVE_ARM_TWD
-static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, 0xf0000600, 29);
-
+static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, R8A7779_SCU_BASE + 0x600, 29);
void __init r8a7779_register_twd(void)
{
twd_local_timer_register(&twd_local_timer);
@@ -178,7 +177,7 @@ static void __init r8a7779_smp_prepare_c
static void __init r8a7779_smp_init_cpus(void)
{
/* setup r8a7779 specific SCU base */
- shmobile_scu_base = R8A7779_SCU_BASE;
+ shmobile_scu_base = IOMEM(R8A7779_SCU_BASE);
shmobile_smp_init_cpus(scu_get_core_count(shmobile_scu_base));
}
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
@ 2013-02-18 13:47 ` Magnus Damm
0 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-18 13:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Magnus Damm <damm@opensource.se>
Rework the IOMEM() usage for the SCU base address in the
case of r8a7779. Adjusts the TWD to use R8A7779_SCU_BASE.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/smp-r8a7779.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- 0003/arch/arm/mach-shmobile/smp-r8a7779.c
+++ work/arch/arm/mach-shmobile/smp-r8a7779.c 2013-02-18 16:21:10.000000000 +0900
@@ -32,7 +32,7 @@
#include <asm/smp_twd.h>
#define AVECR IOMEM(0xfe700040)
-#define R8A7779_SCU_BASE IOMEM(0xf0000000)
+#define R8A7779_SCU_BASE 0xf0000000
static struct r8a7779_pm_ch r8a7779_ch_cpu1 = {
.chan_offs = 0x40, /* PWRSR0 .. PWRER0 */
@@ -59,8 +59,7 @@ static struct r8a7779_pm_ch *r8a7779_ch_
};
#ifdef CONFIG_HAVE_ARM_TWD
-static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, 0xf0000600, 29);
-
+static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, R8A7779_SCU_BASE + 0x600, 29);
void __init r8a7779_register_twd(void)
{
twd_local_timer_register(&twd_local_timer);
@@ -178,7 +177,7 @@ static void __init r8a7779_smp_prepare_c
static void __init r8a7779_smp_init_cpus(void)
{
/* setup r8a7779 specific SCU base */
- shmobile_scu_base = R8A7779_SCU_BASE;
+ shmobile_scu_base = IOMEM(R8A7779_SCU_BASE);
shmobile_smp_init_cpus(scu_get_core_count(shmobile_scu_base));
}
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
2013-02-18 13:46 ` Magnus Damm
@ 2013-02-18 13:47 ` Magnus Damm
-1 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-18 13:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Magnus Damm <damm@opensource.se>
Update the r8a7779 CPU Hotplug code to use SCU PSR
to wait for the target CPU core. Previously the
shared code in hotplug.c was used to let cpu_kill()
wait for cpu_die(). With this change in place the
r8a7779 SMP code does not depend on hotplug.c anymore.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/smp-r8a7779.c | 38 ++++++++++++++++++++++++++++------
1 file changed, 32 insertions(+), 6 deletions(-)
--- 0004/arch/arm/mach-shmobile/smp-r8a7779.c
+++ work/arch/arm/mach-shmobile/smp-r8a7779.c 2013-02-18 22:04:24.000000000 +0900
@@ -26,6 +26,7 @@
#include <linux/irqchip/arm-gic.h>
#include <mach/common.h>
#include <mach/r8a7779.h>
+#include <asm/cacheflush.h>
#include <asm/smp_plat.h>
#include <asm/smp_scu.h>
#include <asm/smp_twd.h>
@@ -68,6 +69,16 @@ void __init r8a7779_register_twd(void)
}
#endif
+static int r8a7779_scu_psr_core_disabled(int cpu)
+{
+ unsigned long mask = 3 << (cpu * 8);
+
+ if ((__raw_readl(shmobile_scu_base + 8) & mask) = mask)
+ return 1;
+
+ return 0;
+}
+
static void modify_scu_cpu_psr(unsigned long set, unsigned long clr)
{
void __iomem *scu_base = shmobile_scu_base;
@@ -89,9 +100,6 @@ static int r8a7779_platform_cpu_kill(uns
cpu = cpu_logical_map(cpu);
- /* disable cache coherency */
- modify_scu_cpu_psr(3 << (cpu * 8), 0);
-
if (cpu < ARRAY_SIZE(r8a7779_ch_cpu))
ch = r8a7779_ch_cpu[cpu];
@@ -110,7 +118,7 @@ static int __maybe_unused r8a7779_cpu_ki
* finish before asking SoC-specific code to power off the CPU core.
*/
for (k = 0; k < 1000; k++) {
- if (shmobile_cpu_is_dead(cpu))
+ if (r8a7779_scu_psr_core_disabled(cpu))
return r8a7779_platform_cpu_kill(cpu);
mdelay(1);
@@ -119,6 +127,24 @@ static int __maybe_unused r8a7779_cpu_ki
return 0;
}
+static void __maybe_unused r8a7779_cpu_die(unsigned int cpu)
+{
+ dsb();
+ flush_cache_all();
+
+ /* disable cache coherency */
+ modify_scu_cpu_psr(3 << (cpu * 8), 0);
+
+ /* Endless loop until power off from r8a7779_cpu_kill() */
+ while (1)
+ cpu_do_idle();
+}
+
+static int __maybe_unused r8a7779_cpu_disable(unsigned int cpu)
+{
+ /* only CPU1->3 have power domains, do not allow hotplug of CPU0 */
+ return cpu = 0 ? -EPERM : 0;
+}
static void __cpuinit r8a7779_secondary_init(unsigned int cpu)
{
@@ -179,7 +205,7 @@ struct smp_operations r8a7779_smp_ops _
.smp_boot_secondary = r8a7779_boot_secondary,
#ifdef CONFIG_HOTPLUG_CPU
.cpu_kill = r8a7779_cpu_kill,
- .cpu_die = shmobile_cpu_die,
- .cpu_disable = shmobile_cpu_disable,
+ .cpu_die = r8a7779_cpu_die,
+ .cpu_disable = r8a7779_cpu_disable,
#endif
};
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
@ 2013-02-18 13:47 ` Magnus Damm
0 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-18 13:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Magnus Damm <damm@opensource.se>
Update the r8a7779 CPU Hotplug code to use SCU PSR
to wait for the target CPU core. Previously the
shared code in hotplug.c was used to let cpu_kill()
wait for cpu_die(). With this change in place the
r8a7779 SMP code does not depend on hotplug.c anymore.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/smp-r8a7779.c | 38 ++++++++++++++++++++++++++++------
1 file changed, 32 insertions(+), 6 deletions(-)
--- 0004/arch/arm/mach-shmobile/smp-r8a7779.c
+++ work/arch/arm/mach-shmobile/smp-r8a7779.c 2013-02-18 22:04:24.000000000 +0900
@@ -26,6 +26,7 @@
#include <linux/irqchip/arm-gic.h>
#include <mach/common.h>
#include <mach/r8a7779.h>
+#include <asm/cacheflush.h>
#include <asm/smp_plat.h>
#include <asm/smp_scu.h>
#include <asm/smp_twd.h>
@@ -68,6 +69,16 @@ void __init r8a7779_register_twd(void)
}
#endif
+static int r8a7779_scu_psr_core_disabled(int cpu)
+{
+ unsigned long mask = 3 << (cpu * 8);
+
+ if ((__raw_readl(shmobile_scu_base + 8) & mask) == mask)
+ return 1;
+
+ return 0;
+}
+
static void modify_scu_cpu_psr(unsigned long set, unsigned long clr)
{
void __iomem *scu_base = shmobile_scu_base;
@@ -89,9 +100,6 @@ static int r8a7779_platform_cpu_kill(uns
cpu = cpu_logical_map(cpu);
- /* disable cache coherency */
- modify_scu_cpu_psr(3 << (cpu * 8), 0);
-
if (cpu < ARRAY_SIZE(r8a7779_ch_cpu))
ch = r8a7779_ch_cpu[cpu];
@@ -110,7 +118,7 @@ static int __maybe_unused r8a7779_cpu_ki
* finish before asking SoC-specific code to power off the CPU core.
*/
for (k = 0; k < 1000; k++) {
- if (shmobile_cpu_is_dead(cpu))
+ if (r8a7779_scu_psr_core_disabled(cpu))
return r8a7779_platform_cpu_kill(cpu);
mdelay(1);
@@ -119,6 +127,24 @@ static int __maybe_unused r8a7779_cpu_ki
return 0;
}
+static void __maybe_unused r8a7779_cpu_die(unsigned int cpu)
+{
+ dsb();
+ flush_cache_all();
+
+ /* disable cache coherency */
+ modify_scu_cpu_psr(3 << (cpu * 8), 0);
+
+ /* Endless loop until power off from r8a7779_cpu_kill() */
+ while (1)
+ cpu_do_idle();
+}
+
+static int __maybe_unused r8a7779_cpu_disable(unsigned int cpu)
+{
+ /* only CPU1->3 have power domains, do not allow hotplug of CPU0 */
+ return cpu == 0 ? -EPERM : 0;
+}
static void __cpuinit r8a7779_secondary_init(unsigned int cpu)
{
@@ -179,7 +205,7 @@ struct smp_operations r8a7779_smp_ops _
.smp_boot_secondary = r8a7779_boot_secondary,
#ifdef CONFIG_HOTPLUG_CPU
.cpu_kill = r8a7779_cpu_kill,
- .cpu_die = shmobile_cpu_die,
- .cpu_disable = shmobile_cpu_disable,
+ .cpu_die = r8a7779_cpu_die,
+ .cpu_disable = r8a7779_cpu_disable,
#endif
};
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
2013-02-18 13:46 ` Magnus Damm
@ 2013-02-18 13:47 ` Magnus Damm
-1 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-18 13:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Magnus Damm <damm@opensource.se>
Update the SMP code for R8A7779 to make use of the
shared SCU function scu_power_mode() together with
the early setup code in shmobile_secondary_vector_scu.
With this patch in place the secondary CPUs modify the
SCU setting during early boot instead of letting other
CPUs deal with the coherency setting before boot. In
other words, we used to setup coherency before boot
in r8a7779_boot_secondary() but that bit is now instead
handled by the code in shmobile_secondary_vector_scu.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/smp-r8a7779.c | 32 +++++---------------------------
1 file changed, 5 insertions(+), 27 deletions(-)
--- 0005/arch/arm/mach-shmobile/smp-r8a7779.c
+++ work/arch/arm/mach-shmobile/smp-r8a7779.c 2013-02-18 22:10:26.000000000 +0900
@@ -58,9 +58,6 @@ static struct r8a7779_pm_ch *r8a7779_ch_
[3] = &r8a7779_ch_cpu3,
};
-static DEFINE_SPINLOCK(scu_lock);
-static unsigned long tmp;
-
#ifdef CONFIG_HAVE_ARM_TWD
static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, R8A7779_SCU_BASE + 0x600, 29);
void __init r8a7779_register_twd(void)
@@ -79,20 +76,6 @@ static int r8a7779_scu_psr_core_disabled
return 0;
}
-static void modify_scu_cpu_psr(unsigned long set, unsigned long clr)
-{
- void __iomem *scu_base = shmobile_scu_base;
-
- spin_lock(&scu_lock);
- tmp = __raw_readl(scu_base + 8);
- tmp &= ~clr;
- tmp |= set;
- spin_unlock(&scu_lock);
-
- /* disable cache coherency after releasing the lock */
- __raw_writel(tmp, scu_base + 8);
-}
-
static int r8a7779_platform_cpu_kill(unsigned int cpu)
{
struct r8a7779_pm_ch *ch = NULL;
@@ -133,7 +116,7 @@ static void __maybe_unused r8a7779_cpu_d
flush_cache_all();
/* disable cache coherency */
- modify_scu_cpu_psr(3 << (cpu * 8), 0);
+ scu_power_mode(shmobile_scu_base, SCU_PM_POWEROFF);
/* Endless loop until power off from r8a7779_cpu_kill() */
while (1)
@@ -158,9 +141,6 @@ static int __cpuinit r8a7779_boot_second
cpu = cpu_logical_map(cpu);
- /* enable cache coherency */
- modify_scu_cpu_psr(0, 3 << (cpu * 8));
-
if (cpu < ARRAY_SIZE(r8a7779_ch_cpu))
ch = r8a7779_ch_cpu[cpu];
@@ -172,15 +152,13 @@ static int __cpuinit r8a7779_boot_second
static void __init r8a7779_smp_prepare_cpus(unsigned int max_cpus)
{
- int cpu = cpu_logical_map(0);
-
scu_enable(shmobile_scu_base);
- /* Map the reset vector (in headsmp.S) */
- __raw_writel(__pa(shmobile_secondary_vector), AVECR);
+ /* Map the reset vector (in headsmp-scu.S) */
+ __raw_writel(__pa(shmobile_secondary_vector_scu), AVECR);
- /* enable cache coherency on CPU0 */
- modify_scu_cpu_psr(0, 3 << (cpu * 8));
+ /* enable cache coherency on booting CPU */
+ scu_power_mode(shmobile_scu_base, SCU_PM_NORMAL);
r8a7779_pm_init();
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
@ 2013-02-18 13:47 ` Magnus Damm
0 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-18 13:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Magnus Damm <damm@opensource.se>
Update the SMP code for R8A7779 to make use of the
shared SCU function scu_power_mode() together with
the early setup code in shmobile_secondary_vector_scu.
With this patch in place the secondary CPUs modify the
SCU setting during early boot instead of letting other
CPUs deal with the coherency setting before boot. In
other words, we used to setup coherency before boot
in r8a7779_boot_secondary() but that bit is now instead
handled by the code in shmobile_secondary_vector_scu.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/smp-r8a7779.c | 32 +++++---------------------------
1 file changed, 5 insertions(+), 27 deletions(-)
--- 0005/arch/arm/mach-shmobile/smp-r8a7779.c
+++ work/arch/arm/mach-shmobile/smp-r8a7779.c 2013-02-18 22:10:26.000000000 +0900
@@ -58,9 +58,6 @@ static struct r8a7779_pm_ch *r8a7779_ch_
[3] = &r8a7779_ch_cpu3,
};
-static DEFINE_SPINLOCK(scu_lock);
-static unsigned long tmp;
-
#ifdef CONFIG_HAVE_ARM_TWD
static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, R8A7779_SCU_BASE + 0x600, 29);
void __init r8a7779_register_twd(void)
@@ -79,20 +76,6 @@ static int r8a7779_scu_psr_core_disabled
return 0;
}
-static void modify_scu_cpu_psr(unsigned long set, unsigned long clr)
-{
- void __iomem *scu_base = shmobile_scu_base;
-
- spin_lock(&scu_lock);
- tmp = __raw_readl(scu_base + 8);
- tmp &= ~clr;
- tmp |= set;
- spin_unlock(&scu_lock);
-
- /* disable cache coherency after releasing the lock */
- __raw_writel(tmp, scu_base + 8);
-}
-
static int r8a7779_platform_cpu_kill(unsigned int cpu)
{
struct r8a7779_pm_ch *ch = NULL;
@@ -133,7 +116,7 @@ static void __maybe_unused r8a7779_cpu_d
flush_cache_all();
/* disable cache coherency */
- modify_scu_cpu_psr(3 << (cpu * 8), 0);
+ scu_power_mode(shmobile_scu_base, SCU_PM_POWEROFF);
/* Endless loop until power off from r8a7779_cpu_kill() */
while (1)
@@ -158,9 +141,6 @@ static int __cpuinit r8a7779_boot_second
cpu = cpu_logical_map(cpu);
- /* enable cache coherency */
- modify_scu_cpu_psr(0, 3 << (cpu * 8));
-
if (cpu < ARRAY_SIZE(r8a7779_ch_cpu))
ch = r8a7779_ch_cpu[cpu];
@@ -172,15 +152,13 @@ static int __cpuinit r8a7779_boot_second
static void __init r8a7779_smp_prepare_cpus(unsigned int max_cpus)
{
- int cpu = cpu_logical_map(0);
-
scu_enable(shmobile_scu_base);
- /* Map the reset vector (in headsmp.S) */
- __raw_writel(__pa(shmobile_secondary_vector), AVECR);
+ /* Map the reset vector (in headsmp-scu.S) */
+ __raw_writel(__pa(shmobile_secondary_vector_scu), AVECR);
- /* enable cache coherency on CPU0 */
- modify_scu_cpu_psr(0, 3 << (cpu * 8));
+ /* enable cache coherency on booting CPU */
+ scu_power_mode(shmobile_scu_base, SCU_PM_NORMAL);
r8a7779_pm_init();
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
2013-02-18 13:46 ` Magnus Damm
@ 2013-02-18 13:47 ` Magnus Damm
-1 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-18 13:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Magnus Damm <damm@opensource.se>
Convert the sh73a0 CPU Hotplug code to use a local
implementation of ->cpu_disable(). With this change
in place the sh73a0 SMP code does no longer depend
on hotplug.c.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/smp-sh73a0.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- 0003/arch/arm/mach-shmobile/smp-sh73a0.c
+++ work/arch/arm/mach-shmobile/smp-sh73a0.c 2013-02-18 16:32:37.000000000 +0900
@@ -124,6 +124,11 @@ static void sh73a0_cpu_die(unsigned int
/* Enter shutdown mode */
cpu_do_idle();
}
+
+static int sh73a0_cpu_disable(unsigned int cpu)
+{
+ return 0; /* CPU0 and CPU1 supported */
+}
#endif /* CONFIG_HOTPLUG_CPU */
struct smp_operations sh73a0_smp_ops __initdata = {
@@ -134,6 +139,6 @@ struct smp_operations sh73a0_smp_ops __i
#ifdef CONFIG_HOTPLUG_CPU
.cpu_kill = sh73a0_cpu_kill,
.cpu_die = sh73a0_cpu_die,
- .cpu_disable = shmobile_cpu_disable_any,
+ .cpu_disable = sh73a0_cpu_disable,
#endif
};
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
@ 2013-02-18 13:47 ` Magnus Damm
0 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-18 13:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Magnus Damm <damm@opensource.se>
Convert the sh73a0 CPU Hotplug code to use a local
implementation of ->cpu_disable(). With this change
in place the sh73a0 SMP code does no longer depend
on hotplug.c.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/smp-sh73a0.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- 0003/arch/arm/mach-shmobile/smp-sh73a0.c
+++ work/arch/arm/mach-shmobile/smp-sh73a0.c 2013-02-18 16:32:37.000000000 +0900
@@ -124,6 +124,11 @@ static void sh73a0_cpu_die(unsigned int
/* Enter shutdown mode */
cpu_do_idle();
}
+
+static int sh73a0_cpu_disable(unsigned int cpu)
+{
+ return 0; /* CPU0 and CPU1 supported */
+}
#endif /* CONFIG_HOTPLUG_CPU */
struct smp_operations sh73a0_smp_ops __initdata = {
@@ -134,6 +139,6 @@ struct smp_operations sh73a0_smp_ops __i
#ifdef CONFIG_HOTPLUG_CPU
.cpu_kill = sh73a0_cpu_kill,
.cpu_die = sh73a0_cpu_die,
- .cpu_disable = shmobile_cpu_disable_any,
+ .cpu_disable = sh73a0_cpu_disable,
#endif
};
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
2013-02-18 13:46 ` Magnus Damm
@ 2013-02-18 13:47 ` Magnus Damm
-1 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-18 13:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Magnus Damm <damm@opensource.se>
Update the r8a7779 SMP code and CPU Hotplug in particular
to follow the same style as sh73a0. This means dropping
__maybe_unused for #ifdef CONFIG_HOTPLUG_CPU.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/smp-r8a7779.c | 96 +++++++++++++++++-----------------
1 file changed, 49 insertions(+), 47 deletions(-)
--- 0006/arch/arm/mach-shmobile/smp-r8a7779.c
+++ work/arch/arm/mach-shmobile/smp-r8a7779.c 2013-02-18 22:30:04.000000000 +0900
@@ -66,16 +66,6 @@ void __init r8a7779_register_twd(void)
}
#endif
-static int r8a7779_scu_psr_core_disabled(int cpu)
-{
- unsigned long mask = 3 << (cpu * 8);
-
- if ((__raw_readl(shmobile_scu_base + 8) & mask) = mask)
- return 1;
-
- return 0;
-}
-
static int r8a7779_platform_cpu_kill(unsigned int cpu)
{
struct r8a7779_pm_ch *ch = NULL;
@@ -92,43 +82,6 @@ static int r8a7779_platform_cpu_kill(uns
return ret ? ret : 1;
}
-static int __maybe_unused r8a7779_cpu_kill(unsigned int cpu)
-{
- int k;
-
- /* this function is running on another CPU than the offline target,
- * here we need wait for shutdown code in platform_cpu_die() to
- * finish before asking SoC-specific code to power off the CPU core.
- */
- for (k = 0; k < 1000; k++) {
- if (r8a7779_scu_psr_core_disabled(cpu))
- return r8a7779_platform_cpu_kill(cpu);
-
- mdelay(1);
- }
-
- return 0;
-}
-
-static void __maybe_unused r8a7779_cpu_die(unsigned int cpu)
-{
- dsb();
- flush_cache_all();
-
- /* disable cache coherency */
- scu_power_mode(shmobile_scu_base, SCU_PM_POWEROFF);
-
- /* Endless loop until power off from r8a7779_cpu_kill() */
- while (1)
- cpu_do_idle();
-}
-
-static int __maybe_unused r8a7779_cpu_disable(unsigned int cpu)
-{
- /* only CPU1->3 have power domains, do not allow hotplug of CPU0 */
- return cpu = 0 ? -EPERM : 0;
-}
-
static void __cpuinit r8a7779_secondary_init(unsigned int cpu)
{
gic_secondary_init(0);
@@ -176,6 +129,55 @@ static void __init r8a7779_smp_init_cpus
shmobile_smp_init_cpus(scu_get_core_count(shmobile_scu_base));
}
+#ifdef CONFIG_HOTPLUG_CPU
+static int r8a7779_scu_psr_core_disabled(int cpu)
+{
+ unsigned long mask = 3 << (cpu * 8);
+
+ if ((__raw_readl(shmobile_scu_base + 8) & mask) = mask)
+ return 1;
+
+ return 0;
+}
+
+static int r8a7779_cpu_kill(unsigned int cpu)
+{
+ int k;
+
+ /* this function is running on another CPU than the offline target,
+ * here we need wait for shutdown code in platform_cpu_die() to
+ * finish before asking SoC-specific code to power off the CPU core.
+ */
+ for (k = 0; k < 1000; k++) {
+ if (r8a7779_scu_psr_core_disabled(cpu))
+ return r8a7779_platform_cpu_kill(cpu);
+
+ mdelay(1);
+ }
+
+ return 0;
+}
+
+static void r8a7779_cpu_die(unsigned int cpu)
+{
+ dsb();
+ flush_cache_all();
+
+ /* disable cache coherency */
+ scu_power_mode(shmobile_scu_base, SCU_PM_POWEROFF);
+
+ /* Endless loop until power off from r8a7779_cpu_kill() */
+ while (1)
+ cpu_do_idle();
+}
+
+static int r8a7779_cpu_disable(unsigned int cpu)
+{
+ /* only CPU1->3 have power domains, do not allow hotplug of CPU0 */
+ return cpu = 0 ? -EPERM : 0;
+}
+#endif /* CONFIG_HOTPLUG_CPU */
+
struct smp_operations r8a7779_smp_ops __initdata = {
.smp_init_cpus = r8a7779_smp_init_cpus,
.smp_prepare_cpus = r8a7779_smp_prepare_cpus,
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
@ 2013-02-18 13:47 ` Magnus Damm
0 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-18 13:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Magnus Damm <damm@opensource.se>
Update the r8a7779 SMP code and CPU Hotplug in particular
to follow the same style as sh73a0. This means dropping
__maybe_unused for #ifdef CONFIG_HOTPLUG_CPU.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/smp-r8a7779.c | 96 +++++++++++++++++-----------------
1 file changed, 49 insertions(+), 47 deletions(-)
--- 0006/arch/arm/mach-shmobile/smp-r8a7779.c
+++ work/arch/arm/mach-shmobile/smp-r8a7779.c 2013-02-18 22:30:04.000000000 +0900
@@ -66,16 +66,6 @@ void __init r8a7779_register_twd(void)
}
#endif
-static int r8a7779_scu_psr_core_disabled(int cpu)
-{
- unsigned long mask = 3 << (cpu * 8);
-
- if ((__raw_readl(shmobile_scu_base + 8) & mask) == mask)
- return 1;
-
- return 0;
-}
-
static int r8a7779_platform_cpu_kill(unsigned int cpu)
{
struct r8a7779_pm_ch *ch = NULL;
@@ -92,43 +82,6 @@ static int r8a7779_platform_cpu_kill(uns
return ret ? ret : 1;
}
-static int __maybe_unused r8a7779_cpu_kill(unsigned int cpu)
-{
- int k;
-
- /* this function is running on another CPU than the offline target,
- * here we need wait for shutdown code in platform_cpu_die() to
- * finish before asking SoC-specific code to power off the CPU core.
- */
- for (k = 0; k < 1000; k++) {
- if (r8a7779_scu_psr_core_disabled(cpu))
- return r8a7779_platform_cpu_kill(cpu);
-
- mdelay(1);
- }
-
- return 0;
-}
-
-static void __maybe_unused r8a7779_cpu_die(unsigned int cpu)
-{
- dsb();
- flush_cache_all();
-
- /* disable cache coherency */
- scu_power_mode(shmobile_scu_base, SCU_PM_POWEROFF);
-
- /* Endless loop until power off from r8a7779_cpu_kill() */
- while (1)
- cpu_do_idle();
-}
-
-static int __maybe_unused r8a7779_cpu_disable(unsigned int cpu)
-{
- /* only CPU1->3 have power domains, do not allow hotplug of CPU0 */
- return cpu == 0 ? -EPERM : 0;
-}
-
static void __cpuinit r8a7779_secondary_init(unsigned int cpu)
{
gic_secondary_init(0);
@@ -176,6 +129,55 @@ static void __init r8a7779_smp_init_cpus
shmobile_smp_init_cpus(scu_get_core_count(shmobile_scu_base));
}
+#ifdef CONFIG_HOTPLUG_CPU
+static int r8a7779_scu_psr_core_disabled(int cpu)
+{
+ unsigned long mask = 3 << (cpu * 8);
+
+ if ((__raw_readl(shmobile_scu_base + 8) & mask) == mask)
+ return 1;
+
+ return 0;
+}
+
+static int r8a7779_cpu_kill(unsigned int cpu)
+{
+ int k;
+
+ /* this function is running on another CPU than the offline target,
+ * here we need wait for shutdown code in platform_cpu_die() to
+ * finish before asking SoC-specific code to power off the CPU core.
+ */
+ for (k = 0; k < 1000; k++) {
+ if (r8a7779_scu_psr_core_disabled(cpu))
+ return r8a7779_platform_cpu_kill(cpu);
+
+ mdelay(1);
+ }
+
+ return 0;
+}
+
+static void r8a7779_cpu_die(unsigned int cpu)
+{
+ dsb();
+ flush_cache_all();
+
+ /* disable cache coherency */
+ scu_power_mode(shmobile_scu_base, SCU_PM_POWEROFF);
+
+ /* Endless loop until power off from r8a7779_cpu_kill() */
+ while (1)
+ cpu_do_idle();
+}
+
+static int r8a7779_cpu_disable(unsigned int cpu)
+{
+ /* only CPU1->3 have power domains, do not allow hotplug of CPU0 */
+ return cpu == 0 ? -EPERM : 0;
+}
+#endif /* CONFIG_HOTPLUG_CPU */
+
struct smp_operations r8a7779_smp_ops __initdata = {
.smp_init_cpus = r8a7779_smp_init_cpus,
.smp_prepare_cpus = r8a7779_smp_prepare_cpus,
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
2013-02-18 13:46 ` Magnus Damm
@ 2013-02-18 13:48 ` Magnus Damm
-1 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-18 13:48 UTC (permalink / raw)
To: linux-arm-kernel
From: Magnus Damm <damm@opensource.se>
Each CPU Hotplug implementation for mach-shmobile
is now self-contained, so this change removes unused
helper code in hotplug.c. The two CPU Hotplug capable
SoCs sh73a0 and r8a7779 remain unchanged.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/Makefile | 1
arch/arm/mach-shmobile/hotplug.c | 64 --------------------------
arch/arm/mach-shmobile/include/mach/common.h | 10 ----
3 files changed, 75 deletions(-)
--- 0001/arch/arm/mach-shmobile/Makefile
+++ work/arch/arm/mach-shmobile/Makefile 2013-02-18 16:39:05.000000000 +0900
@@ -14,7 +14,6 @@ obj-$(CONFIG_ARCH_EMEV2) += setup-emev2.
# SMP objects
smp-y := platsmp.o headsmp.o
-smp-$(CONFIG_HOTPLUG_CPU) += hotplug.o
smp-$(CONFIG_ARCH_SH73A0) += smp-sh73a0.o headsmp-scu.o
smp-$(CONFIG_ARCH_R8A7779) += smp-r8a7779.o headsmp-scu.o
smp-$(CONFIG_ARCH_EMEV2) += smp-emev2.o headsmp-scu.o
--- 0001/arch/arm/mach-shmobile/hotplug.c
+++ /dev/null 2013-01-21 13:48:16.387453344 +0900
@@ -1,64 +0,0 @@
-/*
- * SMP support for R-Mobile / SH-Mobile
- *
- * Copyright (C) 2010 Magnus Damm
- *
- * Based on realview, Copyright (C) 2002 ARM Ltd, All Rights Reserved
- *
- * 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 <linux/kernel.h>
-#include <linux/errno.h>
-#include <linux/smp.h>
-#include <linux/cpumask.h>
-#include <linux/delay.h>
-#include <mach/common.h>
-#include <asm/cacheflush.h>
-
-static cpumask_t dead_cpus;
-
-void shmobile_cpu_die(unsigned int cpu)
-{
- /* hardware shutdown code running on the CPU that is being offlined */
- flush_cache_all();
- dsb();
-
- /* notify platform_cpu_kill() that hardware shutdown is finished */
- cpumask_set_cpu(cpu, &dead_cpus);
-
- /* wait for SoC code in platform_cpu_kill() to shut off CPU core
- * power. CPU bring up starts from the reset vector.
- */
- while (1) {
- /*
- * here's the WFI
- */
- asm(".word 0xe320f003\n"
- :
- :
- : "memory", "cc");
- }
-}
-
-int shmobile_cpu_disable(unsigned int cpu)
-{
- cpumask_clear_cpu(cpu, &dead_cpus);
- /*
- * we don't allow CPU 0 to be shutdown (it is still too special
- * e.g. clock tick interrupts)
- */
- return cpu = 0 ? -EPERM : 0;
-}
-
-int shmobile_cpu_disable_any(unsigned int cpu)
-{
- cpumask_clear_cpu(cpu, &dead_cpus);
- return 0;
-}
-
-int shmobile_cpu_is_dead(unsigned int cpu)
-{
- return cpumask_test_cpu(cpu, &dead_cpus);
-}
--- 0001/arch/arm/mach-shmobile/include/mach/common.h
+++ work/arch/arm/mach-shmobile/include/mach/common.h 2013-02-18 16:38:33.000000000 +0900
@@ -85,16 +85,6 @@ int shmobile_cpuidle_init(void);
static inline int shmobile_cpuidle_init(void) { return 0; }
#endif
-extern void shmobile_cpu_die(unsigned int cpu);
-extern int shmobile_cpu_disable(unsigned int cpu);
-extern int shmobile_cpu_disable_any(unsigned int cpu);
-
-#ifdef CONFIG_HOTPLUG_CPU
-extern int shmobile_cpu_is_dead(unsigned int cpu);
-#else
-static inline int shmobile_cpu_is_dead(unsigned int cpu) { return 1; }
-#endif
-
extern void __iomem *shmobile_scu_base;
extern void shmobile_smp_init_cpus(unsigned int ncores);
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
@ 2013-02-18 13:48 ` Magnus Damm
0 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-18 13:48 UTC (permalink / raw)
To: linux-arm-kernel
From: Magnus Damm <damm@opensource.se>
Each CPU Hotplug implementation for mach-shmobile
is now self-contained, so this change removes unused
helper code in hotplug.c. The two CPU Hotplug capable
SoCs sh73a0 and r8a7779 remain unchanged.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/Makefile | 1
arch/arm/mach-shmobile/hotplug.c | 64 --------------------------
arch/arm/mach-shmobile/include/mach/common.h | 10 ----
3 files changed, 75 deletions(-)
--- 0001/arch/arm/mach-shmobile/Makefile
+++ work/arch/arm/mach-shmobile/Makefile 2013-02-18 16:39:05.000000000 +0900
@@ -14,7 +14,6 @@ obj-$(CONFIG_ARCH_EMEV2) += setup-emev2.
# SMP objects
smp-y := platsmp.o headsmp.o
-smp-$(CONFIG_HOTPLUG_CPU) += hotplug.o
smp-$(CONFIG_ARCH_SH73A0) += smp-sh73a0.o headsmp-scu.o
smp-$(CONFIG_ARCH_R8A7779) += smp-r8a7779.o headsmp-scu.o
smp-$(CONFIG_ARCH_EMEV2) += smp-emev2.o headsmp-scu.o
--- 0001/arch/arm/mach-shmobile/hotplug.c
+++ /dev/null 2013-01-21 13:48:16.387453344 +0900
@@ -1,64 +0,0 @@
-/*
- * SMP support for R-Mobile / SH-Mobile
- *
- * Copyright (C) 2010 Magnus Damm
- *
- * Based on realview, Copyright (C) 2002 ARM Ltd, All Rights Reserved
- *
- * 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 <linux/kernel.h>
-#include <linux/errno.h>
-#include <linux/smp.h>
-#include <linux/cpumask.h>
-#include <linux/delay.h>
-#include <mach/common.h>
-#include <asm/cacheflush.h>
-
-static cpumask_t dead_cpus;
-
-void shmobile_cpu_die(unsigned int cpu)
-{
- /* hardware shutdown code running on the CPU that is being offlined */
- flush_cache_all();
- dsb();
-
- /* notify platform_cpu_kill() that hardware shutdown is finished */
- cpumask_set_cpu(cpu, &dead_cpus);
-
- /* wait for SoC code in platform_cpu_kill() to shut off CPU core
- * power. CPU bring up starts from the reset vector.
- */
- while (1) {
- /*
- * here's the WFI
- */
- asm(".word 0xe320f003\n"
- :
- :
- : "memory", "cc");
- }
-}
-
-int shmobile_cpu_disable(unsigned int cpu)
-{
- cpumask_clear_cpu(cpu, &dead_cpus);
- /*
- * we don't allow CPU 0 to be shutdown (it is still too special
- * e.g. clock tick interrupts)
- */
- return cpu == 0 ? -EPERM : 0;
-}
-
-int shmobile_cpu_disable_any(unsigned int cpu)
-{
- cpumask_clear_cpu(cpu, &dead_cpus);
- return 0;
-}
-
-int shmobile_cpu_is_dead(unsigned int cpu)
-{
- return cpumask_test_cpu(cpu, &dead_cpus);
-}
--- 0001/arch/arm/mach-shmobile/include/mach/common.h
+++ work/arch/arm/mach-shmobile/include/mach/common.h 2013-02-18 16:38:33.000000000 +0900
@@ -85,16 +85,6 @@ int shmobile_cpuidle_init(void);
static inline int shmobile_cpuidle_init(void) { return 0; }
#endif
-extern void shmobile_cpu_die(unsigned int cpu);
-extern int shmobile_cpu_disable(unsigned int cpu);
-extern int shmobile_cpu_disable_any(unsigned int cpu);
-
-#ifdef CONFIG_HOTPLUG_CPU
-extern int shmobile_cpu_is_dead(unsigned int cpu);
-#else
-static inline int shmobile_cpu_is_dead(unsigned int cpu) { return 1; }
-#endif
-
extern void __iomem *shmobile_scu_base;
extern void shmobile_smp_init_cpus(unsigned int ncores);
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
2013-02-18 13:46 ` Magnus Damm
@ 2013-02-19 0:49 ` Simon Horman
-1 siblings, 0 replies; 46+ messages in thread
From: Simon Horman @ 2013-02-19 0:49 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Feb 18, 2013 at 10:46:48PM +0900, Magnus Damm wrote:
> ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
>
> [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
> [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
> [PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
> [PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
> [PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
> [PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
> [PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
> [PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
>
> Finalize the SCU rework by performing minor fixes and converting
> the r8a7779 SMP code to make use of common scu_power_mode() code
> and the early SCU setup code in headsmp-scu.S.
>
> Also, to save a few line remove hotplug.c while at it.
>
> The only remaining itch to scratch here is to fix up CPU Hotplug
> of CPU0 on r8a7779, but for that to happen we first need to start
> accounting for spurious interrupts during shut down.
>
> Signed-off-by: Magnus Damm <damm@opensource.se>
> ---
>
> No known dependencies apart from previous SMP cleanup series
> "[PATCH 00/06] ARM: shmobile: SMP Cortex-A9 SCU rework"
> Written against -next in renesas.git.
I believe those are queued up for upstream in the soc5 branch.
Please let me know when you are comfortable with me applying these patches
to that branch. I'm fine with that answer being "now".
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
@ 2013-02-19 0:49 ` Simon Horman
0 siblings, 0 replies; 46+ messages in thread
From: Simon Horman @ 2013-02-19 0:49 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Feb 18, 2013 at 10:46:48PM +0900, Magnus Damm wrote:
> ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
>
> [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
> [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
> [PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
> [PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
> [PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
> [PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
> [PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
> [PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
>
> Finalize the SCU rework by performing minor fixes and converting
> the r8a7779 SMP code to make use of common scu_power_mode() code
> and the early SCU setup code in headsmp-scu.S.
>
> Also, to save a few line remove hotplug.c while at it.
>
> The only remaining itch to scratch here is to fix up CPU Hotplug
> of CPU0 on r8a7779, but for that to happen we first need to start
> accounting for spurious interrupts during shut down.
>
> Signed-off-by: Magnus Damm <damm@opensource.se>
> ---
>
> No known dependencies apart from previous SMP cleanup series
> "[PATCH 00/06] ARM: shmobile: SMP Cortex-A9 SCU rework"
> Written against -next in renesas.git.
I believe those are queued up for upstream in the soc5 branch.
Please let me know when you are comfortable with me applying these patches
to that branch. I'm fine with that answer being "now".
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
2013-02-19 0:49 ` Simon Horman
@ 2013-02-19 10:09 ` Magnus Damm
-1 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-19 10:09 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 19, 2013 at 9:49 AM, Simon Horman <horms@verge.net.au> wrote:
> On Mon, Feb 18, 2013 at 10:46:48PM +0900, Magnus Damm wrote:
>> ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
>>
>> [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
>> [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
>> [PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
>> [PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
>> [PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
>> [PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
>> [PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
>> [PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
>>
>> Finalize the SCU rework by performing minor fixes and converting
>> the r8a7779 SMP code to make use of common scu_power_mode() code
>> and the early SCU setup code in headsmp-scu.S.
>>
>> Also, to save a few line remove hotplug.c while at it.
>>
>> The only remaining itch to scratch here is to fix up CPU Hotplug
>> of CPU0 on r8a7779, but for that to happen we first need to start
>> accounting for spurious interrupts during shut down.
>>
>> Signed-off-by: Magnus Damm <damm@opensource.se>
>> ---
>>
>> No known dependencies apart from previous SMP cleanup series
>> "[PATCH 00/06] ARM: shmobile: SMP Cortex-A9 SCU rework"
>> Written against -next in renesas.git.
>
> I believe those are queued up for upstream in the soc5 branch.
>
> Please let me know when you are comfortable with me applying these patches
> to that branch. I'm fine with that answer being "now".
Now sounds wonderful. Thanks Simon.
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
@ 2013-02-19 10:09 ` Magnus Damm
0 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-02-19 10:09 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 19, 2013 at 9:49 AM, Simon Horman <horms@verge.net.au> wrote:
> On Mon, Feb 18, 2013 at 10:46:48PM +0900, Magnus Damm wrote:
>> ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
>>
>> [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
>> [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
>> [PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
>> [PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
>> [PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
>> [PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
>> [PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
>> [PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
>>
>> Finalize the SCU rework by performing minor fixes and converting
>> the r8a7779 SMP code to make use of common scu_power_mode() code
>> and the early SCU setup code in headsmp-scu.S.
>>
>> Also, to save a few line remove hotplug.c while at it.
>>
>> The only remaining itch to scratch here is to fix up CPU Hotplug
>> of CPU0 on r8a7779, but for that to happen we first need to start
>> accounting for spurious interrupts during shut down.
>>
>> Signed-off-by: Magnus Damm <damm@opensource.se>
>> ---
>>
>> No known dependencies apart from previous SMP cleanup series
>> "[PATCH 00/06] ARM: shmobile: SMP Cortex-A9 SCU rework"
>> Written against -next in renesas.git.
>
> I believe those are queued up for upstream in the soc5 branch.
>
> Please let me know when you are comfortable with me applying these patches
> to that branch. I'm fine with that answer being "now".
Now sounds wonderful. Thanks Simon.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
2013-02-19 10:09 ` Magnus Damm
@ 2013-02-26 8:53 ` Simon Horman
-1 siblings, 0 replies; 46+ messages in thread
From: Simon Horman @ 2013-02-26 8:53 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 19, 2013 at 07:09:14PM +0900, Magnus Damm wrote:
> On Tue, Feb 19, 2013 at 9:49 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Mon, Feb 18, 2013 at 10:46:48PM +0900, Magnus Damm wrote:
> >> ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
> >>
> >> [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
> >> [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
> >> [PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
> >> [PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
> >> [PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
> >> [PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
> >> [PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
> >> [PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
> >>
> >> Finalize the SCU rework by performing minor fixes and converting
> >> the r8a7779 SMP code to make use of common scu_power_mode() code
> >> and the early SCU setup code in headsmp-scu.S.
> >>
> >> Also, to save a few line remove hotplug.c while at it.
> >>
> >> The only remaining itch to scratch here is to fix up CPU Hotplug
> >> of CPU0 on r8a7779, but for that to happen we first need to start
> >> accounting for spurious interrupts during shut down.
> >>
> >> Signed-off-by: Magnus Damm <damm@opensource.se>
> >> ---
> >>
> >> No known dependencies apart from previous SMP cleanup series
> >> "[PATCH 00/06] ARM: shmobile: SMP Cortex-A9 SCU rework"
> >> Written against -next in renesas.git.
> >
> > I believe those are queued up for upstream in the soc5 branch.
> >
> > Please let me know when you are comfortable with me applying these patches
> > to that branch. I'm fine with that answer being "now".
>
> Now sounds wonderful. Thanks Simon.
[some time passes]
Thanks, applied to the soc5 branch.
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
@ 2013-02-26 8:53 ` Simon Horman
0 siblings, 0 replies; 46+ messages in thread
From: Simon Horman @ 2013-02-26 8:53 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 19, 2013 at 07:09:14PM +0900, Magnus Damm wrote:
> On Tue, Feb 19, 2013 at 9:49 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Mon, Feb 18, 2013 at 10:46:48PM +0900, Magnus Damm wrote:
> >> ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
> >>
> >> [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
> >> [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
> >> [PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
> >> [PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
> >> [PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
> >> [PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
> >> [PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
> >> [PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
> >>
> >> Finalize the SCU rework by performing minor fixes and converting
> >> the r8a7779 SMP code to make use of common scu_power_mode() code
> >> and the early SCU setup code in headsmp-scu.S.
> >>
> >> Also, to save a few line remove hotplug.c while at it.
> >>
> >> The only remaining itch to scratch here is to fix up CPU Hotplug
> >> of CPU0 on r8a7779, but for that to happen we first need to start
> >> accounting for spurious interrupts during shut down.
> >>
> >> Signed-off-by: Magnus Damm <damm@opensource.se>
> >> ---
> >>
> >> No known dependencies apart from previous SMP cleanup series
> >> "[PATCH 00/06] ARM: shmobile: SMP Cortex-A9 SCU rework"
> >> Written against -next in renesas.git.
> >
> > I believe those are queued up for upstream in the soc5 branch.
> >
> > Please let me know when you are comfortable with me applying these patches
> > to that branch. I'm fine with that answer being "now".
>
> Now sounds wonderful. Thanks Simon.
[some time passes]
Thanks, applied to the soc5 branch.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
2013-02-18 13:46 ` Magnus Damm
` (9 preceding siblings ...)
(?)
@ 2013-03-27 6:42 ` Magnus Damm
-1 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-03-27 6:42 UTC (permalink / raw)
To: linux-sh
On Tue, Feb 26, 2013 at 5:53 PM, Simon Horman <horms@verge.net.au> wrote:
> On Tue, Feb 19, 2013 at 07:09:14PM +0900, Magnus Damm wrote:
>> On Tue, Feb 19, 2013 at 9:49 AM, Simon Horman <horms@verge.net.au> wrote:
>> > On Mon, Feb 18, 2013 at 10:46:48PM +0900, Magnus Damm wrote:
>> >> ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
>> >>
>> >> [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
>> >> [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
>> >> [PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
>> >> [PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
>> >> [PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
>> >> [PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
>> >> [PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
>> >> [PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
>> >>
>> >> Finalize the SCU rework by performing minor fixes and converting
>> >> the r8a7779 SMP code to make use of common scu_power_mode() code
>> >> and the early SCU setup code in headsmp-scu.S.
>> >>
>> >> Also, to save a few line remove hotplug.c while at it.
>> >>
>> >> The only remaining itch to scratch here is to fix up CPU Hotplug
>> >> of CPU0 on r8a7779, but for that to happen we first need to start
>> >> accounting for spurious interrupts during shut down.
>> >>
>> >> Signed-off-by: Magnus Damm <damm@opensource.se>
>> >> ---
>> >>
>> >> No known dependencies apart from previous SMP cleanup series
>> >> "[PATCH 00/06] ARM: shmobile: SMP Cortex-A9 SCU rework"
>> >> Written against -next in renesas.git.
>> >
>> > I believe those are queued up for upstream in the soc5 branch.
>> >
>> > Please let me know when you are comfortable with me applying these patches
>> > to that branch. I'm fine with that answer being "now".
>>
>> Now sounds wonderful. Thanks Simon.
>
> [some time passes]
>
> Thanks, applied to the soc5 branch.
[more time passes]
Thanks for your help.
Here's a list of the recent SMP/SCU/CPU Hotplug patches:
[PATCH 00/06] ARM: shmobile: Trivial SMP cleanups
[PATCH 01/06] ARM: shmobile: Remove unused headers from hotplug.c
[PATCH 02/06] ARM: shmobile: Remove partial CPU Hotplug from EMEV2
[PATCH 03/06] ARM: shmobile: Move EMEV2 CPU boot vector setup code
[PATCH 04/06] ARM: shmobile: Remove sh73a0_get_core_count()
[PATCH 05/06] ARM: shmobile: Remove r8a7779_get_core_count()
[PATCH 06/06] ARM: shmobile: Remove emev2_get_core_count()
[PATCH 00/06] ARM: shmobile: SMP Cortex-A9 SCU rework
[PATCH 01/06] ARM: shmobile: Kill off sh73a0 scu_base_addr() function
[PATCH 02/06] ARM: shmobile: Kill off r8a7779 scu_base_addr() function
[PATCH 03/06] ARM: shmobile: Rework EMEV2 scu_base variable
[PATCH 04/06] ARM: shmobile: Move headsmp-sh73a0.S to headsmp-scu.S
[PATCH 05/06] ARM: shmobile: Common shmobile_scu_base in headsmp-scu.S
[PATCH 06/06] ARM: shmobile: Update EMEV2 to use scu_power_mode()
[PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
[PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
[PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
[PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
[PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
[PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
[PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
[PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
[PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
I've now gotten around to once more test the above patches on KZM9D,
and both CPU0 and CPU1 boots as expected when SMP is enabled in the
kernel configuration.
To test I used renesas.git with the tag renesas-next-20130321.
Thanks,
/ magnus
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
2013-02-18 13:46 ` Magnus Damm
` (10 preceding siblings ...)
(?)
@ 2013-03-27 8:45 ` Simon Horman
-1 siblings, 0 replies; 46+ messages in thread
From: Simon Horman @ 2013-03-27 8:45 UTC (permalink / raw)
To: linux-sh
On Wed, Mar 27, 2013 at 03:42:57PM +0900, Magnus Damm wrote:
> On Tue, Feb 26, 2013 at 5:53 PM, Simon Horman <horms@verge.net.au> wrote:
> > On Tue, Feb 19, 2013 at 07:09:14PM +0900, Magnus Damm wrote:
> >> On Tue, Feb 19, 2013 at 9:49 AM, Simon Horman <horms@verge.net.au> wrote:
> >> > On Mon, Feb 18, 2013 at 10:46:48PM +0900, Magnus Damm wrote:
> >> >> ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
> >> >>
> >> >> [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
> >> >> [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
> >> >> [PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
> >> >> [PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
> >> >> [PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
> >> >> [PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
> >> >> [PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
> >> >> [PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
> >> >>
> >> >> Finalize the SCU rework by performing minor fixes and converting
> >> >> the r8a7779 SMP code to make use of common scu_power_mode() code
> >> >> and the early SCU setup code in headsmp-scu.S.
> >> >>
> >> >> Also, to save a few line remove hotplug.c while at it.
> >> >>
> >> >> The only remaining itch to scratch here is to fix up CPU Hotplug
> >> >> of CPU0 on r8a7779, but for that to happen we first need to start
> >> >> accounting for spurious interrupts during shut down.
> >> >>
> >> >> Signed-off-by: Magnus Damm <damm@opensource.se>
> >> >> ---
> >> >>
> >> >> No known dependencies apart from previous SMP cleanup series
> >> >> "[PATCH 00/06] ARM: shmobile: SMP Cortex-A9 SCU rework"
> >> >> Written against -next in renesas.git.
> >> >
> >> > I believe those are queued up for upstream in the soc5 branch.
> >> >
> >> > Please let me know when you are comfortable with me applying these patches
> >> > to that branch. I'm fine with that answer being "now".
> >>
> >> Now sounds wonderful. Thanks Simon.
> >
> > [some time passes]
> >
> > Thanks, applied to the soc5 branch.
>
> [more time passes]
>
> Thanks for your help.
>
> Here's a list of the recent SMP/SCU/CPU Hotplug patches:
>
> [PATCH 00/06] ARM: shmobile: Trivial SMP cleanups
> [PATCH 01/06] ARM: shmobile: Remove unused headers from hotplug.c
> [PATCH 02/06] ARM: shmobile: Remove partial CPU Hotplug from EMEV2
> [PATCH 03/06] ARM: shmobile: Move EMEV2 CPU boot vector setup code
> [PATCH 04/06] ARM: shmobile: Remove sh73a0_get_core_count()
> [PATCH 05/06] ARM: shmobile: Remove r8a7779_get_core_count()
> [PATCH 06/06] ARM: shmobile: Remove emev2_get_core_count()
>
> [PATCH 00/06] ARM: shmobile: SMP Cortex-A9 SCU rework
> [PATCH 01/06] ARM: shmobile: Kill off sh73a0 scu_base_addr() function
> [PATCH 02/06] ARM: shmobile: Kill off r8a7779 scu_base_addr() function
> [PATCH 03/06] ARM: shmobile: Rework EMEV2 scu_base variable
> [PATCH 04/06] ARM: shmobile: Move headsmp-sh73a0.S to headsmp-scu.S
> [PATCH 05/06] ARM: shmobile: Common shmobile_scu_base in headsmp-scu.S
> [PATCH 06/06] ARM: shmobile: Update EMEV2 to use scu_power_mode()
>
> [PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
> [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
> [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
> [PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
> [PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
> [PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
> [PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
> [PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
> [PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
>
> I've now gotten around to once more test the above patches on KZM9D,
> and both CPU0 and CPU1 boots as expected when SMP is enabled in the
> kernel configuration.
>
> To test I used renesas.git with the tag renesas-next-20130321.
Do you want me to queue-up the above patches for v3.10?
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
2013-02-18 13:46 ` Magnus Damm
` (11 preceding siblings ...)
(?)
@ 2013-03-27 8:53 ` Magnus Damm
-1 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-03-27 8:53 UTC (permalink / raw)
To: linux-sh
On Wed, Mar 27, 2013 at 5:45 PM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Mar 27, 2013 at 03:42:57PM +0900, Magnus Damm wrote:
>> On Tue, Feb 26, 2013 at 5:53 PM, Simon Horman <horms@verge.net.au> wrote:
>> > On Tue, Feb 19, 2013 at 07:09:14PM +0900, Magnus Damm wrote:
>> >> On Tue, Feb 19, 2013 at 9:49 AM, Simon Horman <horms@verge.net.au> wrote:
>> >> > On Mon, Feb 18, 2013 at 10:46:48PM +0900, Magnus Damm wrote:
>> >> >> ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
>> >> >>
>> >> >> [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
>> >> >> [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
>> >> >> [PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
>> >> >> [PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
>> >> >> [PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
>> >> >> [PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
>> >> >> [PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
>> >> >> [PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
>> >> >>
>> >> >> Finalize the SCU rework by performing minor fixes and converting
>> >> >> the r8a7779 SMP code to make use of common scu_power_mode() code
>> >> >> and the early SCU setup code in headsmp-scu.S.
>> >> >>
>> >> >> Also, to save a few line remove hotplug.c while at it.
>> >> >>
>> >> >> The only remaining itch to scratch here is to fix up CPU Hotplug
>> >> >> of CPU0 on r8a7779, but for that to happen we first need to start
>> >> >> accounting for spurious interrupts during shut down.
>> >> >>
>> >> >> Signed-off-by: Magnus Damm <damm@opensource.se>
>> >> >> ---
>> >> >>
>> >> >> No known dependencies apart from previous SMP cleanup series
>> >> >> "[PATCH 00/06] ARM: shmobile: SMP Cortex-A9 SCU rework"
>> >> >> Written against -next in renesas.git.
>> >> >
>> >> > I believe those are queued up for upstream in the soc5 branch.
>> >> >
>> >> > Please let me know when you are comfortable with me applying these patches
>> >> > to that branch. I'm fine with that answer being "now".
>> >>
>> >> Now sounds wonderful. Thanks Simon.
>> >
>> > [some time passes]
>> >
>> > Thanks, applied to the soc5 branch.
>>
>> [more time passes]
>>
>> Thanks for your help.
>>
>> Here's a list of the recent SMP/SCU/CPU Hotplug patches:
>>
>> [PATCH 00/06] ARM: shmobile: Trivial SMP cleanups
>> [PATCH 01/06] ARM: shmobile: Remove unused headers from hotplug.c
>> [PATCH 02/06] ARM: shmobile: Remove partial CPU Hotplug from EMEV2
>> [PATCH 03/06] ARM: shmobile: Move EMEV2 CPU boot vector setup code
>> [PATCH 04/06] ARM: shmobile: Remove sh73a0_get_core_count()
>> [PATCH 05/06] ARM: shmobile: Remove r8a7779_get_core_count()
>> [PATCH 06/06] ARM: shmobile: Remove emev2_get_core_count()
>>
>> [PATCH 00/06] ARM: shmobile: SMP Cortex-A9 SCU rework
>> [PATCH 01/06] ARM: shmobile: Kill off sh73a0 scu_base_addr() function
>> [PATCH 02/06] ARM: shmobile: Kill off r8a7779 scu_base_addr() function
>> [PATCH 03/06] ARM: shmobile: Rework EMEV2 scu_base variable
>> [PATCH 04/06] ARM: shmobile: Move headsmp-sh73a0.S to headsmp-scu.S
>> [PATCH 05/06] ARM: shmobile: Common shmobile_scu_base in headsmp-scu.S
>> [PATCH 06/06] ARM: shmobile: Update EMEV2 to use scu_power_mode()
>>
>> [PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
>> [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
>> [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
>> [PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
>> [PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
>> [PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
>> [PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
>> [PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
>> [PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
>>
>> I've now gotten around to once more test the above patches on KZM9D,
>> and both CPU0 and CPU1 boots as expected when SMP is enabled in the
>> kernel configuration.
>>
>> To test I used renesas.git with the tag renesas-next-20130321.
>
> Do you want me to queue-up the above patches for v3.10?
To be honest, I actually expected them to be queued-up already. They
are in "next", right?
If they are not queued up already then please do so.
Thanks,
/ magnus
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
2013-02-18 13:46 ` Magnus Damm
` (12 preceding siblings ...)
(?)
@ 2013-03-27 10:57 ` Simon Horman
-1 siblings, 0 replies; 46+ messages in thread
From: Simon Horman @ 2013-03-27 10:57 UTC (permalink / raw)
To: linux-sh
On Wed, Mar 27, 2013 at 05:53:48PM +0900, Magnus Damm wrote:
> On Wed, Mar 27, 2013 at 5:45 PM, Simon Horman <horms@verge.net.au> wrote:
> > On Wed, Mar 27, 2013 at 03:42:57PM +0900, Magnus Damm wrote:
> >> On Tue, Feb 26, 2013 at 5:53 PM, Simon Horman <horms@verge.net.au> wrote:
> >> > On Tue, Feb 19, 2013 at 07:09:14PM +0900, Magnus Damm wrote:
> >> >> On Tue, Feb 19, 2013 at 9:49 AM, Simon Horman <horms@verge.net.au> wrote:
> >> >> > On Mon, Feb 18, 2013 at 10:46:48PM +0900, Magnus Damm wrote:
> >> >> >> ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
> >> >> >>
> >> >> >> [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
> >> >> >> [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
> >> >> >> [PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
> >> >> >> [PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
> >> >> >> [PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
> >> >> >> [PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
> >> >> >> [PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
> >> >> >> [PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
> >> >> >>
> >> >> >> Finalize the SCU rework by performing minor fixes and converting
> >> >> >> the r8a7779 SMP code to make use of common scu_power_mode() code
> >> >> >> and the early SCU setup code in headsmp-scu.S.
> >> >> >>
> >> >> >> Also, to save a few line remove hotplug.c while at it.
> >> >> >>
> >> >> >> The only remaining itch to scratch here is to fix up CPU Hotplug
> >> >> >> of CPU0 on r8a7779, but for that to happen we first need to start
> >> >> >> accounting for spurious interrupts during shut down.
> >> >> >>
> >> >> >> Signed-off-by: Magnus Damm <damm@opensource.se>
> >> >> >> ---
> >> >> >>
> >> >> >> No known dependencies apart from previous SMP cleanup series
> >> >> >> "[PATCH 00/06] ARM: shmobile: SMP Cortex-A9 SCU rework"
> >> >> >> Written against -next in renesas.git.
> >> >> >
> >> >> > I believe those are queued up for upstream in the soc5 branch.
> >> >> >
> >> >> > Please let me know when you are comfortable with me applying these patches
> >> >> > to that branch. I'm fine with that answer being "now".
> >> >>
> >> >> Now sounds wonderful. Thanks Simon.
> >> >
> >> > [some time passes]
> >> >
> >> > Thanks, applied to the soc5 branch.
> >>
> >> [more time passes]
> >>
> >> Thanks for your help.
> >>
> >> Here's a list of the recent SMP/SCU/CPU Hotplug patches:
> >>
> >> [PATCH 00/06] ARM: shmobile: Trivial SMP cleanups
> >> [PATCH 01/06] ARM: shmobile: Remove unused headers from hotplug.c
> >> [PATCH 02/06] ARM: shmobile: Remove partial CPU Hotplug from EMEV2
> >> [PATCH 03/06] ARM: shmobile: Move EMEV2 CPU boot vector setup code
> >> [PATCH 04/06] ARM: shmobile: Remove sh73a0_get_core_count()
> >> [PATCH 05/06] ARM: shmobile: Remove r8a7779_get_core_count()
> >> [PATCH 06/06] ARM: shmobile: Remove emev2_get_core_count()
> >>
> >> [PATCH 00/06] ARM: shmobile: SMP Cortex-A9 SCU rework
> >> [PATCH 01/06] ARM: shmobile: Kill off sh73a0 scu_base_addr() function
> >> [PATCH 02/06] ARM: shmobile: Kill off r8a7779 scu_base_addr() function
> >> [PATCH 03/06] ARM: shmobile: Rework EMEV2 scu_base variable
> >> [PATCH 04/06] ARM: shmobile: Move headsmp-sh73a0.S to headsmp-scu.S
> >> [PATCH 05/06] ARM: shmobile: Common shmobile_scu_base in headsmp-scu.S
> >> [PATCH 06/06] ARM: shmobile: Update EMEV2 to use scu_power_mode()
> >>
> >> [PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
> >> [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
> >> [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
> >> [PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
> >> [PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
> >> [PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
> >> [PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
> >> [PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
> >> [PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
> >>
> >> I've now gotten around to once more test the above patches on KZM9D,
> >> and both CPU0 and CPU1 boots as expected when SMP is enabled in the
> >> kernel configuration.
> >>
> >> To test I used renesas.git with the tag renesas-next-20130321.
> >
> > Do you want me to queue-up the above patches for v3.10?
>
> To be honest, I actually expected them to be queued-up already. They
> are in "next", right?
>
> If they are not queued up already then please do so.
I checked in patchwork and they have all been accepted.
What was the purpose of you posting the list of patches?
I am confused.
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
2013-02-18 13:46 ` Magnus Damm
` (13 preceding siblings ...)
(?)
@ 2013-03-27 14:58 ` Magnus Damm
-1 siblings, 0 replies; 46+ messages in thread
From: Magnus Damm @ 2013-03-27 14:58 UTC (permalink / raw)
To: linux-sh
On Wed, Mar 27, 2013 at 7:57 PM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Mar 27, 2013 at 05:53:48PM +0900, Magnus Damm wrote:
>> On Wed, Mar 27, 2013 at 5:45 PM, Simon Horman <horms@verge.net.au> wrote:
>> > On Wed, Mar 27, 2013 at 03:42:57PM +0900, Magnus Damm wrote:
>> >> On Tue, Feb 26, 2013 at 5:53 PM, Simon Horman <horms@verge.net.au> wrote:
>> >> > On Tue, Feb 19, 2013 at 07:09:14PM +0900, Magnus Damm wrote:
>> >> >> On Tue, Feb 19, 2013 at 9:49 AM, Simon Horman <horms@verge.net.au> wrote:
>> >> >> > On Mon, Feb 18, 2013 at 10:46:48PM +0900, Magnus Damm wrote:
>> >> >> >> ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
>> >> >> >>
>> >> >> >> [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
>> >> >> >> [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
>> >> >> >> [PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
>> >> >> >> [PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
>> >> >> >> [PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
>> >> >> >> [PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
>> >> >> >> [PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
>> >> >> >> [PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
>> >> >> >>
>> >> >> >> Finalize the SCU rework by performing minor fixes and converting
>> >> >> >> the r8a7779 SMP code to make use of common scu_power_mode() code
>> >> >> >> and the early SCU setup code in headsmp-scu.S.
>> >> >> >>
>> >> >> >> Also, to save a few line remove hotplug.c while at it.
>> >> >> >>
>> >> >> >> The only remaining itch to scratch here is to fix up CPU Hotplug
>> >> >> >> of CPU0 on r8a7779, but for that to happen we first need to start
>> >> >> >> accounting for spurious interrupts during shut down.
>> >> >> >>
>> >> >> >> Signed-off-by: Magnus Damm <damm@opensource.se>
>> >> >> >> ---
>> >> >> >>
>> >> >> >> No known dependencies apart from previous SMP cleanup series
>> >> >> >> "[PATCH 00/06] ARM: shmobile: SMP Cortex-A9 SCU rework"
>> >> >> >> Written against -next in renesas.git.
>> >> >> >
>> >> >> > I believe those are queued up for upstream in the soc5 branch.
>> >> >> >
>> >> >> > Please let me know when you are comfortable with me applying these patches
>> >> >> > to that branch. I'm fine with that answer being "now".
>> >> >>
>> >> >> Now sounds wonderful. Thanks Simon.
>> >> >
>> >> > [some time passes]
>> >> >
>> >> > Thanks, applied to the soc5 branch.
>> >>
>> >> [more time passes]
>> >>
>> >> Thanks for your help.
>> >>
>> >> Here's a list of the recent SMP/SCU/CPU Hotplug patches:
>> >>
>> >> [PATCH 00/06] ARM: shmobile: Trivial SMP cleanups
>> >> [PATCH 01/06] ARM: shmobile: Remove unused headers from hotplug.c
>> >> [PATCH 02/06] ARM: shmobile: Remove partial CPU Hotplug from EMEV2
>> >> [PATCH 03/06] ARM: shmobile: Move EMEV2 CPU boot vector setup code
>> >> [PATCH 04/06] ARM: shmobile: Remove sh73a0_get_core_count()
>> >> [PATCH 05/06] ARM: shmobile: Remove r8a7779_get_core_count()
>> >> [PATCH 06/06] ARM: shmobile: Remove emev2_get_core_count()
>> >>
>> >> [PATCH 00/06] ARM: shmobile: SMP Cortex-A9 SCU rework
>> >> [PATCH 01/06] ARM: shmobile: Kill off sh73a0 scu_base_addr() function
>> >> [PATCH 02/06] ARM: shmobile: Kill off r8a7779 scu_base_addr() function
>> >> [PATCH 03/06] ARM: shmobile: Rework EMEV2 scu_base variable
>> >> [PATCH 04/06] ARM: shmobile: Move headsmp-sh73a0.S to headsmp-scu.S
>> >> [PATCH 05/06] ARM: shmobile: Common shmobile_scu_base in headsmp-scu.S
>> >> [PATCH 06/06] ARM: shmobile: Update EMEV2 to use scu_power_mode()
>> >>
>> >> [PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
>> >> [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
>> >> [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
>> >> [PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
>> >> [PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
>> >> [PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
>> >> [PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
>> >> [PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
>> >> [PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
>> >>
>> >> I've now gotten around to once more test the above patches on KZM9D,
>> >> and both CPU0 and CPU1 boots as expected when SMP is enabled in the
>> >> kernel configuration.
>> >>
>> >> To test I used renesas.git with the tag renesas-next-20130321.
>> >
>> > Do you want me to queue-up the above patches for v3.10?
>>
>> To be honest, I actually expected them to be queued-up already. They
>> are in "next", right?
>>
>> If they are not queued up already then please do so.
>
> I checked in patchwork and they have all been accepted.
>
> What was the purpose of you posting the list of patches?
> I am confused.
Just wanted to make a summary of those SMP related patches. Sorry
about the confusion!
/ magnus
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
2013-02-18 13:46 ` Magnus Damm
` (14 preceding siblings ...)
(?)
@ 2013-03-28 0:17 ` Simon Horman
-1 siblings, 0 replies; 46+ messages in thread
From: Simon Horman @ 2013-03-28 0:17 UTC (permalink / raw)
To: linux-sh
On Wed, Mar 27, 2013 at 11:58:27PM +0900, Magnus Damm wrote:
> On Wed, Mar 27, 2013 at 7:57 PM, Simon Horman <horms@verge.net.au> wrote:
> > On Wed, Mar 27, 2013 at 05:53:48PM +0900, Magnus Damm wrote:
> >> On Wed, Mar 27, 2013 at 5:45 PM, Simon Horman <horms@verge.net.au> wrote:
> >> > On Wed, Mar 27, 2013 at 03:42:57PM +0900, Magnus Damm wrote:
> >> >> On Tue, Feb 26, 2013 at 5:53 PM, Simon Horman <horms@verge.net.au> wrote:
> >> >> > On Tue, Feb 19, 2013 at 07:09:14PM +0900, Magnus Damm wrote:
> >> >> >> On Tue, Feb 19, 2013 at 9:49 AM, Simon Horman <horms@verge.net.au> wrote:
> >> >> >> > On Mon, Feb 18, 2013 at 10:46:48PM +0900, Magnus Damm wrote:
> >> >> >> >> ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
> >> >> >> >>
> >> >> >> >> [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
> >> >> >> >> [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
> >> >> >> >> [PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
> >> >> >> >> [PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
> >> >> >> >> [PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
> >> >> >> >> [PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
> >> >> >> >> [PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
> >> >> >> >> [PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
> >> >> >> >>
> >> >> >> >> Finalize the SCU rework by performing minor fixes and converting
> >> >> >> >> the r8a7779 SMP code to make use of common scu_power_mode() code
> >> >> >> >> and the early SCU setup code in headsmp-scu.S.
> >> >> >> >>
> >> >> >> >> Also, to save a few line remove hotplug.c while at it.
> >> >> >> >>
> >> >> >> >> The only remaining itch to scratch here is to fix up CPU Hotplug
> >> >> >> >> of CPU0 on r8a7779, but for that to happen we first need to start
> >> >> >> >> accounting for spurious interrupts during shut down.
> >> >> >> >>
> >> >> >> >> Signed-off-by: Magnus Damm <damm@opensource.se>
> >> >> >> >> ---
> >> >> >> >>
> >> >> >> >> No known dependencies apart from previous SMP cleanup series
> >> >> >> >> "[PATCH 00/06] ARM: shmobile: SMP Cortex-A9 SCU rework"
> >> >> >> >> Written against -next in renesas.git.
> >> >> >> >
> >> >> >> > I believe those are queued up for upstream in the soc5 branch.
> >> >> >> >
> >> >> >> > Please let me know when you are comfortable with me applying these patches
> >> >> >> > to that branch. I'm fine with that answer being "now".
> >> >> >>
> >> >> >> Now sounds wonderful. Thanks Simon.
> >> >> >
> >> >> > [some time passes]
> >> >> >
> >> >> > Thanks, applied to the soc5 branch.
> >> >>
> >> >> [more time passes]
> >> >>
> >> >> Thanks for your help.
> >> >>
> >> >> Here's a list of the recent SMP/SCU/CPU Hotplug patches:
> >> >>
> >> >> [PATCH 00/06] ARM: shmobile: Trivial SMP cleanups
> >> >> [PATCH 01/06] ARM: shmobile: Remove unused headers from hotplug.c
> >> >> [PATCH 02/06] ARM: shmobile: Remove partial CPU Hotplug from EMEV2
> >> >> [PATCH 03/06] ARM: shmobile: Move EMEV2 CPU boot vector setup code
> >> >> [PATCH 04/06] ARM: shmobile: Remove sh73a0_get_core_count()
> >> >> [PATCH 05/06] ARM: shmobile: Remove r8a7779_get_core_count()
> >> >> [PATCH 06/06] ARM: shmobile: Remove emev2_get_core_count()
> >> >>
> >> >> [PATCH 00/06] ARM: shmobile: SMP Cortex-A9 SCU rework
> >> >> [PATCH 01/06] ARM: shmobile: Kill off sh73a0 scu_base_addr() function
> >> >> [PATCH 02/06] ARM: shmobile: Kill off r8a7779 scu_base_addr() function
> >> >> [PATCH 03/06] ARM: shmobile: Rework EMEV2 scu_base variable
> >> >> [PATCH 04/06] ARM: shmobile: Move headsmp-sh73a0.S to headsmp-scu.S
> >> >> [PATCH 05/06] ARM: shmobile: Common shmobile_scu_base in headsmp-scu.S
> >> >> [PATCH 06/06] ARM: shmobile: Update EMEV2 to use scu_power_mode()
> >> >>
> >> >> [PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2
> >> >> [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S
> >> >> [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
> >> >> [PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD
> >> >> [PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug
> >> >> [PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode()
> >> >> [PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code
> >> >> [PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code
> >> >> [PATCH 08/08] ARM: shmobile: Remove unused hotplug.c
> >> >>
> >> >> I've now gotten around to once more test the above patches on KZM9D,
> >> >> and both CPU0 and CPU1 boots as expected when SMP is enabled in the
> >> >> kernel configuration.
> >> >>
> >> >> To test I used renesas.git with the tag renesas-next-20130321.
> >> >
> >> > Do you want me to queue-up the above patches for v3.10?
> >>
> >> To be honest, I actually expected them to be queued-up already. They
> >> are in "next", right?
> >>
> >> If they are not queued up already then please do so.
> >
> > I checked in patchwork and they have all been accepted.
> >
> > What was the purpose of you posting the list of patches?
> > I am confused.
>
> Just wanted to make a summary of those SMP related patches. Sorry
> about the confusion!
No problem. I am no longer confused :)
^ permalink raw reply [flat|nested] 46+ messages in thread