RFC, GIC based smp_cross_call cleanup suggestion

RFC, GIC based smp_cross_call cleanup suggestion

[John Linn]

I'm getting ready to submit a patch to add SMP to Xilinx code. I notice
that smp_cross_call for all GIC based platforms is duplicated across
each platform in smp.h.

 

I thought I'd try to jump in to help with some cleanup, although I
realize it's minimal, I have to start somewhere.

 

What about moving the smp_cross_call for GIC based designs into gic.h?

 

Or other suggestions?

 

Thanks

John



This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110401/f914f022/attachment-0001.html>

RFC, GIC based smp_cross_call cleanup suggestion

[Grant Likely]

On Fri, Apr 1, 2011 at 4:26 PM, John Linn <John.Linn@xilinx.com> wrote:
> I?m getting ready to submit a patch to add SMP to Xilinx code. I notice that
> smp_cross_call for all GIC based platforms is duplicated across each
> platform in smp.h.
>
>
>
> I thought I?d try to jump in to help with some cleanup, although I realize
> it?s minimal, I have to start somewhere.
>
>
>
> What about moving the smp_cross_call for GIC based designs into gic.h?

Go for it.  It's an obvious cleanup.

g.

RFC, GIC based smp_cross_call cleanup suggestion

[Russell King - ARM Linux]

On Fri, Apr 01, 2011 at 04:55:02PM -0600, Grant Likely wrote:
> On Fri, Apr 1, 2011 at 4:26 PM, John Linn <John.Linn@xilinx.com> wrote:
> > I?m getting ready to submit a patch to add SMP to Xilinx code. I notice that
> > smp_cross_call for all GIC based platforms is duplicated across each
> > platform in smp.h.
> >
> >
> >
> > I thought I?d try to jump in to help with some cleanup, although I realize
> > it?s minimal, I have to start somewhere.
> >
> >
> >
> > What about moving the smp_cross_call for GIC based designs into gic.h?
> 
> Go for it.  It's an obvious cleanup.

That assumes that all SMP implementations will always have a GIC.  It
looks to me like this is conditional on shmobile, and so I don't think
its that trivial - maybe Paul or Magnus can first indicate why this is.

RFC, GIC based smp_cross_call cleanup suggestion

[Colin Cross]

On Sat, Apr 2, 2011 at 1:51 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 01, 2011 at 04:55:02PM -0600, Grant Likely wrote:
>> On Fri, Apr 1, 2011 at 4:26 PM, John Linn <John.Linn@xilinx.com> wrote:
>> > I?m getting ready to submit a patch to add SMP to Xilinx code. I notice that
>> > smp_cross_call for all GIC based platforms is duplicated across each
>> > platform in smp.h.
>> >
>> >
>> >
>> > I thought I?d try to jump in to help with some cleanup, although I realize
>> > it?s minimal, I have to start somewhere.
>> >
>> >
>> >
>> > What about moving the smp_cross_call for GIC based designs into gic.h?
>>
>> Go for it. ?It's an obvious cleanup.
>
> That assumes that all SMP implementations will always have a GIC. ?It
> looks to me like this is conditional on shmobile, and so I don't think
> its that trivial - maybe Paul or Magnus can first indicate why this is.

OMAP4 may also require a custom smp_cross_call implementation if CPU
idle is going to be supported in SMP - in CPU off idle modes, a GIC
SGI will not wake the CPU, and a write directly to the CPU's power
management controller or an external interrupt source would be
required.

RFC, GIC based smp_cross_call cleanup suggestion

[Grant Likely]

On Sat, Apr 2, 2011 at 3:10 AM, Colin Cross <ccross@google.com> wrote:
> On Sat, Apr 2, 2011 at 1:51 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Fri, Apr 01, 2011 at 04:55:02PM -0600, Grant Likely wrote:
>>> On Fri, Apr 1, 2011 at 4:26 PM, John Linn <John.Linn@xilinx.com> wrote:
>>> > I?m getting ready to submit a patch to add SMP to Xilinx code. I notice that
>>> > smp_cross_call for all GIC based platforms is duplicated across each
>>> > platform in smp.h.
>>> >
>>> >
>>> >
>>> > I thought I?d try to jump in to help with some cleanup, although I realize
>>> > it?s minimal, I have to start somewhere.
>>> >
>>> >
>>> >
>>> > What about moving the smp_cross_call for GIC based designs into gic.h?
>>>
>>> Go for it. ?It's an obvious cleanup.
>>
>> That assumes that all SMP implementations will always have a GIC. ?It
>> looks to me like this is conditional on shmobile, and so I don't think
>> its that trivial - maybe Paul or Magnus can first indicate why this is.
>
> OMAP4 may also require a custom smp_cross_call implementation if CPU
> idle is going to be supported in SMP - in CPU off idle modes, a GIC
> SGI will not wake the CPU, and a write directly to the CPU's power
> management controller or an external interrupt source would be
> required.

What John proposes appears to be a pretty sane default though.  It
would make sense to move it to common code, and require explicit
action on the part of the subarch to compile it out for a different
behaviour.  Requiring each subarch to define it explicitly doesn't
seem optimal.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

RFC, GIC based smp_cross_call cleanup suggestion

[Russell King - ARM Linux]

On Sat, Apr 02, 2011 at 10:47:57PM -0600, Grant Likely wrote:
> On Sat, Apr 2, 2011 at 3:10 AM, Colin Cross <ccross@google.com> wrote:
> > On Sat, Apr 2, 2011 at 1:51 AM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> >> On Fri, Apr 01, 2011 at 04:55:02PM -0600, Grant Likely wrote:
> >>> On Fri, Apr 1, 2011 at 4:26 PM, John Linn <John.Linn@xilinx.com> wrote:
> >>> > I?m getting ready to submit a patch to add SMP to Xilinx code. I notice that
> >>> > smp_cross_call for all GIC based platforms is duplicated across each
> >>> > platform in smp.h.
> >>> >
> >>> >
> >>> >
> >>> > I thought I?d try to jump in to help with some cleanup, although I realize
> >>> > it?s minimal, I have to start somewhere.
> >>> >
> >>> >
> >>> >
> >>> > What about moving the smp_cross_call for GIC based designs into gic.h?
> >>>
> >>> Go for it. ?It's an obvious cleanup.
> >>
> >> That assumes that all SMP implementations will always have a GIC. ?It
> >> looks to me like this is conditional on shmobile, and so I don't think
> >> its that trivial - maybe Paul or Magnus can first indicate why this is.
> >
> > OMAP4 may also require a custom smp_cross_call implementation if CPU
> > idle is going to be supported in SMP - in CPU off idle modes, a GIC
> > SGI will not wake the CPU, and a write directly to the CPU's power
> > management controller or an external interrupt source would be
> > required.
> 
> What John proposes appears to be a pretty sane default though.  It
> would make sense to move it to common code, and require explicit
> action on the part of the subarch to compile it out for a different
> behaviour.  Requiring each subarch to define it explicitly doesn't
> seem optimal.

