1. 10 7月, 2015 2 次提交
  2. 22 6月, 2015 1 次提交
  3. 17 6月, 2015 1 次提交
  4. 06 6月, 2015 1 次提交
  5. 02 4月, 2015 1 次提交
    • M
      MIPS: c-r4k.c: Fix the 74K D-cache alias erratum workaround · e2e7f29a
      Maciej W. Rozycki 提交于
      Fix the 74K D-cache alias erratum workaround so that it actually works.
      Our current code sets MIPS_CACHE_VTAG for the D-cache, but that flag
      only has any effect for the I-cache.  Additionally MIPS_CACHE_PINDEX is
      set for the D-cache if CP0.Config7.AR is also set for an affected
      processor, leading to confusing information in the bootstrap log (the
      flag isn't used beyond that).
      
      So delete the setting of MIPS_CACHE_VTAG and rely on MIPS_CACHE_ALIASES,
      set in a common place, removing I-cache coherency issues seen in GDB
      testing with software breakpoints, gdbserver and ptrace(2), on affected
      systems.
      
      While at it add a little piece of explanation of what CP0.Config6.SYND
      is so that people do not have to chase documentation.
      Signed-off-by: NMaciej W. Rozycki <macro@codesourcery.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/8507/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      e2e7f29a
  6. 01 4月, 2015 1 次提交
  7. 17 2月, 2015 2 次提交
  8. 16 2月, 2015 1 次提交
  9. 24 11月, 2014 1 次提交
  10. 30 7月, 2014 1 次提交
  11. 31 5月, 2014 1 次提交
  12. 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
  13. 23 5月, 2014 1 次提交
  14. 02 5月, 2014 1 次提交
  15. 01 4月, 2014 1 次提交
  16. 27 3月, 2014 7 次提交
  17. 07 3月, 2014 2 次提交
  18. 23 1月, 2014 3 次提交
  19. 15 1月, 2014 2 次提交
  20. 30 10月, 2013 1 次提交
  21. 02 10月, 2013 1 次提交
    • Y
      MIPS: Fix forgotten preempt_enable() when CPU has inclusive pcaches · 5596b0b2
      Yoichi Yuasa 提交于
      [    1.904000] BUG: scheduling while atomic: swapper/1/0x00000002
      [    1.908000] Modules linked in:
      [    1.916000] CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0-rc2-lemote-los.git-5318619-dirty #1
      [    1.920000] Stack : 0000000031aac000 ffffffff810d0000 0000000000000052 ffffffff802730a4
                0000000000000000 0000000000000001 ffffffff810cdf90 ffffffff810d0000
                ffffffff8068b968 ffffffff806f5537 ffffffff810cdf90 980000009f0782e8
                0000000000000001 ffffffff80720000 ffffffff806b0000 980000009f078000
                980000009f290000 ffffffff805f312c 980000009f05b5d8 ffffffff80233518
                980000009f05b5e8 ffffffff80274b7c 980000009f078000 ffffffff8068b968
                0000000000000000 0000000000000000 0000000000000000 0000000000000000
                0000000000000000 980000009f05b520 0000000000000000 ffffffff805f2f6c
                0000000000000000 ffffffff80700000 ffffffff80700000 ffffffff806fc758
                ffffffff80700000 ffffffff8020be98 ffffffff806fceb0 ffffffff805f2f6c
                ...
      [    2.028000] Call Trace:
      [    2.032000] [<ffffffff8020be98>] show_stack+0x80/0x98
      [    2.036000] [<ffffffff805f2f6c>] __schedule_bug+0x44/0x6c
      [    2.040000] [<ffffffff805fac58>] __schedule+0x518/0x5b0
      [    2.044000] [<ffffffff805f8a58>] schedule_timeout+0x128/0x1f0
      [    2.048000] [<ffffffff80240314>] msleep+0x3c/0x60
      [    2.052000] [<ffffffff80495400>] do_probe+0x238/0x3a8
      [    2.056000] [<ffffffff804958b0>] ide_probe_port+0x340/0x7e8
      [    2.060000] [<ffffffff80496028>] ide_host_register+0x2d0/0x7a8
      [    2.064000] [<ffffffff8049c65c>] ide_pci_init_two+0x4e4/0x790
      [    2.068000] [<ffffffff8049f9b8>] amd74xx_probe+0x148/0x2c8
      [    2.072000] [<ffffffff803f571c>] pci_device_probe+0xc4/0x130
      [    2.076000] [<ffffffff80478f60>] driver_probe_device+0x98/0x270
      [    2.080000] [<ffffffff80479298>] __driver_attach+0xe0/0xe8
      [    2.084000] [<ffffffff80476ab0>] bus_for_each_dev+0x78/0xe0
      [    2.088000] [<ffffffff80478468>] bus_add_driver+0x230/0x310
      [    2.092000] [<ffffffff80479b44>] driver_register+0x84/0x158
      [    2.096000] [<ffffffff80200504>] do_one_initcall+0x104/0x160
      Signed-off-by: NYoichi Yuasa <yuasa@linux-mips.org>
      Reported-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Cc: linux-mips@linux-mips.org
      Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
      Patchwork: https://patchwork.linux-mips.org/patch/5941/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      5596b0b2
  22. 19 9月, 2013 2 次提交
  23. 18 9月, 2013 1 次提交
  24. 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
  25. 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
  26. 08 5月, 2013 1 次提交
  27. 02 5月, 2013 1 次提交