summaryrefslogtreecommitdiffstats
path: root/arch/powerpc/include/asm/sfp-machine.h
AgeCommit message (Collapse)Author
2010-05-26Revert "endian: #define __BYTE_ORDER"Linus Torvalds
This reverts commit b3b77c8caef1750ebeea1054e39e358550ea9f55, which was also totally broken (see commit 0d2daf5cc858 that reverted the crc32 version of it). As reported by Stephen Rothwell, it causes problems on big-endian machines: > In file included from fs/jfs/jfs_types.h:33, > from fs/jfs/jfs_incore.h:26, > from fs/jfs/file.c:22: > fs/jfs/endian24.h:36:101: warning: "__LITTLE_ENDIAN" is not defined The kernel has never had that crazy "__BYTE_ORDER == __LITTLE_ENDIAN" model. It's not how we do things, and it isn't how we _should_ do things. So don't go there. Requested-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-05-25endian: #define __BYTE_ORDERJoakim Tjernlund
Linux does not define __BYTE_ORDER in its endian header files which makes some header files bend backwards to get at the current endian. Lets #define __BYTE_ORDER in big_endian.h/litte_endian.h to make it easier for header files that are used in user space too. In userspace the convention is that 1. _both_ __LITTLE_ENDIAN and __BIG_ENDIAN are defined, 2. you have to test for e.g. __BYTE_ORDER == __BIG_ENDIAN. Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-04-02powerpc/math-emu: Change types to work on ppc64Kumar Gala
While normally we don't use the math emulation code on ppc64 it can be useful for doing things like emulating the embedded FP instructions. Since performance isn't critical in this scenario its easier to keep the sizes of the various math-emu the same as on ppc32. Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2008-12-03powerpc: Add SPE/EFP math emulation for E500v1/v2 processors.Liu Yu
This patch add the handlers of SPE/EFP exceptions. The code is used to emulate float point arithmetic, when MSR(SPE) is enabled and receive EFP data interrupt or EFP round interrupt. This patch has no conflict with or dependence on FP math-emu. The code has been tested by TestFloat. Now the code doesn't support SPE/EFP instructions emulation (it won't be called when receive program interrupt), but it could be easily added. Signed-off-by: Liu Yu <yu.liu@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2008-12-03powerpc/math-emu: Adopt new version of _FP_CHOOSENANLiu Yu
Move to using the same macro definition for _FP_CHOOSENAN as s390, sh, sparc32/64. The original author didn't understand this and matched what sparc64 was doing and they have updated to this definition. Signed-off-by: Liu Yu <yu.liu@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2008-12-03powerpc/math-emu: Fix single float point division bugLiu Yu
PowerPC float point division emulation is derived from gcc. I reported this problem on gcc maillist and got this reply: http://gcc.gnu.org/ml/gcc/2008-03/msg00543.html Since UDIV_NEEDS_NORMALIZATION is not used by kernel, we should use _FP_DIV_MEAT_1_udiv_norm to make sure the single float point is normalized before udiv_qrnnd. Signed-off-by: Liu Yu <yu.liu@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2008-10-01powerpc/math-emu: Use kernel generic math-emu codeKumar Gala
The math emulation code is centered around a set of generic macros that provide the core of the emulation that are shared by the various architectures and other projects (like glibc). Each arch implements its own sfp-machine.h to specific various arch specific details. For historic reasons that are now lost the powerpc math-emu code had its own version of the common headers. This moves us to using the kernel generic version and thus getting fixes when those are updated. Also cleaned up exception/error reporting from the FP emulation functions. Signed-off-by: Kumar Gala <galak@kernel.crashing.org>