Bear in mind that the GIC doesn't do any PM support, so the hardware
folk are inventing their own IRQ controller to sit along side the GIC
to provide that missing functionality.  What I expect will happen is
that the GIC will be obsoleted and replaced by something integrating
PM support.

So we could end up in the situation where we need both GIC and something
else in the kernel at the same time - especially if we persue the single
kernel image thing.  Moving smp_cross_call() into gic.h would add an
additional bar to that happening.

A better solution may be to make smp_cross_call() be a function pointer
which must be initialized as part of the platforms SMP initialization.
That'd get rid of mach/smp.h entirely.

Oh, and while looking at that, guess what annoyingly stands in the way
of eliminating mach/smp.h ?  Yes, it's OMAP, because they've bunged some
function prototypes into plat/smp.h.  (I've not cared about that in the
patch below; I've deleted the entire thing, so it probably breaks OMAP.)

 arch/arm/include/asm/smp.h                |    6 +----
 arch/arm/kernel/smp.c                     |    7 +++++
 arch/arm/mach-exynos4/include/mach/smp.h  |   19 ---------------
 arch/arm/mach-exynos4/platsmp.c           |    5 +++-
 arch/arm/mach-msm/include/mach/smp.h      |   23 -------------------
 arch/arm/mach-msm/platsmp.c               |    4 ++-
 arch/arm/mach-omap2/omap-smp.c            |    5 +++-
 arch/arm/mach-realview/include/mach/smp.h |   14 -----------
 arch/arm/mach-realview/platsmp.c          |    3 ++
 arch/arm/mach-shmobile/include/mach/smp.h |   16 -------------
 arch/arm/mach-shmobile/platsmp.c          |    3 ++
 arch/arm/mach-tegra/include/mach/smp.h    |   14 -----------
 arch/arm/mach-tegra/platsmp.c             |    3 ++
 arch/arm/mach-ux500/include/mach/smp.h    |   24 --------------------
 arch/arm/mach-ux500/platsmp.c             |    5 +++-
 arch/arm/mach-vexpress/ct-ca9x4.c         |    2 +
 arch/arm/mach-vexpress/include/mach/smp.h |   13 ----------
 arch/arm/plat-omap/include/plat/smp.h     |   36 ------------------------------
 arch/arm/plat-versatile/platsmp.c         |    3 +-
 19 files changed, 37 insertions(+), 168 deletions(-)

diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h
index 96ed521..27d1c95 100644
--- a/arch/arm/include/asm/smp.h
+++ b/arch/arm/include/asm/smp.h
@@ -14,8 +14,6 @@
 #include <linux/cpumask.h>
 #include <linux/thread_info.h>
 
-#include <mach/smp.h>
-
 #ifndef CONFIG_SMP
 # error "<asm/smp.h> included in non-SMP build"
 #endif
@@ -47,9 +45,9 @@ extern void smp_init_cpus(void);
 
 
 /*
- * Raise an IPI cross call on CPUs in callmap.
+ * Provide a function to raise an IPI cross call on CPUs in callmap.
  */
-extern void smp_cross_call(const struct cpumask *mask, int ipi);
+extern void smp_set_cross_call(void (*fn)(const struct cpumask *, int));
 
 /*
  * Boot a secondary CPU, and assign it the specified idle task.
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 8fe05ad..c58bae9 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -376,6 +376,13 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
 	}
 }
 
+static void (*smp_cross_call)(const struct cpumask *, int);
+
+void __init smp_set_cross_call(void (*fn)(const struct cpumask *, int))
+{
+	smp_cross_call = fn;
+}
+
 void arch_send_call_function_ipi_mask(const struct cpumask *mask)
 {
 	smp_cross_call(mask, IPI_CALL_FUNC);
diff --git a/arch/arm/mach-exynos4/include/mach/smp.h b/arch/arm/mach-exynos4/include/mach/smp.h
deleted file mode 100644
index a463dce..0000000
--- a/arch/arm/mach-exynos4/include/mach/smp.h
+++ /dev/null
@@ -1,19 +0,0 @@
-/* linux/arch/arm/mach-exynos4/include/mach/smp.h
- *
- * Cloned from arch/arm/mach-realview/include/mach/smp.h
-*/
-
-#ifndef ASM_ARCH_SMP_H
-#define ASM_ARCH_SMP_H __FILE__
-
-#include <asm/hardware/gic.h>
-
-/*
- * We use IRQ1 as the IPI
- */
-static inline void smp_cross_call(const struct cpumask *mask, int ipi)
-{
-	gic_raise_softirq(mask, ipi);
-}
-
-#endif
diff --git a/arch/arm/mach-exynos4/platsmp.c b/arch/arm/mach-exynos4/platsmp.c
index 6d35878..8403dd2 100644
--- a/arch/arm/mach-exynos4/platsmp.c
+++ b/arch/arm/mach-exynos4/platsmp.c
@@ -22,6 +22,7 @@
 #include <linux/io.h>
 
 #include <asm/cacheflush.h>
+#include <asm/hardare/gic.h>
 #include <asm/smp_scu.h>
 #include <asm/unified.h>
 
@@ -104,7 +105,7 @@ int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
 	 * the boot monitor to read the system wide flags register,
 	 * and branch to the address found there.
 	 */
-	smp_cross_call(cpumask_of(cpu), 1);
+	gic_raise_softirq(cpumask_of(cpu), 1);
 
 	timeout = jiffies + (1 * HZ);
 	while (time_before(jiffies, timeout)) {
@@ -147,6 +148,8 @@ void __init smp_init_cpus(void)
 
 	for (i = 0; i < ncores; i++)
 		set_cpu_possible(i, true);
+
+	set_smp_cross_call(gic_raise_softirq);
 }
 
 void __init platform_smp_prepare_cpus(unsigned int max_cpus)
diff --git a/arch/arm/mach-msm/include/mach/smp.h b/arch/arm/mach-msm/include/mach/smp.h
deleted file mode 100644
index 3c01000..0000000
--- a/arch/arm/mach-msm/include/mach/smp.h
+++ /dev/null
@@ -1,23 +0,0 @@
-/* Copyright (c) 2010, Code Aurora Forum. 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 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#ifndef __ASM_ARCH_MSM_SMP_H
-#define __ASM_ARCH_MSM_SMP_H
-
-#include <asm/hardware/gic.h>
-
-static inline void smp_cross_call(const struct cpumask *mask, int ipi)
-{
-	gic_raise_softirq(mask, ipi);
-}
-
-#endif
diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
index 0f427bc..2034098 100644
--- a/arch/arm/mach-msm/platsmp.c
+++ b/arch/arm/mach-msm/platsmp.c
@@ -119,7 +119,7 @@ int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
 	 * the boot monitor to read the system wide flags register,
 	 * and branch to the address found there.
 	 */
-	smp_cross_call(cpumask_of(cpu), 1);
+	gic_raise_softirq(cpumask_of(cpu), 1);
 
 	timeout = jiffies + (1 * HZ);
 	while (time_before(jiffies, timeout)) {
@@ -151,6 +151,8 @@ void __init smp_init_cpus(void)
 
 	for (i = 0; i < NR_CPUS; i++)
 		set_cpu_possible(i, true);
+
+	set_smp_cross_call(gic_raise_softirq);
 }
 
 void __init platform_smp_prepare_cpus(unsigned int max_cpus)
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index b66cfe8..ecfe93c 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -21,6 +21,7 @@
 #include <linux/io.h>
 
 #include <asm/cacheflush.h>
+#include <asm/hardware/gic.h>
 #include <asm/smp_scu.h>
 #include <mach/hardware.h>
 #include <mach/omap4-common.h>
@@ -63,7 +64,7 @@ int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
 	omap_modify_auxcoreboot0(0x200, 0xfffffdff);
 	flush_cache_all();
 	smp_wmb();
-	smp_cross_call(cpumask_of(cpu), 1);
+	gic_raise_softirq(cpumask_of(cpu), 1);
 
 	/*
 	 * Now the secondary core is starting up let it run its
@@ -118,6 +119,8 @@ void __init smp_init_cpus(void)
 
 	for (i = 0; i < ncores; i++)
 		set_cpu_possible(i, true);
+
+	set_smp_cross_call(gic_raise_softirq);
 }
 
 void __init platform_smp_prepare_cpus(unsigned int max_cpus)
diff --git a/arch/arm/mach-realview/include/mach/smp.h b/arch/arm/mach-realview/include/mach/smp.h
deleted file mode 100644
index c8221b3..0000000
--- a/arch/arm/mach-realview/include/mach/smp.h
+++ /dev/null
@@ -1,14 +0,0 @@
-#ifndef ASMARM_ARCH_SMP_H
-#define ASMARM_ARCH_SMP_H
-
-#include <asm/hardware/gic.h>
-
-/*
- * We use IRQ1 as the IPI
- */
-static inline void smp_cross_call(const struct cpumask *mask, int ipi)
-{
-	gic_raise_softirq(mask, ipi);
-}
-
-#endif
diff --git a/arch/arm/mach-realview/platsmp.c b/arch/arm/mach-realview/platsmp.c
index 2391922..963bf0d 100644
--- a/arch/arm/mach-realview/platsmp.c
+++ b/arch/arm/mach-realview/platsmp.c
@@ -14,6 +14,7 @@
 #include <linux/io.h>
 
 #include <mach/hardware.h>
+#include <asm/hardware/gic.h>
 #include <asm/mach-types.h>
 #include <asm/smp_scu.h>
 #include <asm/unified.h>
@@ -61,6 +62,8 @@ void __init smp_init_cpus(void)
 
 	for (i = 0; i < ncores; i++)
 		set_cpu_possible(i, true);
+
+	set_smp_cross_call(gic_raise_softirq);
 }
 
 void __init platform_smp_prepare_cpus(unsigned int max_cpus)
