1. 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
  2. 02 8月, 2014 1 次提交
  3. 14 1月, 2014 1 次提交
    • 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
  4. 30 10月, 2013 1 次提交
  5. 01 2月, 2013 1 次提交
  6. 17 12月, 2010 1 次提交
  7. 05 8月, 2010 1 次提交
  8. 13 4月, 2010 2 次提交
    • D
      MIPS: Preliminary VDSO · c52d0d30
      David Daney 提交于
      This is a preliminary patch to add a vdso to all user processes.  Still
      missing are ELF headers and .eh_frame information.  But it is enough to
      allow us to move signal trampolines off of the stack.  Note that emulation
      of branch delay slots in the FPU emulator still requires the stack.
      
      We allocate a single page (the vdso) and write all possible signal
      trampolines into it.  The stack is moved down by one page and the vdso is
      mapped into this space.
      Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
      To: linux-mips@linux-mips.org
      Patchwork: http://patchwork.linux-mips.org/patch/975/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      c52d0d30
    • R
      MIPS: Fix elfcore.c build warning · d5d3102b
      Ralf Baechle 提交于
      kernel/elfcore.c includes <linux/elf.h> which includes the <asm/elf.h>.  In
      <asm/elf.h>, struct pt_regs is declared inside the parameter list of the
      elf_dump_regs function which causes a kernel build warning.
      
      Fixed by adding a forward declaration of struct pt_regs.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      d5d3102b
  9. 27 2月, 2010 1 次提交
  10. 16 12月, 2009 1 次提交
  11. 03 7月, 2009 1 次提交
    • Y
      MIPS: 64-bit: Fix o32 core dump · cad9bc69
      Yong Zhang 提交于
      If an o32 process generates a core dump on a 64 bit kernel, the core file
      will not be correctly recognized. This is because ELF_CORE_COPY_REGS and
      ELF_CORE_COPY_TASK_REGS are not correctly defined for o32 and will use
      the default register set which would be CONFIG_64BIT in asm/elf.h.
      
      So we'll switch to use the right register defines in this situation by
      checking for WANT_COMPAT_REG_H and use the right defines of
      ELF_CORE_COPY_REGS and ELF_CORE_COPY_TASK_REGS.
      
      [Ralf: made ELF_CORE_COPY_TASK_REGS() bullet-proof against funny arguments.]
      Signed-off-by: NYong Zhang <yong.zhang@windriver.com>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      cad9bc69
  12. 22 12月, 2008 1 次提交
  13. 16 10月, 2008 1 次提交
  14. 11 10月, 2008 1 次提交
  15. 08 2月, 2008 1 次提交
  16. 12 10月, 2007 1 次提交
  17. 01 8月, 2007 1 次提交
  18. 26 4月, 2006 1 次提交
  19. 19 4月, 2006 1 次提交
  20. 10 1月, 2006 1 次提交
  21. 07 11月, 2005 1 次提交
  22. 30 10月, 2005 5 次提交
  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