diff mbox

[7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()

Message ID 1361373527-21695-8-git-send-email-santosh.shilimkar@ti.com (mailing list archive)
State New, archived
Headers show

Commit Message

Santosh Shilimkar Feb. 20, 2013, 3:18 p.m. UTC
Move the secondary CPU wakeup prepare code under smp_prepare_cpus(). While at
it drop the un-necessary sev() and barrier which was under prepare code.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/mach-omap2/omap-smp.c |   51 ++++++++++++++++------------------------
 1 file changed, 20 insertions(+), 31 deletions(-)

Comments

Kevin Hilman March 27, 2013, 6:45 p.m. UTC | #1
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:

> Move the secondary CPU wakeup prepare code under smp_prepare_cpus(). 

Why?

> While at
> it drop the un-necessary sev() and barrier which was under prepare code.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
>  arch/arm/mach-omap2/omap-smp.c |   51 ++++++++++++++++------------------------
>  1 file changed, 20 insertions(+), 31 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
> index 7d29a74..9711ecd 100644
> --- a/arch/arm/mach-omap2/omap-smp.c
> +++ b/arch/arm/mach-omap2/omap-smp.c
> @@ -164,36 +164,6 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
>  	return 0;
>  }
>  
> -static void __init wakeup_secondary(void)
> -{
> -	void *startup_addr = omap_secondary_startup;
> -	void __iomem *base = omap_get_wakeupgen_base();
> -
> -	if (cpu_is_omap446x()) {
> -		startup_addr = omap_secondary_startup_4460;
> -		pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
> -	}
> -
> -	/*
> -	 * Write the address of secondary startup routine into the
> -	 * AuxCoreBoot1 where ROM code will jump and start executing
> -	 * on secondary core once out of WFE
> -	 * A barrier is added to ensure that write buffer is drained
> -	 */
> -	if (omap_secure_apis_support())
> -		omap_auxcoreboot_addr(virt_to_phys(startup_addr));
> -	else
> -		__raw_writel(virt_to_phys(omap5_secondary_startup),
> -						base + OMAP_AUX_CORE_BOOT_1);
> -
> -	/*
> -	 * Send a 'sev' to wake the secondary core from WFE.
> -	 * Drain the outstanding writes to memory
> -	 */
> -	dsb_sev();
> -	mb();
> -}
> -
>  /*
>   * Initialise the CPU possible map early - this describes the CPUs
>   * which may be present or become present in the system.
> @@ -231,6 +201,8 @@ static void __init omap4_smp_init_cpus(void)
>  
>  static void __init omap4_smp_prepare_cpus(unsigned int max_cpus)
>  {
> +	void *startup_addr = omap_secondary_startup;
> +	void __iomem *base = omap_get_wakeupgen_base();
>  
>  	/*
>  	 * Initialise the SCU and wake up the secondary core using
> @@ -238,7 +210,24 @@ static void __init omap4_smp_prepare_cpus(unsigned int max_cpus)
>  	 */
>  	if (scu_base)
>  		scu_enable(scu_base);
> -	wakeup_secondary();
> +
> +	if (cpu_is_omap446x()) {
> +		startup_addr = omap_secondary_startup_4460;
> +		pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
> +	}
> +
> +	/*
> +	 * Write the address of secondary startup routine into the
> +	 * AuxCoreBoot1 where ROM code will jump and start executing
> +	 * on secondary core once out of WFE
> +	 * A barrier is added to ensure that write buffer is drained
> +	 */
> +	if (omap_secure_apis_support())
> +		omap_auxcoreboot_addr(virt_to_phys(startup_addr));
> +	else
> +		__raw_writel(virt_to_phys(omap5_secondary_startup),
> +						base + OMAP_AUX_CORE_BOOT_1);
> +
>  }
>  
>  struct smp_operations omap4_smp_ops __initdata = {
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Santosh Shilimkar March 27, 2013, 7:04 p.m. UTC | #2
On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> 
>> Move the secondary CPU wakeup prepare code under smp_prepare_cpus(). 
> 
> Why?
> 
Because that code belongs to smp_prepare_cpus(). As I said
in earlier patches, it was remainder of the pen release code
which was borrowed from ARM code initially.

Regards,
Santosh

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kevin Hilman March 27, 2013, 7:54 p.m. UTC | #3
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:

> On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>> 
>>> Move the secondary CPU wakeup prepare code under smp_prepare_cpus(). 
>> 
>> Why?
>> 
> Because that code belongs to smp_prepare_cpus(). As I said
> in earlier patches, it was remainder of the pen release code
> which was borrowed from ARM code initially.

Sure, but that should be in the changelog.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Santosh Shilimkar March 27, 2013, 8:50 p.m. UTC | #4
On Thursday 28 March 2013 01:24 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> 
>> On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>
>>>> Move the secondary CPU wakeup prepare code under smp_prepare_cpus(). 
>>>
>>> Why?
>>>
>> Because that code belongs to smp_prepare_cpus(). As I said
>> in earlier patches, it was remainder of the pen release code
>> which was borrowed from ARM code initially.
> 
> Sure, but that should be in the changelog.
> 
Yep. Will add above info in changelog.

Regards,
Santosh

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Russell King - ARM Linux March 28, 2013, 9:46 a.m. UTC | #5
On Thu, Mar 28, 2013 at 12:34:50AM +0530, Santosh Shilimkar wrote:
> On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
> > Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> > 
> >> Move the secondary CPU wakeup prepare code under smp_prepare_cpus(). 
> > 
> > Why?
> > 
> Because that code belongs to smp_prepare_cpus(). As I said
> in earlier patches, it was remainder of the pen release code
> which was borrowed from ARM code initially.

What about hotplug after the system is suspended?  Is this setup
preserved by the secure ROM?

If not, it really needs to be part of the CPU bringup, not the
boot-time-only preparation code.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Santosh Shilimkar March 28, 2013, 9:58 a.m. UTC | #6
On Thursday 28 March 2013 03:16 PM, Russell King - ARM Linux wrote:
> On Thu, Mar 28, 2013 at 12:34:50AM +0530, Santosh Shilimkar wrote:
>> On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>
>>>> Move the secondary CPU wakeup prepare code under smp_prepare_cpus(). 
>>>
>>> Why?
>>>
>> Because that code belongs to smp_prepare_cpus(). As I said
>> in earlier patches, it was remainder of the pen release code
>> which was borrowed from ARM code initially.
> 
> What about hotplug after the system is suspended?  Is this setup
> preserved by the secure ROM?
>
> If not, it really needs to be part of the CPU bringup, not the
> boot-time-only preparation code.
>
Its already the case. Hotplug CPU restarts just like CPU bring-up.
Initial code, hotplug cpu and last cpu(suspend) were taking identical
path for the suspend wakeup. Later you suggested after the discussion
that hotplug CPU state need not be saved and can be restarted just like
the CPU bring-up path.

So the current code follows above.

Regards,
Santosh




 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Russell King - ARM Linux March 28, 2013, 12:04 p.m. UTC | #7
On Thu, Mar 28, 2013 at 03:28:12PM +0530, Santosh Shilimkar wrote:
> On Thursday 28 March 2013 03:16 PM, Russell King - ARM Linux wrote:
> > On Thu, Mar 28, 2013 at 12:34:50AM +0530, Santosh Shilimkar wrote:
> >> On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
> >>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> >>>
> >>>> Move the secondary CPU wakeup prepare code under smp_prepare_cpus(). 
> >>>
> >>> Why?
> >>>
> >> Because that code belongs to smp_prepare_cpus(). As I said
> >> in earlier patches, it was remainder of the pen release code
> >> which was borrowed from ARM code initially.
> > 
> > What about hotplug after the system is suspended?  Is this setup
> > preserved by the secure ROM?
> >
> > If not, it really needs to be part of the CPU bringup, not the
> > boot-time-only preparation code.
> >
> Its already the case. Hotplug CPU restarts just like CPU bring-up.
> Initial code, hotplug cpu and last cpu(suspend) were taking identical
> path for the suspend wakeup. Later you suggested after the discussion
> that hotplug CPU state need not be saved and can be restarted just like
> the CPU bring-up path.
> 
> So the current code follows above.

smp_prepare_cpus() doesn't get run apart from at initial boot.

So, I repeat my question: what restores OMAP_AUX_CORE_BOOT_1 after
context loss?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Santosh Shilimkar March 28, 2013, 12:09 p.m. UTC | #8
On Thursday 28 March 2013 05:34 PM, Russell King - ARM Linux wrote:
> On Thu, Mar 28, 2013 at 03:28:12PM +0530, Santosh Shilimkar wrote:
>> On Thursday 28 March 2013 03:16 PM, Russell King - ARM Linux wrote:
>>> On Thu, Mar 28, 2013 at 12:34:50AM +0530, Santosh Shilimkar wrote:
>>>> On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
>>>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>>>
>>>>>> Move the secondary CPU wakeup prepare code under smp_prepare_cpus(). 
>>>>>
>>>>> Why?
>>>>>
>>>> Because that code belongs to smp_prepare_cpus(). As I said
>>>> in earlier patches, it was remainder of the pen release code
>>>> which was borrowed from ARM code initially.
>>>
>>> What about hotplug after the system is suspended?  Is this setup
>>> preserved by the secure ROM?
>>>
>>> If not, it really needs to be part of the CPU bringup, not the
>>> boot-time-only preparation code.
>>>
>> Its already the case. Hotplug CPU restarts just like CPU bring-up.
>> Initial code, hotplug cpu and last cpu(suspend) were taking identical
>> path for the suspend wakeup. Later you suggested after the discussion
>> that hotplug CPU state need not be saved and can be restarted just like
>> the CPU bring-up path.
>>
>> So the current code follows above.
> 
> smp_prepare_cpus() doesn't get run apart from at initial boot.
> 
> So, I repeat my question: what restores OMAP_AUX_CORE_BOOT_1 after
> context loss?
> 
Sorry I missed your point. OMAP_AUX_CORE_BOOT_* registers
are maintained across power transitions.

Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 7d29a74..9711ecd 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -164,36 +164,6 @@  static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
 	return 0;
 }
 