diff --git a/arch/arm/mach-shmobile/include/mach/smp.h b/arch/arm/mach-shmobile/include/mach/smp.h
deleted file mode 100644
index 50db94e..0000000
--- a/arch/arm/mach-shmobile/include/mach/smp.h
+++ /dev/null
@@ -1,16 +0,0 @@
-#ifndef __MACH_SMP_H
-#define __MACH_SMP_H
-
-#include <asm/hardware/gic.h>
-
-/*
- * We use IRQ1 as the IPI
- */
-static inline void smp_cross_call(const struct cpumask *mask, int ipi)
-{
-#if defined(CONFIG_ARM_GIC)
-	gic_raise_softirq(mask, ipi);
-#endif
-}
-
-#endif
diff --git a/arch/arm/mach-shmobile/platsmp.c b/arch/arm/mach-shmobile/platsmp.c
index 65e879b..f3888fe 100644
--- a/arch/arm/mach-shmobile/platsmp.c
+++ b/arch/arm/mach-shmobile/platsmp.c
@@ -16,6 +16,7 @@
 #include <linux/device.h>
 #include <linux/smp.h>
 #include <linux/io.h>
+#include <asm/hardware/gic.h>
 #include <asm/localtimer.h>
 #include <asm/mach-types.h>
 #include <mach/common.h>
@@ -57,6 +58,8 @@ void __init smp_init_cpus(void)
 
 	for (i = 0; i < ncores; i++)
 		set_cpu_possible(i, true);
+
+	set_smp_cross_call(gic_raise_softirq);
 }
 
 void __init platform_smp_prepare_cpus(unsigned int max_cpus)
