aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm/vfp/vfpdouble.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2014-04-14ARM: 8026/1: Fix emulation of multiply accumulate instructionsJay Foad1-0/+2
The emulation for single and double precision multiply accumulate instructions correctly normalised any denormal values in the operand registers, but failed to normalise the destination (accumulator) register. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=70501 Signed-off-by: Jay Foad <jay.foad@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-10[ARM] vfp: fix fuitod/fsitod instructionsRussell King1-3/+11
These two instructions exceptionally take a single precision register as their operand. This means we can't use vfp_get_dm() to read the register number - we need to use vfp_get_sm() instead. Add a flag to indicate this exception to the general rule. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-10-20[ARM] 4630/1: Fix the vector stride of the double vector instruction.Takashi Ohmasa1-4/+4
The vector stride of the double-precision vector instructions must be changed to 1-2 from even 2-4, because the double registers numbering has been changed to 0-15 from even 0-30 by 1356c1948da967bc1d4c663762bfe21dfcec4b2f commit. Signed-off-by: Takashi Ohmasa <ohmasa.takashi@jp.panasonic.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-04-22[ARM] Remove unnecessary asm/ptrace.h from VFP support codeRussell King1-1/+0
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-10-28[ARM] 3899/1: Fix the normalization of the denormal double precision number.Takashi Ohmasa1-1/+1
The significand should be shifted until the value of bit [62] is 1 to normalize the denormal double number. Signed-off-by: Takashi Ohmasa <ohmasa.takashi@jp.panasonic.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-09-25[ARM] Cleanups for 4cc9bd2eaa1063c68341c1c00e66660adcfdf254Russell King1-41/+32
- Document the meaning for OP_SCALAR, OP_SD and add OP_DD. - Formatting cleanups - Remove now redundant code for making compare instructions operate on scalar values. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-09-25[ARM] 3789/4: Fix VFP emulation to ignore VECITR for scalar instructionGen FUKATSU1-36/+36
VECITR in Floating-Point Exception register indicates the number of remaining short vector iterations after a potential exception was detected. In case of exception caused by scalar instructions, VECITR is NOT updated. Therefore emulation for VFP must ignore VECITR field and treat "veclen" as zero when recognizing scalar instructing. Signed-off-by: Gen Fukatsu <fukatsu.gen@jp.panasonic.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-08-30[ARM] 3750/3: Fix double VFP emulation for EABI kernelsDaniel Jacobowitz1-10/+10
Patch from Daniel Jacobowitz vfp_put_double didn't work in a CONFIG_AEABI kernel. By swapping the arguments, we arrange for them to be in the same place regardless of ABI. I made the same change to vfp_put_float for consistency. Signed-off-by: Daniel Jacobowitz <dan@codesourcery.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-08-27[ARM] 3758/1: Preserve signalling NaNs in conversionDaniel Jacobowitz1-1/+1
Patch from Daniel Jacobowitz The fcvtds and fcvtsd instructions were generating a qnan bit pattern for both quiet and signalling NaNs. Signed-off-by: Daniel Jacobowitz <dan@codesourcery.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-08-27[ARM] 3749/3: Correct VFP single/double conversion emulationDaniel Jacobowitz1-7/+21
Patch from Daniel Jacobowitz The fcvtsd/fcvtds emulation was left behind when the numbering of double precision registers was changed from 0-30 to 0-15. Both conversion instructions were writing their results to the wrong register. Also, the conversion instructions should stop after the first element even if a vector length is specified. Signed-off-by: Daniel Jacobowitz <dan@codesourcery.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
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!