summaryrefslogtreecommitdiffstats
path: root/include/asm-ppc64/smp.h
Commit message (Collapse)AuthorAgeFilesLines
* powerpc: Merge smp.c and smp.hPaul Mackerras2005-11-051-92/+0
| | | | | | | This also moves setup_cpu_maps to setup-common.c (calling it smp_setup_cpu_maps) and uses it on both 32-bit and 64-bit. Signed-off-by: Paul Mackerras <paulus@samba.org>
* powerpc: Implement smp_release_cpus() in C not asmMichael Ellerman2005-11-041-0/+1
| | | | | | | | | | There's no reason for smp_release_cpus() to be asm, and most people can make more sense of C code. Add an extern declaration to smp.h and remove the custom one in machine_kexec.c Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
* powerpc: Cleanup vpa codeMichael Ellerman2005-11-031-8/+0
| | | | | | | | | | | | | register_vpa() doesn't actually do a VPA register call it just uses the flags you pass it, so rename it to vpa_call() to be clearer. We can then define register_vpa() and unregister_vpa() which are both simple wrappers around vpa_call(). (we'll need unregister_vpa() for kexec soon) We can then cleanup vpa_init(), and because vpa_init() is only called from platforms/pseries we remove the definition in asm-ppc64/smp.h. Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
* [PATCH] powerpc: create a new arch/powerpc/platforms/cell/smp.cArnd Bergmann2005-11-011-0/+1
| | | | | | | | | | During the conversion to the merge tree, the Cell specific SMP initialization was removed from the pSeries code. This creates a new Cell specific SMP implementation file. Signed-off-by: Arnd Bergmann <arndb@de.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
* powerpc: Move smp_mpic_message_pass into mpic.cPaul Mackerras2005-10-201-1/+0
| | | | | | | Having it here rather than in arch/ppc64/kernel/smp.c means that we can use it on 32-bit SMP systems easily with ARCH=powerpc. Signed-off-by: Paul Mackerras <paulus@samba.org>
* [PATCH] ppc64: add BPA platform typeArnd Bergmann2005-06-231-0/+8
| | | | | | | | | | | | | This adds the basic support for running on BPA machines. So far, this is only the IBM workstation, and it will not run on others without a little more generalization. It should be possible to configure a kernel for any combination of CONFIG_PPC_BPA with any of the other multiplatform targets. Signed-off-by: Arnd Bergmann <arndb@de.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [PATCH] smp_processor_id() cleanupIngo Molnar2005-06-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements a number of smp_processor_id() cleanup ideas that Arjan van de Ven and I came up with. The previous __smp_processor_id/_smp_processor_id/smp_processor_id API spaghetti was hard to follow both on the implementational and on the usage side. Some of the complexity arose from picking wrong names, some of the complexity comes from the fact that not all architectures defined __smp_processor_id. In the new code, there are two externally visible symbols: - smp_processor_id(): debug variant. - raw_smp_processor_id(): nondebug variant. Replaces all existing uses of _smp_processor_id() and __smp_processor_id(). Defined by every SMP architecture in include/asm-*/smp.h. There is one new internal symbol, dependent on DEBUG_PREEMPT: - debug_smp_processor_id(): internal debug variant, mapped to smp_processor_id(). Also, i moved debug_smp_processor_id() from lib/kernel_lock.c into a new lib/smp_processor_id.c file. All related comments got updated and/or clarified. I have build/boot tested the following 8 .config combinations on x86: {SMP,UP} x {PREEMPT,!PREEMPT} x {DEBUG_PREEMPT,!DEBUG_PREEMPT} I have also build/boot tested x64 on UP/PREEMPT/DEBUG_PREEMPT. (Other architectures are untested, but should work just fine.) Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-161-0/+91
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!