diff --git a/arch/arm/mach-tegra/include/mach/smp.h b/arch/arm/mach-tegra/include/mach/smp.h
deleted file mode 100644
index c8221b3..0000000
--- a/arch/arm/mach-tegra/include/mach/smp.h
+++ /dev/null
@@ -1,14 +0,0 @@
-#ifndef ASMARM_ARCH_SMP_H
-#define ASMARM_ARCH_SMP_H
-
-#include <asm/hardware/gic.h>
-
-/*
- * We use IRQ1 as the IPI
- */
-static inline void smp_cross_call(const struct cpumask *mask, int ipi)
-{
-	gic_raise_softirq(mask, ipi);
-}
-
-#endif
diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
index ec1f689..b8ae3c9 100644
--- a/arch/arm/mach-tegra/platsmp.c
+++ b/arch/arm/mach-tegra/platsmp.c
@@ -20,6 +20,7 @@
 #include <linux/io.h>
 
 #include <asm/cacheflush.h>
+#include <asm/hardware/gic.h>
 #include <mach/hardware.h>
 #include <asm/mach-types.h>
 #include <asm/smp_scu.h>
@@ -122,6 +123,8 @@ void __init smp_init_cpus(void)
 
 	for (i = 0; i < ncores; i++)
 		cpu_set(i, cpu_possible_map);
+
+	set_smp_cross_call(gic_raise_softirq);
 }
 
 void __init platform_smp_prepare_cpus(unsigned int max_cpus)
diff --git a/arch/arm/mach-ux500/include/mach/smp.h b/arch/arm/mach-ux500/include/mach/smp.h
deleted file mode 100644
index ca2b15b..0000000
--- a/arch/arm/mach-ux500/include/mach/smp.h
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * This file is based ARM realview platform.
- * Copyright (C) ARM Limited.
- *
- * This file is licensed under  the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-#ifndef ASMARM_ARCH_SMP_H
-#define ASMARM_ARCH_SMP_H
-
-#include <asm/hardware/gic.h>
-
-/* This is required to wakeup the secondary core */
-extern void u8500_secondary_startup(void);
-
-/*
- * We use IRQ1 as the IPI
- */
-static inline void smp_cross_call(const struct cpumask *mask, int ipi)
-{
-	gic_raise_softirq(mask, ipi);
-}
-#endif
diff --git a/arch/arm/mach-ux500/platsmp.c b/arch/arm/mach-ux500/platsmp.c
index 4fff4d4..4e33846 100644
--- a/arch/arm/mach-ux500/platsmp.c
+++ b/arch/arm/mach-ux500/platsmp.c
@@ -18,6 +18,7 @@
 #include <linux/io.h>
 
 #include <asm/cacheflush.h>
+#include <asm/hardware/gic.h>
 #include <asm/smp_scu.h>
 #include <mach/hardware.h>
 #include <mach/setup.h>
@@ -94,7 +95,7 @@ int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
 	 */
 	write_pen_release(cpu);
 
-	smp_cross_call(cpumask_of(cpu), 1);
+	gic_raise_softirq(cpumask_of(cpu), 1);
 
 	timeout = jiffies + (1 * HZ);
 	while (time_before(jiffies, timeout)) {
@@ -162,6 +163,8 @@ void __init smp_init_cpus(void)
 
 	for (i = 0; i < ncores; i++)
 		set_cpu_possible(i, true);
+
+	set_smp_cross_call(gic_raise_softirq);
 }
 
 void __init platform_smp_prepare_cpus(unsigned int max_cpus)
diff --git a/arch/arm/mach-vexpress/ct-ca9x4.c b/arch/arm/mach-vexpress/ct-ca9x4.c
index ebc22e7..9dc1c69 100644
--- a/arch/arm/mach-vexpress/ct-ca9x4.c
+++ b/arch/arm/mach-vexpress/ct-ca9x4.c
@@ -210,6 +210,8 @@ static void ct_ca9x4_init_cpu_map(void)
 
 	for (i = 0; i < ncores; ++i)
 		set_cpu_possible(i, true);
+
+	set_smp_cross_call(gic_raise_softirq);
 }
 
 static void ct_ca9x4_smp_enable(unsigned int max_cpus)
diff --git a/arch/arm/mach-vexpress/include/mach/smp.h b/arch/arm/mach-vexpress/include/mach/smp.h
deleted file mode 100644
index 4c05e4a..0000000
--- a/arch/arm/mach-vexpress/include/mach/smp.h
+++ /dev/null
@@ -1,13 +0,0 @@
-#ifndef __MACH_SMP_H
-#define __MACH_SMP_H
-
-#include <asm/hardware/gic.h>
-
-/*
- * We use IRQ1 as the IPI
- */
-static inline void smp_cross_call(const struct cpumask *mask, int ipi)
-{
-	gic_raise_softirq(mask, ipi);
-}
-#endif
diff --git a/arch/arm/plat-omap/include/plat/smp.h b/arch/arm/plat-omap/include/plat/smp.h
deleted file mode 100644
index 7a10257..0000000
--- a/arch/arm/plat-omap/include/plat/smp.h
+++ /dev/null
@@ -1,36 +0,0 @@
-/*
- * OMAP4 machine specific smp.h
- *
- * Copyright (C) 2009 Texas Instruments, Inc.
- *
- * Author:
- *	Santosh Shilimkar <santosh.shilimkar@ti.com>
- *
- * Interface functions needed for the SMP. This file is based on arm
- * realview smp platform.
- * Copyright (c) 2003 ARM Limited.
- *
- * 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.
- */
-#ifndef OMAP_ARCH_SMP_H
-#define OMAP_ARCH_SMP_H
-
-#include <asm/hardware/gic.h>
-
-/* Needed for secondary core boot */
-extern void omap_secondary_startup(void);
-extern u32 omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask);
-extern void omap_auxcoreboot_addr(u32 cpu_addr);
-extern u32 omap_read_auxcoreboot0(void);
-
-/*
- * We use Soft IRQ1 as the IPI
- */
-static inline void smp_cross_call(const struct cpumask *mask, int ipi)
-{
-	gic_raise_softirq(mask, ipi);
-}
-
-#endif
diff --git a/arch/arm/plat-versatile/platsmp.c b/arch/arm/plat-versatile/platsmp.c
index ba3d471..51ecfea 100644
--- a/arch/arm/plat-versatile/platsmp.c
+++ b/arch/arm/plat-versatile/platsmp.c
@@ -16,6 +16,7 @@
 #include <linux/smp.h>
 
 #include <asm/cacheflush.h>
+#include <asm/hardware/gic.h>
 
 /*
  * control for which core is the next to come out of the secondary
@@ -83,7 +84,7 @@ int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
 	 * the boot monitor to read the system wide flags register,
 	 * and branch to the address found there.
 	 */
