1. 11 11月, 2015 5 次提交
  2. 22 6月, 2015 3 次提交
  3. 17 6月, 2015 1 次提交
  4. 10 4月, 2015 1 次提交
  5. 01 4月, 2015 1 次提交
  6. 20 3月, 2015 1 次提交
  7. 18 3月, 2015 1 次提交
    • S
      MIPS: Rearrange PTE bits into fixed positions. · be0c37c9
      Steven J. Hill 提交于
      This patch rearranges the PTE bits into fixed positions for R2
      and later cores. In the past, the TLB handling code did runtime
      checking of RI/XI and adjusted the shifts and rotates in order
      to fit the largest PFN value into the PTE. The checking now
      occurs when building the TLB handler, thus eliminating those
      checks. These new arrangements also define the largest possible
      PFN value that can fit in the PTE. HUGE page support is only
      available for 64-bit cores. Layouts of the PTE bits are now:
      
         64-bit, R1 or earlier:     CCC D V G [S H] M A W R P
         32-bit, R1 or earler:      CCC D V G M A W R P
         64-bit, R2 or later:       CCC D V G RI/R XI [S H] M A W P
         32-bit, R2 or later:       CCC D V G RI/R XI M A W P
      
      [ralf@linux-mips.org: Fix another build error *rant* *rant*]
      Signed-off-by: NSteven J. Hill <Steven.Hill@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9353/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      be0c37c9
  8. 17 2月, 2015 1 次提交
  9. 16 2月, 2015 1 次提交
  10. 28 11月, 2014 1 次提交
  11. 25 11月, 2014 1 次提交
  12. 23 10月, 2014 1 次提交
    • D
      MIPS: tlbex: Properly fix HUGE TLB Refill exception handler · 9e0f162a
      David Daney 提交于
      In commit 8393c524 (MIPS: tlbex: Fix a missing statement for
      HUGETLB), the TLB Refill handler was fixed so that non-OCTEON targets
      would work properly with huge pages.  The change was incorrect in that
      it broke the OCTEON case.
      
      The problem is shown here:
      
          xxx0:	df7a0000 	ld	k0,0(k1)
          .
          .
          .
          xxxc0:	df610000 	ld	at,0(k1)
          xxxc4:	335a0ff0 	andi	k0,k0,0xff0
          xxxc8:	e825ffcd 	bbit1	at,0x5,0x0
          xxxcc:	003ad82d 	daddu	k1,at,k0
          .
          .
          .
      
      In the non-octeon case there is a destructive test for the huge PTE
      bit, and then at 0, $k0 is reloaded (that is what the 8393c524
      patch added).
      
      In the octeon case, we modify k1 in the branch delay slot, but we
      never need k0 again, so the new load is not needed, but since k1 is
      modified, if we do the load, we load from a garbage location and then
      get a nested TLB Refill, which is seen in userspace as either SIGBUS
      or SIGSEGV (depending on the garbage).
      
      The real fix is to only do this reloading if it is needed, and never
      where it is harmful.
      Signed-off-by: NDavid Daney <david.daney@cavium.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: Fuxin Zhang <zhangfx@lemote.com>
      Cc: Zhangjin Wu <wuzhangjin@gmail.com>
      Cc: stable@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/8151/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      9e0f162a
  13. 02 8月, 2014 3 次提交
    • L
      MIPS: Use dedicated exception handler if CPU supports RI/XI exceptions · 5890f70f
      Leonid Yegoshin 提交于
      Use the regular tlb_do_page_fault_0 (no write) handler to handle
      the RI and XI exceptions. Also skip the RI/XI validation check
      on TLB load handler since it's redundant when the CPU has
      unique RI/XI exceptions.
      Singed-off-by: NLeonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/7339/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      5890f70f
    • M
      MIPS: mm: Use the Hardware Page Table Walker if the core supports it · f1014d1b
      Markos Chandras 提交于
      The Hardware Page Table Walker aims to speed up TLB refill exceptions
      by handling them in the hardware level instead of having a software
      TLB refill handler. However, a TLB refill exception can still be
      thrown in certain cases such as, synchronus exceptions, or address
      translation or memory errors during the HTW operation. As a result of
      which, HTW must not be considered a complete replacement for the TLB
      refill software handler, but rather a fast-path for it.
      For HTW to work, the PWBase register must contain the task's page
      global directory address so the HTW will kick in on TLB refill
      exceptions.
      
      Due to HTW being a separate engine embedded deep in the CPU pipeline,
      we need to restart the HTW everytime a PTE changes to avoid HTW
      fetching a old entry from the page tables. It's also necessary to
      restart the HTW on context switches to prevent it from fetching a
      page from the previous process. Finally, since HTW is using the
      entryhi register to write the translations to the TLB, it's necessary
      to stop the HTW whenever the entryhi changes (eg for tlb probe
      perations) and enable it back afterwards.
      
      == Performance ==
      
      The following trivial test was used to measure the performance of the
      HTW. Using the same root filesystem, the following command was used
      to measure the number of tlb refill handler executions with and
      without (using 'nohtw' kernel parameter) HTW support.  The kernel was
      modified to use a scratch register as a counter for the TLB refill
      exceptions.
      
      find /usr -type f -exec ls -lh {} \;
      
      HTW Enabled:
      TLB refill exceptions: 12306
      
      HTW Disabled:
      TLB refill exceptions: 17805
      Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Patchwork: https://patchwork.linux-mips.org/patch/7336/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      f1014d1b
    • L
      MIPS: bugfix: missed cache flush of TLB refill handler · 1062080a
      Leonid Yegoshin 提交于
      Commit
      
          Commit 1d40cfcd
          Author: Ralf Baechle <ralf@linux-mips.org>
          Date:   Fri Jul 15 15:23:23 2005 +0000
      
          Avoid SMP cacheflushes.  This is a minor optimization of startup but
          will also avoid smp_call_function from doing stupid things when called
          from a CPU that is not yet marked online.
      
      missed an appropriate cache flush of TLB refill handler because that time it was
      at fixed location CAC_BASE. After years the refill handler in EBASE vector
      is not at that location and can be allocated in some another memory and needs
      I-cache sync as other TLB exception vectors.
      
      Besides that, the new function - local_flash_icache_range() was introduced
      to avoid SMP cacheflushes.
      Signed-off-by: NLeonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: paul.gortmaker@windriver.com
      Cc: jchandra@broadcom.com
      Cc: linux-kernel@vger.kernel.org
      Cc: david.daney@cavium.com
      Patchwork: https://patchwork.linux-mips.org/patch/7312/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      1062080a
  14. 30 7月, 2014 1 次提交
  15. 02 6月, 2014 1 次提交
  16. 31 5月, 2014 1 次提交
  17. 15 5月, 2014 1 次提交
  18. 01 4月, 2014 2 次提交
  19. 27 3月, 2014 2 次提交
  20. 07 3月, 2014 1 次提交
  21. 25 1月, 2014 1 次提交
  22. 23 1月, 2014 1 次提交
  23. 30 10月, 2013 3 次提交
  24. 18 9月, 2013 1 次提交
  25. 26 8月, 2013 1 次提交
  26. 19 7月, 2013 2 次提交
  27. 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