| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
It looks like Zach Brown's patch pr_debug-check-pr_debug-arguments
worked as inteded. That is, it doesn't "allow completely incorrect code
to build." :).
The arm build fails with the following message:
CC arch/arm/vfp/vfpsingle.o
arch/arm/vfp/vfpsingle.c: In function `__vfp_single_normaliseround':
arch/arm/vfp/vfpsingle.c:201: error: `func' undeclared (first use in
this function)
arch/arm/vfp/vfpsingle.c:201: error: (Each undeclared identifier is
reported only once
arch/arm/vfp/vfpsingle.c:201: error: for each function it appears in.)
make[1]: *** [arch/arm/vfp/vfpsingle.o] Error 1
make: *** [arch/arm/vfp] Error 2
The following patch fixes the issue by using func only when DEBUG is
defined.
Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Zach Brown <zach.brown@oracle.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
- 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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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!
|
