aboutsummaryrefslogtreecommitdiffstats
path: root/arch/sparc/math-emu (follow)
AgeCommit message (Collapse)AuthorFilesLines
2012-05-25sparc64: Fix several bugs in quad floating point emulation.David S. Miller1-6/+14
UltraSPARC-T2 and later do not use the fp_exception_other trap and do not set the floating point trap type field in the %fsr at all when you try to execute an unimplemented FPU operation. Instead, it uses the illegal_instruction trap and it leaves the floating point trap type field clear. So we should not validate the %fsr trap type field when do_mathemu() is invoked from the illegal instruction handler. Also, the floating point trap type field is 3 bits, not 4 bits. Signed-off-by: David S. Miller <davem@davemloft.net>
2012-03-28Disintegrate asm/system.h for SparcDavid Howells1-0/+1
Disintegrate asm/system.h for Sparc. Signed-off-by: David Howells <dhowells@redhat.com> cc: sparclinux@vger.kernel.org
2011-07-01perf: Remove the nmi parameter from the swevent and overflow interfacePeter Zijlstra2-2/+2
The nmi parameter indicated if we could do wakeups from the current context, if not, we would set some state and self-IPI and let the resulting interrupt do the wakeup. For the various event classes: - hardware: nmi=0; PMI is in fact an NMI or we run irq_work_run from the PMI-tail (ARM etc.) - tracepoint: nmi=0; since tracepoint could be from NMI context. - software: nmi=[0,1]; some, like the schedule thing cannot perform wakeups, and hence need 0. As one can see, there is very little nmi=1 usage, and the down-side of not using it is that on some platforms some software events can have a jiffy delay in wakeup (when arch_irq_work_raise isn't implemented). The up-side however is that we can remove the nmi parameter and save a bunch of conditionals in fast paths. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Michael Cree <mcree@orcon.net.nz> Cc: Will Deacon <will.deacon@arm.com> Cc: Deng-Cheng Zhu <dengcheng.zhu@gmail.com> Cc: Anton Blanchard <anton@samba.org> Cc: Eric B Munson <emunson@mgebm.net> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Paul Mundt <lethal@linux-sh.org> Cc: David S. Miller <davem@davemloft.net> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Don Zickus <dzickus@redhat.com> Link: http://lkml.kernel.org/n/tip-agjev8eu666tvknpb3iaj0fg@git.kernel.org Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-03-31Fix common misspellingsLucas De Marchi1-1/+1
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2010-05-26Revert "endian: #define __BYTE_ORDER"Linus Torvalds2-0/+12
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 Tjernlund2-12/+0
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-12-11sparc: Add alignment and emulation fault perf events.David S. Miller2-0/+5
This mirrors commit 196f02bf900c5eb6f85d889c4f70e7cc11fda7e8 (powerpc: perf_event: Add alignment-faults and emulation-faults software events) Signed-off-by: David S. Miller <davem@davemloft.net>
2008-12-04sparc64: unify math-emuSam Ravnborg2-0/+633
Move relavent files to sparc/math-emu and adjust path/include accordingly. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2008-12-04sparc: prepare math-emu for unificationSam Ravnborg3-2/+2
Add _32 to filenames to make them 32 bit unique Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2008-12-04sparc: cleanup math-emuSam Ravnborg2-39/+3
- Drop unused assignment from Makefile - Replace EXTRA_CFLAGS with ccflags-y - Delete unused file Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2008-05-20sparc: remove CVS keywordsAdrian Bunk1-1/+1
This patch removes the CVS keywords that weren't updated for a long time from comments. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-04-04kbuild: use relative path to -ISam Ravnborg1-1/+1
Using a relative path has the advantage that when the kernel source tree is moved the relevant .o files will not be rebuild just because the path to the kernel src has changed. This also got rid of a user of TOPDIR - which has been deprecated for a long time now. Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2006-01-30[SPARC]: Fix compile failures in math-emu.David S. Miller1-10/+0
Kill debugging default switch cases in do_one_mathemu(). That case is handled properly already and gcc hates the empty statement that results when the debug code is disabled. Pointed out by kaffe. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-04-16Linux-2.6.12-rc2Linus Torvalds4-0/+680
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!