aboutsummaryrefslogtreecommitdiff
path: root/arch/ppc/kernel/process.c
AgeCommit message (Collapse)Author
2006-01-12powerpc: make ARCH=ppc use arch/powerpc/kernel/process.cPaul Mackerras
Commit 5388fb1025443ec223ba556b10efc4c5f83f8682 made signal_32.c use discard_lazy_cpu_state, which broke ARCH=ppc because that uses the common signal_32.c but has its own process.c. Make ARCH=ppc use the common process.c to fix this and to reduce the amount of duplicated code. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29[PATCH] ppc: fix floating point register corruptionPaolo Galtieri
I recently discovered a bug on PPC which causes the floating point registers to get corrupted when CONFIG_PREEMPT=y. The problem occurred while running a multi threaded Java application that does floating point. The problem could be reproduced in anywhere from 2 to 6 hours. With the patch I have included below it ran for over a week without failure. Signed-off-by: Paolo Galtieri <pgaltieri@mvista.com> Cc: Kumar Gala <galak@gate.crashing.org> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Tom Rini <trini@kernel.crashing.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] ppc32: #ifdef out ALTIVEC specific code in __switch_toMarcelo Tosatti
#ifdef out an ALTIVEC specific tweak in __switch_to() Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-10-27[PATCH] powerpc: Fix handling of fpscr on 64-bitDavid Gibson
The recent merge of fpu.S broken the handling of fpscr for ARCH=powerpc and CONFIG_PPC64=y. FP registers could be corrupted, leading to strange random application crashes. The confusion arises, because the thread_struct has (and requires) a 64-bit area to save the fpscr, because we use load/store double instructions to get it in to/out of the FPU. However, only the low 32-bits are actually used, so we want to treat it as a 32-bit quantity when manipulating its bits to avoid extra load/stores on 32-bit. This patch replaces the current definition with a structure of two 32-bit quantities (pad and val), to clarify things as much as is possible. The 'val' field is used when manipulating bits, the structure itself is used when obtaining the address for loading/unloading the value from the FPU. While we're at it, consolidate the 4 (!) almost identical versions of cvt_fd() and cvt_df() (arch/ppc/kernel/misc.S, arch/ppc64/kernel/misc.S, arch/powerpc/kernel/misc_32.S, arch/powerpc/kernel/misc_64.S) into a single version in fpu.S. The new version takes a pointer to thread_struct and applies the correct offset itself, rather than a pointer to the fpscr field itself, again to avoid confusion as to which is the correct field to use. Finally, this patch makes ARCH=ppc64 also use the consolidated fpu.S code, which it previously did not. Built for G5 (ARCH=ppc64 and ARCH=powerpc), 32-bit powermac (ARCH=ppc and ARCH=powerpc) and Walnut (ARCH=ppc, CONFIG_MATH_EMULATION=y). Booted on G5 (ARCH=powerpc) and things which previously fell over no longer do. Signed-off-by: David Gibson <dwg@au1.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-10-17ppc: Fix various compile errors resulting from ptrace.c mergePaul Mackerras
This introduces flush_{fp,altivec,spe}_to_thread and fixes a branch-too-far error in linking. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-10-11ppc: Various minor compile fixesPaul Mackerras
This fixes up a variety of minor problems in compiling with ARCH=ppc arising from using the merged versions of various header files. A lot of the changes are just adding #include <asm/machdep.h> to files that use ppc_md or smp_ops_t. This also arranges for us to use semaphore.c, vecemu.c, vector.S and fpu.S from arch/powerpc/kernel when compiling with ARCH=ppc. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
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!