| Message ID | 5016D03D.8010607@codeaurora.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Stephen Boyd wrote: > > On 07/10/12 23:34, Kukjin Kim wrote: > > Stephen Boyd wrote: > >> Great. Kukjin Kim, can exynos use SGI0? It looks like exynos is the > only > >> one left to move to SGI0. > >> > > Yeah, EXYNOS can use SGI0 instead of SGI1 :) > > > > > > Russell, can we apply something like this? > Please feel free to add my ack on following change. Acked-by: Kukjin Kim <kgene.kim@samsung.com> Thanks. Best regards, Kgene. -- Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. > diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach- > exynos/platsmp.c > index 36c3984..090e32b 100644 > --- a/arch/arm/mach-exynos/platsmp.c > +++ b/arch/arm/mach-exynos/platsmp.c > @@ -139,7 +139,7 @@ int __cpuinit boot_secondary(unsigned int cpu, struct > task_struct *idle) > > __raw_writel(virt_to_phys(exynos4_secondary_startup), > CPU1_BOOT_REG); > - gic_raise_softirq(cpumask_of(cpu), 1); > + gic_raise_softirq(cpumask_of(cpu), 0); > > if (pen_release == -1) > break; > > > I see we have another user of SGI1. Magnus/Rafael, can we move > smp-emev2.c to use SGI0 instead of SGI1? > > -- > Sent by an employee of the Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
On Wed, Aug 1, 2012 at 2:42 AM, Kukjin Kim <kgene.kim@samsung.com> wrote: > Stephen Boyd wrote: >> >> On 07/10/12 23:34, Kukjin Kim wrote: >> > Stephen Boyd wrote: >> >> Great. Kukjin Kim, can exynos use SGI0? It looks like exynos is the >> only >> >> one left to move to SGI0. >> >> >> > Yeah, EXYNOS can use SGI0 instead of SGI1 :) >> > >> > >> >> Russell, can we apply something like this? >> > Please feel free to add my ack on following change. > > Acked-by: Kukjin Kim <kgene.kim@samsung.com> > When testing coupled cpuidle on Exynos5, I found that sending an IPI does not successfully wake up CPU1. CPU1 is in a wfe with interrupts masked, not a wfi, so an interrupt is not able to wake it up. It tends to wake up anyways because the next time a spin lock is unlocked, often during a timer interrupt on CPU0, CPU0 executes an sev which wakes up CPU1. You can see that the IPI is unnecessary by removing the gic_raise_softirq and replacing it with dsb_sev().
On Mon, Aug 06, 2012 at 01:41:06PM -0700, Colin Cross wrote: > When testing coupled cpuidle on Exynos5, I found that sending an IPI > does not successfully wake up CPU1. CPU1 is in a wfe with interrupts > masked, not a wfi, so an interrupt is not able to wake it up. It > tends to wake up anyways because the next time a spin lock is > unlocked, often during a timer interrupt on CPU0, CPU0 executes an sev > which wakes up CPU1. You can see that the IPI is unnecessary by > removing the gic_raise_softirq and replacing it with dsb_sev(). That's good news; that supports my assertion that the SMP bringup code we see on various platforms as copies from the Realview code was done without much thought about what is actually required. It's good that you're looking into this, and fixing the code on the CPUs you have access to. I rather wish we'd made it a requirement for people to _document_ the actual bringup conditions in the kernel for their hardware before we accepted their SMP support code.
On Tue, Aug 7, 2012 at 10:30 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Aug 06, 2012 at 01:41:06PM -0700, Colin Cross wrote: >> When testing coupled cpuidle on Exynos5, I found that sending an IPI >> does not successfully wake up CPU1. CPU1 is in a wfe with interrupts >> masked, not a wfi, so an interrupt is not able to wake it up. It >> tends to wake up anyways because the next time a spin lock is >> unlocked, often during a timer interrupt on CPU0, CPU0 executes an sev >> which wakes up CPU1. You can see that the IPI is unnecessary by >> removing the gic_raise_softirq and replacing it with dsb_sev(). > > That's good news; that supports my assertion that the SMP bringup code > we see on various platforms as copies from the Realview code was done > without much thought about what is actually required. > > It's good that you're looking into this, and fixing the code on the CPUs > you have access to. I rather wish we'd made it a requirement for people > to _document_ the actual bringup conditions in the kernel for their > hardware before we accepted their SMP support code. > Movement to SGI0 for all ARM platform was also discussed when I was trying to fix the "Unknown IPI message 0x1" warning with patch [1] For OMAP too, the SGI0 works. Regards Santosh [1 ] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-January/038430.html
Colin Cross wrote: > > On Wed, Aug 1, 2012 at 2:42 AM, Kukjin Kim <kgene.kim@samsung.com> wrote: > > Stephen Boyd wrote: > >> > >> On 07/10/12 23:34, Kukjin Kim wrote: > >> > Stephen Boyd wrote: > >> >> Great. Kukjin Kim, can exynos use SGI0? It looks like exynos is the > >> only > >> >> one left to move to SGI0. > >> >> > >> > Yeah, EXYNOS can use SGI0 instead of SGI1 :) > >> > > >> > > >> > >> Russell, can we apply something like this? > >> > > Please feel free to add my ack on following change. > > > > Acked-by: Kukjin Kim <kgene.kim@samsung.com> > > > > When testing coupled cpuidle on Exynos5, I found that sending an IPI > does not successfully wake up CPU1. CPU1 is in a wfe with interrupts > masked, not a wfi, so an interrupt is not able to wake it up. It > tends to wake up anyways because the next time a spin lock is > unlocked, often during a timer interrupt on CPU0, CPU0 executes an sev > which wakes up CPU1. You can see that the IPI is unnecessary by > removing the gic_raise_softirq and replacing it with dsb_sev(). Hmm...could be. Let me check you commented in detail. And if any updates, I'll let you know. Thanks for your information. Best regards, Kgene. -- Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c index 36c3984..090e32b 100644 --- a/arch/arm/mach-exynos/platsmp.c +++ b/arch/arm/mach-exynos/platsmp.c @@ -139,7 +139,7 @@ int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle) __raw_writel(virt_to_phys(exynos4_secondary_startup), CPU1_BOOT_REG); - gic_raise_softirq(cpumask_of(cpu), 1); + gic_raise_softirq(cpumask_of(cpu), 0); if (pen_release == -1) break;