26 Jan, 2008

2 commits

  • This patch adds the support for VFPv3 (the kernel currently supports
    VFPv2). The main difference is 32 double registers (compared to 16).

    Signed-off-by: Catalin Marinas
    Signed-off-by: Russell King

    Catalin Marinas
     
  • This patch allows the VFP support code to run correctly on CPUs
    compatible with the common VFP subarchitecture specification (Appendix
    B in the ARM ARM v7-A and v7-R edition). It implements support for VFP
    subarchitecture 2 while being backwards compatible with
    subarchitecture 1.

    On VFP subarchitecture 1, the arithmetic exceptions are asynchronous
    (or imprecise as described in the old ARM ARM) unless the FPSCR.IXE
    bit is 1. The exceptional instructions can be read from FPINST and
    FPINST2 registers. With VFP subarchitecture 2, the arithmetic
    exceptions can also be synchronous and marked by the FPEXC.DEX bit
    (the FPEXC.EX bit is cleared). CPUs implementing the synchronous
    arithmetic exceptions don't have the FPINST and FPINST2 registers and
    accessing them would trigger and undefined exception.

    Note that FPEXC.EX bit has an additional meaning on subarchitecture 1
    - if it isn't set, there is no additional information in FPINST and
    FPINST2 that needs to be saved at context switch or when lazy-loading
    the VFP state of a different thread.

    The patch also removes the clearing of the cumulative exception flags in
    FPSCR when additional exceptions were raised. It is up to the user
    application to clear these bits.

    Signed-off-by: Catalin Marinas
    Signed-off-by: Russell King

    Catalin Marinas
     

11 Jan, 2008

1 commit

  • 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

    Russell King
     

21 Oct, 2007

2 commits


16 Oct, 2007

1 commit

  • The variable AFLAGS is a wellknown variable and the usage by
    kbuild may result in unexpected behaviour.
    On top of that several people over time has asked for a way to
    pass in additional flags to gcc.

    This patch replace use of AFLAGS with KBUILD_AFLAGS all over
    the tree.

    Patch was tested on following architectures:
    alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k, s390

    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     

13 Sep, 2007

1 commit

  • vfp_init() takes care of the condition when CONFIG_VFP=y but no real VFP
    device exists. However, when this condition is true, a compiler might
    misplace code lines in a way that will break this support. (To be more
    specific - fmrx(FPSID) might be executed before vfp_testing_entry
    assignment, which will end up with Oops - undefined instruction).
    This patch adds a barrier() to guarantee the right execution ordering.

    Signed-off-by: Assaf Hoffman
    Signed-off-by: Russell King

    Tzachi Perelstein
     

20 Jul, 2007

1 commit


10 Jun, 2007

1 commit

  • Fix a real section mismatch issue; the test code is thrown away after
    initialisation, but if we do not detect the VFP hardware, it is left
    hooked into the exception handler. Any VFP instructions which are
    subsequently executed risk calling the discarded exception handler.

    Introduce a new "null" handler which returns to the "unrecognised
    fault" return address.

    Signed-off-by: Russell King

    Russell King
     

22 Apr, 2007

1 commit


26 Jan, 2007

1 commit


03 Jan, 2007

1 commit


09 Dec, 2006

1 commit

  • 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: Russell King

    Russell King
     

28 Oct, 2006

2 commits


12 Oct, 2006

1 commit


03 Oct, 2006

1 commit

  • 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
    Cc: Russell King
    Cc: Zach Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Frederik Deweerdt
     

25 Sep, 2006

2 commits


20 Sep, 2006

2 commits

  • 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: Daniel Jacobowitz
    Signed-off-by: Russell King

    Daniel Jacobowitz
     
  • 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: Russell King

    Russell King
     

30 Aug, 2006

1 commit


27 Aug, 2006

3 commits


01 Jul, 2006

1 commit


22 Jun, 2006

2 commits

  • 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: Russell King

    Russell King
     
  • 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: Russell King

    Russell King
     

06 May, 2006

1 commit

  • 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: George G. Davis
    Signed-off-by: Russell King

    George G. Davis
     

26 Apr, 2006

1 commit


11 Apr, 2006

2 commits

  • 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
    Signed-off-by: Russell King

    Catalin Marinas
     
  • 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
    Signed-off-by: Russell King

    Catalin Marinas
     

26 Mar, 2006

1 commit


24 Mar, 2006

1 commit


22 Mar, 2006

1 commit


10 Sep, 2005

1 commit


04 Aug, 2005

1 commit


30 Jun, 2005

2 commits


17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds