[RFC PATCH v2 2/3] ARM: SoC: Add per SoC SMP and CPU hotplug operations

Hi Santosh,

On 09/09/11 15:55, Santosh wrote:

Marc,

On Friday 09 September 2011 08:16 PM, Marc Zyngier wrote:

quoted

Populate the SoC descriptor structure with the SMP and CPU hotplug
operations. To allow the kernel to continue building, the platform
hooks are defined as weak symbols which are overrided by the
platform code. Once all platforms are converted, the "weak" attribute
will be removed and the function made static.

Cc: Arnd Bergmann<arnd@arndb.de>
Cc: Nicolas Pitre<nico@fluxnic.net>
Signed-off-by: Marc Zyngier<redacted>
---
  arch/arm/include/asm/soc.h |   18 ++++++++++++++++
  arch/arm/kernel/setup.c    |   11 ++++++++++
  arch/arm/kernel/smp.c      |   47 ++++++++++++++++++++++++++++++++++++++++++++
  3 files changed, 76 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/soc.h b/arch/arm/include/asm/soc.h
index ce92784..2593f90 100644
--- a/arch/arm/include/asm/soc.h
+++ b/arch/arm/include/asm/soc.h

@@ -12,10 +12,28 @@
  #ifndef __ASM_ARM_SOC_H
  #define __ASM_ARM_SOC_H

+struct task_struct;
+
+struct arm_soc_smp_ops {
+	void (*smp_init_cpus)(void);
+	void (*smp_prepare_cpus)(unsigned int max_cpus);
+	void (*smp_secondary_init)(unsigned int cpu);
+	int  (*smp_boot_secondary)(unsigned int cpu, struct task_struct *idle);
+#ifdef CONFIG_HOTPLUG_CPU
+	int  (*cpu_kill)(unsigned int cpu);
+	void (*cpu_die)(unsigned int cpu);
+	int  (*cpu_disable)(unsigned int cpu);
+#endif
+};

Sorry for such a basic question but I don't understand the need
of these wrappers.
I am not upto speed on this topic but what is the motivation
behind the soc_smp_ops(). All of above functions are CPU specific
and not really soc specific though, I agree that every SOC,
implements it's own version.

My understanding is that they really are SoC specific. If you compare
OMAP4, Tegra and VExpress (for example), you'll notice that these
functions are quite different, despite using the same A9 CPU.

For example, you boot a secondary CPU on OMAP4 by trapping into secure
mode, on Tegra by powering it on, and on VE by writing the expected
value to some location.

Indirecting these functions makes it possible to compile support for
multiple SMP platforms into the same image. Probably it is possible to
reduce the differences to something smaller than the above, but I'd
rather change one thing at a time.

Let's add the indirection first (which essentially preserves the
existing internal API), and only then let's see if we can spot common
patterns across the whole range of SMP implementations.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...