-	smp_cross_call(cpumask_of(cpu), 1);
+	gic_raise_softirq(cpumask_of(cpu), 1);
 
 	timeout = jiffies + (1 * HZ);
 	while (time_before(jiffies, timeout)) {

RFC, GIC based smp_cross_call cleanup suggestion

[Santosh Shilimkar]

On 4/3/2011 4:07 PM, Russell King - ARM Linux wrote:
> On Sat, Apr 02, 2011 at 10:47:57PM -0600, Grant Likely wrote:
>> On Sat, Apr 2, 2011 at 3:10 AM, Colin Cross<ccross@google.com>  wrote:
>>> On Sat, Apr 2, 2011 at 1:51 AM, Russell King - ARM Linux
>>> <linux@arm.linux.org.uk>  wrote:
>>>> On Fri, Apr 01, 2011 at 04:55:02PM -0600, Grant Likely wrote:
>>>>> On Fri, Apr 1, 2011 at 4:26 PM, John Linn<John.Linn@xilinx.com>  wrote:
>>>>>> I?m getting ready to submit a patch to add SMP to Xilinx code. I notice that
>>>>>> smp_cross_call for all GIC based platforms is duplicated across each
>>>>>> platform in smp.h.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I thought I?d try to jump in to help with some cleanup, although I realize
>>>>>> it?s minimal, I have to start somewhere.
>>>>>>
>>>>>>
>>>>>>
>>>>>> What about moving the smp_cross_call for GIC based designs into gic.h?
>>>>>
>>>>> Go for it.  It's an obvious cleanup.
>>>>
>>>> That assumes that all SMP implementations will always have a GIC.  It
>>>> looks to me like this is conditional on shmobile, and so I don't think
>>>> its that trivial - maybe Paul or Magnus can first indicate why this is.
>>>
>>> OMAP4 may also require a custom smp_cross_call implementation if CPU
>>> idle is going to be supported in SMP - in CPU off idle modes, a GIC
>>> SGI will not wake the CPU, and a write directly to the CPU's power
>>> management controller or an external interrupt source would be
>>> required.
>>
>> What John proposes appears to be a pretty sane default though.  It
>> would make sense to move it to common code, and require explicit
>> action on the part of the subarch to compile it out for a different
>> behaviour.  Requiring each subarch to define it explicitly doesn't
>> seem optimal.
>
> Bear in mind that the GIC doesn't do any PM support, so the hardware
> folk are inventing their own IRQ controller to sit along side the GIC
> to provide that missing functionality.  What I expect will happen is
> that the GIC will be obsoleted and replaced by something integrating
> PM support.
>
> So we could end up in the situation where we need both GIC and something
> else in the kernel at the same time - especially if we persue the single
> kernel image thing.  Moving smp_cross_call() into gic.h would add an
> additional bar to that happening.
>
> A better solution may be to make smp_cross_call() be a function pointer
> which must be initialized as part of the platforms SMP initialization.
> That'd get rid of mach/smp.h entirely.
>
> Oh, and while looking at that, guess what annoyingly stands in the way
> of eliminating mach/smp.h ?  Yes, it's OMAP, because they've bunged some
> function prototypes into plat/smp.h.  (I've not cared about that in the
> patch below; I've deleted the entire thing, so it probably breaks OMAP.)
>
Sure, it does break OMAP4. These functions are there because they
are used/compiled only for SMP support.

If you plan to commit this change then I can move these to
other OMAP4 header file.

Regards
Santosh

RFC, GIC based smp_cross_call cleanup suggestion

[Russell King - ARM Linux]

On Sun, Apr 03, 2011 at 04:23:41PM +0530, Santosh Shilimkar wrote:
> Sure, it does break OMAP4. These functions are there because they
> are used/compiled only for SMP support.

If they're only used privately within the mach-omap2 code, then putting
them in a header file in arch/arm/mach-omap2 would've been the logical
thing to do, rather than telling the entire SMP kernel about the
functions.

Header files in arch/arm/*/include/mach included from
arch/arm/include/asm/*.h are there to provide necessary definitions for
either the rest of the kernel or the ARM specific parts.  They shouldn't
be polluted with *any* platform private stuff which is not absolutely
necessary to satisfy the rest of the kernel.  Those mach/ includes
being:

mach/barriers.h
mach/clkdev.h
mach/floppy.h
mach/gpio.h
mach/hardware.h
mach/io.h
mach/irqs.h
mach/isa-dma.h
mach/memory.h
mach/mtd-xip.h
mach/smp.h
mach/timex.h
mach/vmalloc.h

RFC, GIC based smp_cross_call cleanup suggestion

[Santosh Shilimkar]

On 4/3/2011 5:16 PM, Russell King - ARM Linux wrote:
> On Sun, Apr 03, 2011 at 04:23:41PM +0530, Santosh Shilimkar wrote:
>> Sure, it does break OMAP4. These functions are there because they
>> are used/compiled only for SMP support.
>
> If they're only used privately within the mach-omap2 code, then putting
> them in a header file in arch/arm/mach-omap2 would've been the logical
> thing to do, rather than telling the entire SMP kernel about the
> functions.
>
Ok. Make sense.

> Header files in arch/arm/*/include/mach included from
> arch/arm/include/asm/*.h are there to provide necessary definitions for
> either the rest of the kernel or the ARM specific parts.  They shouldn't
> be polluted with *any* platform private stuff which is not absolutely
> necessary to satisfy the rest of the kernel.  Those mach/ includes
> being:
>
> mach/barriers.h
> mach/clkdev.h
> mach/floppy.h
> mach/gpio.h
> mach/hardware.h
> mach/io.h
> mach/irqs.h
> mach/isa-dma.h
> mach/memory.h
> mach/mtd-xip.h
> mach/smp.h
> mach/timex.h
> mach/vmalloc.h
>
Thanks for the list. I shall move those to omap4-common.h
I didn't do it last time thinking file
"arch/arm/plat-omap/include/plat/smp.h" can have platform
specific functions as well.

I missed the point that "mach/smp.h" would be included
indirectly by "linux/smp.h"

Thanks for making this clear to me.

Regards
Santosh

RFC, GIC based smp_cross_call cleanup suggestion

[Russell King - ARM Linux]

On Sun, Apr 03, 2011 at 04:23:41PM +0530, Santosh Shilimkar wrote:
> If you plan to commit this change then I can move these to
> other OMAP4 header file.

Can you send me a patch to do that please?

Thanks.

RFC, GIC based smp_cross_call cleanup suggestion

[Santosh Shilimkar]

On 4/3/2011 7:18 PM, Russell King - ARM Linux wrote:
> On Sun, Apr 03, 2011 at 04:23:41PM +0530, Santosh Shilimkar wrote:
>> If you plan to commit this change then I can move these to
>> other OMAP4 header file.
>
> Can you send me a patch to do that please?
>
Here it is.. Generated against latest mainline.
Also attached just in case for any mailer issues.

 From 62563f7687d8b19f1c9c3966105d141d91e69b55 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Mon, 4 Apr 2011 12:48:37 +0530
Subject: [PATCH] OMAP4: Move the privately used SMP boot functions to 
OMAP specific header.

Header files in arch/arm/*/include/mach included from
arch/arm/include/asm/*.h are there to provide necessary definitions for
either the rest of the kernel or the ARM specific parts.  They shouldn't
be polluted with *any* platform private stuff which is not absolutely
necessary to satisfy the rest of the kernel.

Hence move the OMAP specific SMP boot functions to different header
instead of keeping them in 'plat/smp.h' which gets included indirectly
by linux/smp.h

The patch is outcome of the discussion in below thread:
	http://www.spinics.net/lists/arm-kernel/msg120363.html

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
  arch/arm/mach-omap2/include/mach/omap4-common.h |    7 +++++++
  arch/arm/plat-omap/include/plat/smp.h           |    6 ------
  2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h 
b/arch/arm/mach-omap2/include/mach/omap4-common.h
index de441c0..e4bd876 100644
--- a/arch/arm/mach-omap2/include/mach/omap4-common.h
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -33,4 +33,11 @@ extern void __iomem *gic_dist_base_addr;
  extern void __init gic_init_irq(void);
  extern void omap_smc1(u32 fn, u32 arg);

+#ifdef CONFIG_SMP
+/* Needed for secondary core boot */
+extern void omap_secondary_startup(void);
+extern u32 omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask);
+extern void omap_auxcoreboot_addr(u32 cpu_addr);
+extern u32 omap_read_auxcoreboot0(void);
+#endif
  #endif
diff --git a/arch/arm/plat-omap/include/plat/smp.h 
b/arch/arm/plat-omap/include/plat/smp.h
index 7a10257..416e9d5 100644
--- a/arch/arm/plat-omap/include/plat/smp.h
+++ b/arch/arm/plat-omap/include/plat/smp.h
@@ -19,12 +19,6 @@

  #include <asm/hardware/gic.h>

-/* Needed for secondary core boot */
-extern void omap_secondary_startup(void);
-extern u32 omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask);
-extern void omap_auxcoreboot_addr(u32 cpu_addr);
-extern u32 omap_read_auxcoreboot0(void);
-
  /*
   * We use Soft IRQ1 as the IPI
   */
