aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm/vfp/vfpdouble.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2006-04-25[ARM] vfp: fix leak of VFP_NAN_FLAG into FPSCRRussell King1-1/+1
The VFP code can leak VFP_NAN_FLAG into the FPSCR. It doesn't correspond to any real FPSCR bit (and overlaps one of the exception flags). Bug report from Daniel Jacobowitz Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-04-10[ARM] 3473/1: Use numbers 0-15 for the VFP double registersCatalin Marinas1-12/+8
Patch from Catalin Marinas This patch changes the double registers numbering to 0-15 from even 0-30, in preparation for future VFP extensions. It also fixes the VFP_REG_ZERO bug (value 16 actually represents the 8th double register with the original numbering). The original mcrr/mrrc on CP10 were generating FMRRS/FMSRR instead of FMRRD/FMDRR. The patch changes to CP11 for the correct instructions. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-04-10[ARM] 3471/1: FTOSI functions should return 0 for NaNCatalin Marinas1-2/+7
Patch from Catalin Marinas The NaN case was dealed with by the "exponent >= ... + 32" condition but it was not setting the value "d" to 0. Signed-off-by: Ken'ichi Kuromusha <musha@aplix.co.jp> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-08-03[PATCH] ARM: 2841/1: Fix VFP +/-0 case for doubles additionCatalin Marinas1-0/+3
Patch from Catalin Marinas The IEEE 754 standard specifies that the result of (x - x), where x is a valid number, should be -0 if the rounding mode is towards minus infinity or +0 otherwise. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-29[PATCH] ARM: Fix VFP to use do_div()Russell King1-0/+2
VFP used __divdi3 64-bit division needlessly. Convert it to use our 64-bit by 32-bit division instead. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-04-16Linux-2.6.12-rc2Linus Torvalds1-0/+1186
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!