1. 17 2月, 2015 3 次提交
  2. 16 2月, 2015 1 次提交
  3. 12 2月, 2015 1 次提交
    • P
      MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS · 9791554b
      Paul Burton 提交于
      Userland code may be built using an ABI which permits linking to objects
      that have more restrictive floating point requirements. For example,
      userland code may be built to target the O32 FPXX ABI. Such code may be
      linked with other FPXX code, or code built for either one of the more
      restrictive FP32 or FP64. When linking with more restrictive code, the
      overall requirement of the process becomes that of the more restrictive
      code. The kernel has no way to know in advance which mode the process
      will need to be executed in, and indeed it may need to change during
      execution. The dynamic loader is the only code which will know the
      overall required mode, and so it needs to have a means to instruct the
      kernel to switch the FP mode of the process.
      
      This patch introduces 2 new options to the prctl syscall which provide
      such a capability. The FP mode of the process is represented as a
      simple bitmask combining a number of mode bits mirroring those present
      in the hardware. Userland can either retrieve the current FP mode of
      the process:
      
        mode = prctl(PR_GET_FP_MODE);
      
      or modify the current FP mode of the process:
      
        err = prctl(PR_SET_FP_MODE, new_mode);
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: Matthew Fortune <matthew.fortune@imgtec.com>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/8899/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      9791554b
  4. 24 11月, 2014 4 次提交
  5. 02 8月, 2014 5 次提交
  6. 04 6月, 2014 1 次提交
  7. 25 5月, 2014 1 次提交
  8. 24 5月, 2014 1 次提交
    • R
      MIPS: MT: Remove SMTC support · b633648c
      Ralf Baechle 提交于
      Nobody is maintaining SMTC anymore and there also seems to be no userbase.
      Which is a pity - the SMTC technology primarily developed by Kevin D.
      Kissell <kevink@paralogos.com> is an ingenious demonstration for the MT
      ASE's power and elegance.
      
      Based on Markos Chandras <Markos.Chandras@imgtec.com> patch
      https://patchwork.linux-mips.org/patch/6719/ which while very similar did
      no longer apply cleanly when I tried to merge it plus some additional
      post-SMTC cleanup - SMTC was a feature as tricky to remove as it was to
      merge once upon a time.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      b633648c
  9. 02 5月, 2014 1 次提交
  10. 27 3月, 2014 5 次提交
  11. 07 3月, 2014 1 次提交
  12. 23 1月, 2014 4 次提交
  13. 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
  14. 30 10月, 2013 3 次提交
  15. 18 9月, 2013 1 次提交
  16. 17 7月, 2013 1 次提交
  17. 15 7月, 2013 1 次提交
    • P
      MIPS: Delete __cpuinit/__CPUINIT usage from MIPS code · 078a55fc
      Paul Gortmaker 提交于
      commit 3747069b25e419f6b51395f48127e9812abc3596 upstream.
      
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      
      Note that some harmless section mismatch warnings may result, since
      notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
      and are flagged as __cpuinit  -- so if we remove the __cpuinit from
      the arch specific callers, we will also get section mismatch warnings.
      As an intermediate step, we intend to turn the linux/init.h cpuinit
      related content into no-ops as early as possible, since that will get
      rid of these warnings.  In any case, they are temporary and harmless.
      
      Here, we remove all the MIPS __cpuinit from C code and __CPUINIT
      from asm files.  MIPS is interesting in this respect, because there
      are also uasm users hiding behind their own renamed versions of the
      __cpuinit macros.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      [ralf@linux-mips.org: Folded in Paul's followup fix.]
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/5494/
      Patchwork: https://patchwork.linux-mips.org/patch/5495/
      Patchwork: https://patchwork.linux-mips.org/patch/5509/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      078a55fc
  18. 01 7月, 2013 2 次提交
    • S
      MIPS: microMIPS: Fix improper definition of ISA exception bit. · c6213c6c
      Steven J. Hill 提交于
      The ISA exception bit selects whether exceptions are taken in classic
      or microMIPS mode. This bit is Config3.ISAOnExc and was improperly
      defined as bits 16 and 17 instead of just bit 16. A new function was
      added so that platforms could set this bit when running a kernel
      compiled with only microMIPS instructions.
      Signed-off-by: NSteven J. Hill <Steven.Hill@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/5377/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      c6213c6c
    • R
      MIPS: Get rid of MIPS I flag and test macros. · 1990e542
      Ralf Baechle 提交于
      MIPS I is the ancestor of all MIPS ISA and architecture variants.  Anything
      ever build in the MIPS empire is either MIPS I or at least contains MIPS I.
      If it's running Linux, that is.
      
      So there is little point in having cpu_has_mips_1 because it will always
      evaluate as true - though usually only at runtime.  Thus there is no
      point in having the MIPS_CPU_ISA_I ISA flag, so get rid of it.
      
      Little complication: traps.c was using a test for a pure MIPS I ISA as
      a test for an R3000-style cp0.  To deal with that, use a check for
      cpu_has_3kex or cpu_has_4kex instead.
      
      cpu_has_3kex is a new macro.  At the moment its default implementation is
      !cpu_has_4kex but this may eventually change if Linux is ever going to
      support the oddball MIPS processors R6000 and R8000 so users of either
      of these macros should not make any assumptions.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Patchwork: https://patchwork.linux-mips.org/patch/5551/
      1990e542
  19. 25 6月, 2013 1 次提交
    • J
      MIPS: Flush TLB handlers directly after writing them · a3d9086b
      Jonas Gorski 提交于
      When having enabled MIPS_PGD_C0_CONTEXT, trap_init() might call the
      generated tlbmiss_handler_setup_pgd before it was committed to memory,
      causing boot failures:
      
        trap_init()
         |- per_cpu_trap_init()
         |   |- TLBMISS_HANDLER_SETUP()
         |       |- tlbmiss_handler_setup_pgd()
         |- flush_tlb_handlers()
      
      To avoid this, move flush_tlb_handlers() into build_tlb_refill_handler()
      right after they were generated. We can do this as the cache handling is
      initialized just before creating the tlb handlers.
      
      This issue was introduced in 3d8bfdd0
      ("MIPS: Use C0_KScratch (if present) to hold PGD pointer.").
      Signed-off-by: NJonas Gorski <jogo@openwrt.org>
      Cc: linux-mips@linux-mips.org
      Cc: Steven J. Hill <Steven.Hill@imgtec.com>
      Cc: Jayachandran C <jchandra@broadcom.com>
      Cc: David Daney <david.daney@cavium.com>
      Patchwork: https://patchwork.linux-mips.org/patch/5539/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      a3d9086b
  20. 13 6月, 2013 1 次提交
  21. 11 6月, 2013 1 次提交