-- 
1.6.0.4

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0001-OMAP4-Move-the-privately-used-SMP-boot-functions-to.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110404/77a8888d/attachment.ksh>

RFC, GIC based smp_cross_call cleanup suggestion

[Russell King - ARM Linux]

On Mon, Apr 04, 2011 at 01:50:35PM +0530, Santosh Shilimkar wrote:
> On 4/3/2011 7:18 PM, Russell King - ARM Linux wrote:
>> On Sun, Apr 03, 2011 at 04:23:41PM +0530, Santosh Shilimkar wrote:
>>> If you plan to commit this change then I can move these to
>>> other OMAP4 header file.
>>
>> Can you send me a patch to do that please?
>>
> Here it is.. Generated against latest mainline.
> Also attached just in case for any mailer issues.

Looks good, please send to the patch system.

RFC, GIC based smp_cross_call cleanup suggestion

[Santosh Shilimkar]

On 4/4/2011 1:55 PM, Russell King - ARM Linux wrote:
> On Mon, Apr 04, 2011 at 01:50:35PM +0530, Santosh Shilimkar wrote:
>> On 4/3/2011 7:18 PM, Russell King - ARM Linux wrote:
>>> On Sun, Apr 03, 2011 at 04:23:41PM +0530, Santosh Shilimkar wrote:
>>>> If you plan to commit this change then I can move these to
>>>> other OMAP4 header file.
>>>
>>> Can you send me a patch to do that please?
>>>
>> Here it is.. Generated against latest mainline.
>> Also attached just in case for any mailer issues.
>
> Looks good, please send to the patch system.
patch 6860/1

Regards
Santosh

RFC, GIC based smp_cross_call cleanup suggestion

