When we install the handlers for context switching, we must enable
VFP on all CPU cores, otherwise undefined (and random) effects
occur.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Don't set HWCAP_VFP in the processor support file; not only does it
depend on the processor features, but it also depends on the support
code being present.  Therefore, only set it if the support code
detects that we have a VFP coprocessor attached.

Also, move the VFP handling of the coprocessor access register into
the VFP support code.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The SIGFPE signal should be generated if Division by Zero exception is detected.
Signed-off-by: NTakashi Ohmasa <ohmasa.takashi@jp.panasonic.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The significand should be shifted until the value of bit [62] is 1
to normalize the denormal double number.
Signed-off-by: NTakashi Ohmasa <ohmasa.takashi@jp.panasonic.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NFrederik Deweerdt <frederik.deweerdt@gmail.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Zach Brown <zach.brown@oracle.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus 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: NRussell 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: NGen Fukatsu <fukatsu.gen@jp.panasonic.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Daniel Jacobowitz

The ARM kernel has several uses of asm("foo%?").  %? is a GCC internal
modifier used to output conditional execution predicates.  However, no
version of GCC supports conditionalizing asm statements.  GCC 4.2 will
correctly expand %? to the empty string in user asms.  Earlier versions may
reuse the condition from the previous instruction.  In 'if (foo) asm
("bar%?");' this is somewhat likely to be right... but not reliable.

So, the only safe thing to do is to remove the uses of %?.  I believe
the tlbflush.h occurances were supposed to be removed before, based
on the comment about %? not working at the top of that file.

Old versions of GCC could omit branches around user asms if the asm didn't
mark the condition codes as clobbered.  This problem hasn't been seen on any
recent (3.x or 4.x) GCC, but it could theoretically happen.  So, where
%? was removed a cc clobber was added.
Signed-off-by: NDaniel Jacobowitz <dan@codesourcery.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The common case for the thread notifier is a context switch.  Tell
gcc that this is the most likely condition so it can optimise the
function for this case.
Signed-off-by: NRussell 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: NDaniel Jacobowitz <dan@codesourcery.com>
Signed-off-by: NRussell 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: NDaniel Jacobowitz <dan@codesourcery.com>
Signed-off-by: NRussell 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: NDaniel Jacobowitz <dan@codesourcery.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Daniel Jacobowitz

The recent fix to hide VFP_NAN_FLAG broke the check in vfp_raise_exceptions;
it would attempt to deliver an exception mask of 0xfffffeff instead of reporting
a serious error condition using printk.  Define a safe constant to use for
an invalid exception maskm, and use it at both ends.
Signed-off-by: NDaniel Jacobowitz <dan@codesourcery.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

Since we pass flags to the compiler to control code generation based
on the least capable selected CPU, if we want to include VFP support,
we must tweak the assembler flags to allow the VFP instructions.
Moreover, we must not use the mrrc/mcrr versions since these will not
be recognised by the assembler.

We do not convert all instructions to the VFP-equivalent (yet) since
binutils appears to barf on "fmrx rn, fpinst" and doesn't provide any
other way (other than using the mrc equivalent) to encode this
instruction - which is rather a problem when you have a VFP
implementation which requires these instructions.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Some machine classes need to allow VFP support to be built into the
kernel, but still allow the kernel to run even though VFP isn't
present.  Unfortunately, the kernel hard-codes VFP instructions
into the thread switch, which prevents this being run-time selectable.

Solve this by introducing a notifier which things such as VFP can
hook into to be informed of events which affect the VFP subsystem
(eg, creation and destruction of threads, switches between threads.)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from George G. Davis

The ARM VFP FPSCR register is corrupted when a condition flags modifying
VFP instruction is followed by a non-condition flags modifying VFP
instruction and both instructions raise exceptions.  The fix is to
read the current FPSCR in between emulation of these two instructions
and use the current FPSCR value when handling the second exception.
Signed-off-by: NGeorge G. Davis <gdavis@mvista.com>
Signed-off-by: NRussell 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: NRussell 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: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell 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: NKen'ichi Kuromusha <musha@aplix.co.jp>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Catalin Marinas

The current VFP code corrupts the VFP registers (including the control
ones) if more than one floating point application is executed at the same
time. This patch fixes the updating of the load/store base addresses for
the VFP registers.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

5d25ac03 broke VFP builds due to
enable_irq not being defined as an assembly macro.  Move it to
assembler.h so everyone can use it.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Allow the individual coprocessor handlers to decide when to enable
interrupts, rather than unconditionally enabling them.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Delete obsoleted stuff from arch Makefile and rename
constants.h to asm-offsets.h
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

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: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We were forcing SIGFPE on to a user program for no good reason.
Use send_sig_info() instead.
Signed-off-by: NRussell 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: NRussell 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!