1. 13 1月, 2015 1 次提交
    • R
      MIPS: Do not fiddle with FRE unless FRE is actually available. · b0c34f61
      Ralf Baechle 提交于
      Commit 4227a2d4 (MIPS: Support for hybrid
      FPRs) changes the kernel to execute read_c0_config5() even on processors
      that don't have a Config5 register.  According to the arch spec the
      behaviour of trying to read or write this register is UNDEFINED where this
      register doesn't exist, that is merely looking at this register is
      already cruel because that might kill a kitten.
      
      In case of Qemu older than v2.2 Qemu has elected to implement this
      UNDEFINED behaviour by taking a RI exception - which then fries the
      kernel:
      
      [...]
      Freeing YAMON memory: 956k freed
      Freeing unused kernel memory: 240K (80674000 - 806b0000)
      Reserved instruction in kernel code[#1]:
      CPU: 0 PID: 1 Comm: init Not tainted 3.18.0-rc6-00058-g4227a2d4 #26
      task: 86047588 ti: 86048000 task.ti: 86048000
      $ 0   : 00000000 77a638cc 00000000 00000000
      [...]
      
      For qemu v2.2.0 commit f31b035a9f10dc9b57f01c426110af845d453ce2
      (target-mips: correctly handle access to unimplemented CP0 register)
      changed the behaviour to returning zero on read and ignoring writes
      which more matches how typical hardware implementations actually behave.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      b0c34f61
  2. 24 11月, 2014 1 次提交
    • P
      MIPS: Support for hybrid FPRs · 4227a2d4
      Paul Burton 提交于
      Hybrid FPRs is a scheme where scalar FP registers are 64b wide, but
      accesses to odd indexed single registers use bits 63:32 of the
      preceeding even indexed 64b register. In this mode all FP code
      except that built for the plain FP64 ABI can execute correctly. Most
      notably a combination of FP64A & FP32 code can execute correctly,
      allowing for existing FP32 binaries to be linked with new FP64A binaries
      that can make use of 64 bit FP & MSA.
      
      Hybrid FPRs are implemented by setting both the FR & FRE bits, trapping
      & emulating single precision FP instructions (via Reserved Instruction
      exceptions) whilst allowing others to execute natively. It therefore has
      a penalty in terms of execution speed, and should only be used when no
      fully native mode can be. As more binaries are recompiled to use either
      the FPXX or FP64(A) ABIs, the need for hybrid FPRs should diminish.
      However in the short to mid term it allows for a gradual transition
      towards that world, rather than a complete ABI break which is not
      feasible for some users & not desirable for many.
      
      A task will be executed using the hybrid FPR scheme when its
      TIF_HYBRID_FPREGS flag is set & TIF_32BIT_FPREGS is clear. A further
      patch will set the flags as necessary, this patch simply adds the
      infrastructure necessary for the hybrid FPR mode to work.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: linux-fsdevel@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/7683/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      4227a2d4
  3. 07 11月, 2014 1 次提交
    • M
      MIPS: Fix build with binutils 2.24.51+ · 842dfc11
      Manuel Lauss 提交于
      Starting with version 2.24.51.20140728 MIPS binutils complain loudly
      about mixing soft-float and hard-float object files, leading to this
      build failure since GCC is invoked with "-msoft-float" on MIPS:
      
      {standard input}: Warning: .gnu_attribute 4,3 requires `softfloat'
        LD      arch/mips/alchemy/common/built-in.o
      mipsel-softfloat-linux-gnu-ld: Warning: arch/mips/alchemy/common/built-in.o
       uses -msoft-float (set by arch/mips/alchemy/common/prom.o),
       arch/mips/alchemy/common/sleeper.o uses -mhard-float
      
      To fix this, we detect if GAS is new enough to support "-msoft-float" command
      option, and if it does, we can let GCC pass it to GAS;  but then we also need
      to sprinkle the files which make use of floating point registers with the
      necessary ".set hardfloat" directives.
      Signed-off-by: NManuel Lauss <manuel.lauss@gmail.com>
      Cc: Linux-MIPS <linux-mips@linux-mips.org>
      Cc: Matthew Fortune <Matthew.Fortune@imgtec.com>
      Cc: Markos Chandras <Markos.Chandras@imgtec.com>
      Cc: Maciej W. Rozycki <macro@linux-mips.org>
      Patchwork: https://patchwork.linux-mips.org/patch/8355/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      842dfc11
  4. 02 8月, 2014 2 次提交
  5. 23 5月, 2014 1 次提交
  6. 27 3月, 2014 1 次提交
  7. 15 3月, 2014 1 次提交
  8. 06 2月, 2014 1 次提交
  9. 14 1月, 2014 2 次提交
    • P
      MIPS: Support for 64-bit FP with O32 binaries · 597ce172
      Paul Burton 提交于
      CPUs implementing MIPS32 R2 may include a 64-bit FPU, just as MIPS64 CPUs
      do. In order to preserve backwards compatibility a 64-bit FPU will act
      like a 32-bit FPU (by accessing doubles from the least significant 32
      bits of an even-odd pair of FP registers) when the Status.FR bit is
      zero, again just like a mips64 CPU. The standard O32 ABI is defined
      expecting a 32-bit FPU, however recent toolchains support use of a
      64-bit FPU from an O32 MIPS32 executable. When an ELF executable is
      built to use a 64-bit FPU a new flag (EF_MIPS_FP64) is set in the ELF
      header.
      
      With this patch the kernel will check the EF_MIPS_FP64 flag when
      executing an O32 binary, and set Status.FR accordingly. The addition
      of O32 64-bit FP support lessens the opportunity for optimisation in
      the FPU emulator, so a CONFIG_MIPS_O32_FP64_SUPPORT Kconfig option is
      introduced to allow this support to be disabled for those that don't
      require it.
      
      Inspired by an earlier patch by Leonid Yegoshin, but implemented more
      cleanly & correctly.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: Paul Burton <paul.burton@imgtec.com>
      Patchwork: https://patchwork.linux-mips.org/patch/6154/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      597ce172
    • P
      MIPS: Remove unused {en,dis}able_fpu macros · 56a22d21
      Paul Burton 提交于
      These macros are not used anywhere in the kernel. Remove them.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/6111/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      56a22d21
  10. 01 2月, 2013 1 次提交
  11. 17 12月, 2009 1 次提交
  12. 11 10月, 2008 1 次提交
  13. 20 7月, 2008 1 次提交
    • D
      [MIPS] Fix missing prototypes in asm/fpu.h · f028b860
      Dmitri Vorobiev 提交于
      While building the Malta defconfig, sparse spat the following
      warnings:
      
      >>>>>>>>>>>>>>>>>>
      arch/mips/math-emu/kernel_linkage.c:31:6: warning: symbol
      'fpu_emulator_init_fpu' was not declared. Should it be static?
      
      arch/mips/math-emu/kernel_linkage.c:54:5: warning: symbol
      'fpu_emulator_save_context' was not declared. Should it be
      static?
      
      arch/mips/math-emu/kernel_linkage.c:68:5: warning: symbol
      'fpu_emulator_restore_context' was not declared. Should it be
      static?
      >>>>>>>>>>>>>>>>>>
      
      This patch fixes these errors by adding the proper prototypes
      to the include/asm-mips/fpu.h header, and actually using this
      header in the sparse-spotted source file.
      
      Build-tested with Malta defconfig.
      Signed-off-by: NDmitri Vorobiev <dmitri.vorobiev@movial.fi>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      f028b860
  14. 20 10月, 2007 1 次提交
  15. 11 5月, 2007 1 次提交
  16. 20 4月, 2007 2 次提交
  17. 17 3月, 2007 1 次提交
  18. 10 10月, 2006 1 次提交
  19. 20 6月, 2006 1 次提交
  20. 26 4月, 2006 1 次提交
  21. 19 4月, 2006 1 次提交
  22. 30 10月, 2005 1 次提交
  23. 05 9月, 2005 1 次提交
  24. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4