[John Linn]

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Sunday, April 03, 2011 4:38 AM
> To: grant.likely at secretlab.ca
> Cc: Colin Cross; Paul Mundt; Magnus Damm; John Linn; linux-arm-
> kernel at lists.infradead.org; Santosh Shilimkar
> Subject: Re: RFC, GIC based smp_cross_call cleanup suggestion
> 
> On Sat, Apr 02, 2011 at 10:47:57PM -0600, Grant Likely wrote:
> > On Sat, Apr 2, 2011 at 3:10 AM, Colin Cross <ccross@google.com>
> wrote:
> > > On Sat, Apr 2, 2011 at 1:51 AM, Russell King - ARM Linux
> > > <linux@arm.linux.org.uk> wrote:
> > >> On Fri, Apr 01, 2011 at 04:55:02PM -0600, Grant Likely wrote:
> > >>> On Fri, Apr 1, 2011 at 4:26 PM, John Linn <John.Linn@xilinx.com>
> wrote:
> > >>> > I?m getting ready to submit a patch to add SMP to Xilinx code.
> I notice that
> > >>> > smp_cross_call for all GIC based platforms is duplicated across
> each
> > >>> > platform in smp.h.
> > >>> >
> > >>> >
> > >>> >
> > >>> > I thought I?d try to jump in to help with some cleanup,
> although I realize
> > >>> > it?s minimal, I have to start somewhere.
> > >>> >
> > >>> >
> > >>> >
> > >>> > What about moving the smp_cross_call for GIC based designs into
> gic.h?
> > >>>
> > >>> Go for it. ?It's an obvious cleanup.
> > >>
> > >> That assumes that all SMP implementations will always have a GIC.
> ?It
> > >> looks to me like this is conditional on shmobile, and so I don't
> think
> > >> its that trivial - maybe Paul or Magnus can first indicate why
> this is.
> > >
> > > OMAP4 may also require a custom smp_cross_call implementation if
> CPU
> > > idle is going to be supported in SMP - in CPU off idle modes, a GIC
> > > SGI will not wake the CPU, and a write directly to the CPU's power
> > > management controller or an external interrupt source would be
> > > required.
> >
> > What John proposes appears to be a pretty sane default though.  It
> > would make sense to move it to common code, and require explicit
> > action on the part of the subarch to compile it out for a different
> > behaviour.  Requiring each subarch to define it explicitly doesn't
> > seem optimal.
> 
> Bear in mind that the GIC doesn't do any PM support, so the hardware
> folk are inventing their own IRQ controller to sit along side the GIC
> to provide that missing functionality.  What I expect will happen is
> that the GIC will be obsoleted and replaced by something integrating
> PM support.
> 
> So we could end up in the situation where we need both GIC and
> something
> else in the kernel at the same time - especially if we persue the
> single
> kernel image thing.  Moving smp_cross_call() into gic.h would add an
> additional bar to that happening.
> 
> A better solution may be to make smp_cross_call() be a function pointer
> which must be initialized as part of the platforms SMP initialization.
> That'd get rid of mach/smp.h entirely.
> 
> Oh, and while looking at that, guess what annoyingly stands in the way
> of eliminating mach/smp.h ?  Yes, it's OMAP, because they've bunged
> some
> function prototypes into plat/smp.h.  (I've not cared about that in the
> patch below; I've deleted the entire thing, so it probably breaks
> OMAP.)
> 
>  arch/arm/include/asm/smp.h                |    6 +----
>  arch/arm/kernel/smp.c                     |    7 +++++
>  arch/arm/mach-exynos4/include/mach/smp.h  |   19 ---------------
>  arch/arm/mach-exynos4/platsmp.c           |    5 +++-
>  arch/arm/mach-msm/include/mach/smp.h      |   23 -------------------
>  arch/arm/mach-msm/platsmp.c               |    4 ++-
>  arch/arm/mach-omap2/omap-smp.c            |    5 +++-
>  arch/arm/mach-realview/include/mach/smp.h |   14 -----------
>  arch/arm/mach-realview/platsmp.c          |    3 ++
>  arch/arm/mach-shmobile/include/mach/smp.h |   16 -------------
>  arch/arm/mach-shmobile/platsmp.c          |    3 ++
>  arch/arm/mach-tegra/include/mach/smp.h    |   14 -----------
>  arch/arm/mach-tegra/platsmp.c             |    3 ++
>  arch/arm/mach-ux500/include/mach/smp.h    |   24 --------------------
>  arch/arm/mach-ux500/platsmp.c             |    5 +++-
>  arch/arm/mach-vexpress/ct-ca9x4.c         |    2 +
>  arch/arm/mach-vexpress/include/mach/smp.h |   13 ----------
>  arch/arm/plat-omap/include/plat/smp.h     |   36 ---------------------
> ---------
>  arch/arm/plat-versatile/platsmp.c         |    3 +-
>  19 files changed, 37 insertions(+), 168 deletions(-)
> 

Hi Russell,

I realize my SMP patch set I just sent out doesn't take this into account yet.  

I thought I needed to get it out for review since there's likely to be changes.

I can make this change to my patch set easily if it's the direction you go.

Thanks,
John

This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

RFC, GIC based smp_cross_call cleanup suggestion

[Russell King - ARM Linux]

On Sun, Apr 03, 2011 at 03:15:27PM -0600, John Linn wrote:
> I realize my SMP patch set I just sent out doesn't take this into
> account yet.  
> 
> I thought I needed to get it out for review since there's likely to
> be changes.
> 
> I can make this change to my patch set easily if it's the direction you go.

If we're going to be doing a lot of consolidation in the platform support
code during this merge window, it will mean that it'll be extremely
difficult to carry new platforms along side as they'll need to be
regularly updated.

Committing new platform support in the middle of the consolidation effort
also invites problems with the consolidation patches needing to be updated
before they can be applied.

As I mentioned in the OMAP git pull discussion, I think we should reserve
this cycle for consolidation effort and bug fixes only, otherwise things
will get really sticky.

RFC, GIC based smp_cross_call cleanup suggestion

[Santosh Shilimkar]

+ Thomas G,

On 4/2/2011 2:40 PM, Colin Cross wrote:
> On Sat, Apr 2, 2011 at 1:51 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk>  wrote:
>> On Fri, Apr 01, 2011 at 04:55:02PM -0600, Grant Likely wrote:
>>> On Fri, Apr 1, 2011 at 4:26 PM, John Linn<John.Linn@xilinx.com>  wrote:
>>>> I?m getting ready to submit a patch to add SMP to Xilinx code. I notice that
>>>> smp_cross_call for all GIC based platforms is duplicated across each
>>>> platform in smp.h.
>>>>
>>>>
>>>>
>>>> I thought I?d try to jump in to help with some cleanup, although I realize
>>>> it?s minimal, I have to start somewhere.
>>>>
>>>>
>>>>
>>>> What about moving the smp_cross_call for GIC based designs into gic.h?
>>>
>>> Go for it.  It's an obvious cleanup.
>>
>> That assumes that all SMP implementations will always have a GIC.  It
>> looks to me like this is conditional on shmobile, and so I don't think
>> its that trivial - maybe Paul or Magnus can first indicate why this is.
>
> OMAP4 may also require a custom smp_cross_call implementation if CPU
> idle is going to be supported in SMP - in CPU off idle modes, a GIC
> SGI will not wake the CPU, and a write directly to the CPU's power
> management controller or an external interrupt source would be
> required.

This can be done without making smp_cross_call() platform
specific.
While working on broad-cast notifiers for ARM with Thomas G, this
point was discussed.

Where the TWD can't wakeup its own local CPU from C3 mode, how do we
provide a platform specific method to perform this wakeup ?

Thomas Quoted....
"It would not complicate the OMAP code that much. All it needs is
extending the clock event device callbacks by an broadcast_affinity()
function which would be called from the broadcast code when the
broadcast device is armed. The argument would be a cpumask which would
tell you which core(s) to wake up when the broadcast timer fires next.

