1. 19 9月, 2013 2 次提交
  2. 18 9月, 2013 1 次提交
  3. 17 9月, 2013 1 次提交
    • R
      MIPS: Fix accessing to per-cpu data when flushing the cache · ff522058
      Ralf Baechle 提交于
      This fixes the following issue
      
      BUG: using smp_processor_id() in preemptible [00000000] code: kjournald/1761
      caller is blast_dcache32+0x30/0x254
      Call Trace:
      [<8047f02c>] dump_stack+0x8/0x34
      [<802e7e40>] debug_smp_processor_id+0xe0/0xf0
      [<80114d94>] blast_dcache32+0x30/0x254
      [<80118484>] r4k_dma_cache_wback_inv+0x200/0x288
      [<80110ff0>] mips_dma_map_sg+0x108/0x180
      [<80355098>] ide_dma_prepare+0xf0/0x1b8
      [<8034eaa4>] do_rw_taskfile+0x1e8/0x33c
      [<8035951c>] ide_do_rw_disk+0x298/0x3e4
      [<8034a3c4>] do_ide_request+0x2e0/0x704
      [<802bb0dc>] __blk_run_queue+0x44/0x64
      [<802be000>] queue_unplugged.isra.36+0x1c/0x54
      [<802beb94>] blk_flush_plug_list+0x18c/0x24c
      [<802bec6c>] blk_finish_plug+0x18/0x48
      [<8026554c>] journal_commit_transaction+0x3b8/0x151c
      [<80269648>] kjournald+0xec/0x238
      [<8014ac00>] kthread+0xb8/0xc0
      [<8010268c>] ret_from_kernel_thread+0x14/0x1c
      
      Caches in most systems are identical - but not always, so we can't avoid
      the use of smp_call_function() by just looking at the boot CPU's data,
      have to fiddle with preemption instead.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/5835
      ff522058
  4. 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
  5. 08 5月, 2013 1 次提交
  6. 02 5月, 2013 1 次提交
  7. 05 4月, 2013 1 次提交
  8. 17 2月, 2013 1 次提交
  9. 01 2月, 2013 1 次提交
  10. 14 12月, 2012 2 次提交
  11. 09 11月, 2012 1 次提交
  12. 14 9月, 2012 1 次提交
  13. 19 7月, 2012 1 次提交
  14. 07 7月, 2012 1 次提交
  15. 17 5月, 2012 1 次提交
  16. 29 3月, 2012 1 次提交
  17. 20 3月, 2012 1 次提交
  18. 08 12月, 2011 1 次提交
  19. 20 10月, 2011 1 次提交
  20. 26 7月, 2011 1 次提交
    • K
      MIPS: Add SYNC after cacheflush · d0023c4a
      Kevin Cernekee 提交于
      On processors with deep write buffers, it is likely that many cycles
      will pass between a CACHE instruction and the time the data actually
      gets written out to DRAM.  Add a SYNC instruction to ensure that the
      buffers get emptied before the flush functions return.
      
      Actual problem seen in the wild:
      
      1) dma_alloc_coherent() allocates cached memory
      
      2) memset() is called to clear the new pages
      
      3) dma_cache_wback_inv() is called to flush the zero data out to memory
      
      4) dma_alloc_coherent() returns an uncached (kseg1) pointer to the
      freshly allocated pages
      
      5) Caller writes data through the kseg1 pointer
      
      6) Buffered writeback data finally gets flushed out to DRAM
      
      7) Part of caller's data is inexplicably zeroed out
      
      This patch adds SYNC between steps 3 and 4, which fixed the problem.
      Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: 
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      d0023c4a
  21. 19 5月, 2011 1 次提交
  22. 11 5月, 2011 1 次提交
    • R
      MIPS: c-r4k: Fix GCC 4.6.0 build error · 71271aab
      Ralf Baechle 提交于
        CC      arch/mips/mm/c-r4k.o
      arch/mips/mm/c-r4k.c: In function 'probe_scache':
      arch/mips/mm/c-r4k.c:1078:6: error: variable 'tmp' set but not used [-Werror=unused-but-set-variable]
      cc1: all warnings being treated as errors
      
      Older GCC versions didn't warn about the unused variable tmp because it was
      getting initialized.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      71271aab
  23. 06 4月, 2011 1 次提交
  24. 30 10月, 2010 2 次提交
  25. 25 6月, 2009 1 次提交
  26. 17 6月, 2009 1 次提交
  27. 14 5月, 2009 1 次提交
  28. 30 3月, 2009 1 次提交
    • M
      MIPS: Alchemy: unify CPU model constants. · 270717a8
      Manuel Lauss 提交于
      This patch removes the various CPU_AU1??? model constants in favor of
      a single CPU_ALCHEMY one.
      
      All currently existing Alchemy models are identical in terms of cpu
      core and cache size/organization.  The parts of the mips kernel which
      need to know the exact CPU revision extract it from the c0_prid register
      already; and finally nothing else in-tree depends on those any more.
      
      Should a new variant with slightly different "company options" and/or
      "processor revision" bits in c0_prid appear, it will be supported
      immediately (minus an exact model string in cpuinfo).
      Signed-off-by: NManuel Lauss <mano@roarinelk.homelinux.net>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      270717a8
  29. 24 3月, 2009 1 次提交
  30. 31 1月, 2009 1 次提交
  31. 06 9月, 2008 1 次提交
  32. 26 6月, 2008 1 次提交
  33. 16 6月, 2008 2 次提交
  34. 29 4月, 2008 2 次提交
  35. 08 4月, 2008 1 次提交