| Message ID | 1361373527-21695-8-git-send-email-santosh.shilimkar@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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
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
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
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
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
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
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 --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 = {
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(-)