So OMAP would fill in that hook and implement the wakeup redirector
setup, which I guess would be a couple of lines."

 From above it's should be trivial once the broad-cast notifiers
are extended to have "broadcast_affinity()" supported

Regards
Santosh

RFC, GIC based smp_cross_call cleanup suggestion

[Colin Cross]

On Sat, Apr 2, 2011 at 11:23 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> + Thomas G,
>
> On 4/2/2011 2:40 PM, Colin Cross wrote:
>>
>> On Sat, Apr 2, 2011 at 1:51 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> ?wrote:
>>>
>>> On Fri, Apr 01, 2011 at 04:55:02PM -0600, Grant Likely wrote:
>>>>
>>>> On Fri, Apr 1, 2011 at 4:26 PM, John Linn<John.Linn@xilinx.com> ?wrote:
>>>>>
>>>>> I?m getting ready to submit a patch to add SMP to Xilinx code. I notice
>>>>> that
>>>>> smp_cross_call for all GIC based platforms is duplicated across each
>>>>> platform in smp.h.
>>>>>
>>>>>
>>>>>
>>>>> I thought I?d try to jump in to help with some cleanup, although I
>>>>> realize
>>>>> it?s minimal, I have to start somewhere.
>>>>>
>>>>>
>>>>>
>>>>> What about moving the smp_cross_call for GIC based designs into gic.h?
>>>>
>>>> Go for it. ?It's an obvious cleanup.
>>>
>>> That assumes that all SMP implementations will always have a GIC. ?It
>>> looks to me like this is conditional on shmobile, and so I don't think
>>> its that trivial - maybe Paul or Magnus can first indicate why this is.
>>
>> OMAP4 may also require a custom smp_cross_call implementation if CPU
>> idle is going to be supported in SMP - in CPU off idle modes, a GIC
>> SGI will not wake the CPU, and a write directly to the CPU's power
>> management controller or an external interrupt source would be
>> required.
>
> This can be done without making smp_cross_call() platform
> specific.
> While working on broad-cast notifiers for ARM with Thomas G, this
> point was discussed.
>
> Where the TWD can't wakeup its own local CPU from C3 mode, how do we
> provide a platform specific method to perform this wakeup ?
>
> Thomas Quoted....
> "It would not complicate the OMAP code that much. All it needs is
> extending the clock event device callbacks by an broadcast_affinity()
> function which would be called from the broadcast code when the
> broadcast device is armed. The argument would be a cpumask which would
> tell you which core(s) to wake up when the broadcast timer fires next.
>
> So OMAP would fill in that hook and implement the wakeup redirector
> setup, which I guess would be a couple of lines."
>
> From above it's should be trivial once the broad-cast notifiers
> are extended to have "broadcast_affinity()" supported

That fixes the localtimer, but not calls to generic_exec_single, which
also calls smp_cross_call.

RFC, GIC based smp_cross_call cleanup suggestion

[Magnus Damm]

On Sat, Apr 2, 2011 at 5:51 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 01, 2011 at 04:55:02PM -0600, Grant Likely wrote:
>> On Fri, Apr 1, 2011 at 4:26 PM, John Linn <John.Linn@xilinx.com> wrote:
>> > I?m getting ready to submit a patch to add SMP to Xilinx code. I notice that
>> > smp_cross_call for all GIC based platforms is duplicated across each
>> > platform in smp.h.
>> >
>> >
>> >
>> > I thought I?d try to jump in to help with some cleanup, although I realize
>> > it?s minimal, I have to start somewhere.
>> >
>> >
>> >
>> > What about moving the smp_cross_call for GIC based designs into gic.h?
>>
>> Go for it. ?It's an obvious cleanup.
>
> That assumes that all SMP implementations will always have a GIC. ?It
> looks to me like this is conditional on shmobile, and so I don't think
> its that trivial - maybe Paul or Magnus can first indicate why this is.

Our SMP implementations all come with GIC. All shmobile SoCs don't
come with SMP though, so the conditional is most likely related to
that.

Thanks,

/ magnus

RFC, GIC based smp_cross_call cleanup suggestion

[Russell King - ARM Linux]

On Sun, Apr 03, 2011 at 12:37:11PM +0900, Magnus Damm wrote:
> On Sat, Apr 2, 2011 at 5:51 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Apr 01, 2011 at 04:55:02PM -0600, Grant Likely wrote:
> >> On Fri, Apr 1, 2011 at 4:26 PM, John Linn <John.Linn@xilinx.com> wrote:
> >> > I?m getting ready to submit a patch to add SMP to Xilinx code. I notice that
> >> > smp_cross_call for all GIC based platforms is duplicated across each
> >> > platform in smp.h.
> >> >
> >> >
> >> >
> >> > I thought I?d try to jump in to help with some cleanup, although I realize
> >> > it?s minimal, I have to start somewhere.
> >> >
> >> >
> >> >
> >> > What about moving the smp_cross_call for GIC based designs into gic.h?
> >>
> >> Go for it. ?It's an obvious cleanup.
> >
> > That assumes that all SMP implementations will always have a GIC. ?It
> > looks to me like this is conditional on shmobile, and so I don't think
> > its that trivial - maybe Paul or Magnus can first indicate why this is.
> 
> Our SMP implementations all come with GIC. All shmobile SoCs don't
> come with SMP though, so the conditional is most likely related to
> that.

On platforms without SMP, mach/smp.h shouldn't be included, so the code
in mach/smp.h won't be seen by the compiler.  So, I think you can get
rid of that conditional.

RFC, GIC based smp_cross_call cleanup suggestion

[Russell King - ARM Linux]

On Fri, Apr 01, 2011 at 04:55:02PM -0600, Grant Likely wrote:
> On Fri, Apr 1, 2011 at 4:26 PM, John Linn <John.Linn@xilinx.com> wrote:
> > I?m getting ready to submit a patch to add SMP to Xilinx code. I notice that
> > smp_cross_call for all GIC based platforms is duplicated across each
> > platform in smp.h.
> >
> >
> >
> > I thought I?d try to jump in to help with some cleanup, although I realize
> > it?s minimal, I have to start somewhere.
> >
> >
> >
> > What about moving the smp_cross_call for GIC based designs into gic.h?
> 
> Go for it.  It's an obvious cleanup.

BTW, where's John's original email?  It hasn't come through the mailing
list from what I can see.