-static void __init wakeup_secondary(void)
-{
-	void *startup_addr = omap_secondary_startup;
-	void __iomem *base = omap_get_wakeupgen_base();
-
-	if (cpu_is_omap446x()) {
-		startup_addr = omap_secondary_startup_4460;
-		pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
-	}
-
-	/*
-	 * Write the address of secondary startup routine into the
-	 * AuxCoreBoot1 where ROM code will jump and start executing
-	 * on secondary core once out of WFE
-	 * A barrier is added to ensure that write buffer is drained
-	 */
-	if (omap_secure_apis_support())
-		omap_auxcoreboot_addr(virt_to_phys(startup_addr));
-	else
-		__raw_writel(virt_to_phys(omap5_secondary_startup),
-						base + OMAP_AUX_CORE_BOOT_1);
-
-	/*
-	 * Send a 'sev' to wake the secondary core from WFE.
-	 * Drain the outstanding writes to memory
-	 */
-	dsb_sev();
-	mb();
-}
-
 /*
  * Initialise the CPU possible map early - this describes the CPUs
  * which may be present or become present in the system.
@@ -231,6 +201,8 @@  static void __init omap4_smp_init_cpus(void)
 
 static void __init omap4_smp_prepare_cpus(unsigned int max_cpus)
 {
+	void *startup_addr = omap_secondary_startup;
+	void __iomem *base = omap_get_wakeupgen_base();
 
 	/*
 	 * Initialise the SCU and wake up the secondary core using
@@ -238,7 +210,24 @@  static void __init omap4_smp_prepare_cpus(unsigned int max_cpus)
 	 */
 	if (scu_base)
 		scu_enable(scu_base);
-	wakeup_secondary();
+
+	if (cpu_is_omap446x()) {
+		startup_addr = omap_secondary_startup_4460;
+		pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
+	}
+
+	/*
+	 * Write the address of secondary startup routine into the
+	 * AuxCoreBoot1 where ROM code will jump and start executing
+	 * on secondary core once out of WFE
+	 * A barrier is added to ensure that write buffer is drained
+	 */
+	if (omap_secure_apis_support())
+		omap_auxcoreboot_addr(virt_to_phys(startup_addr));
+	else
+		__raw_writel(virt_to_phys(omap5_secondary_startup),
+						base + OMAP_AUX_CORE_BOOT_1);
+
 }
 
 struct smp_operations omap4_smp_ops __initdata = {