1. 23 7月, 2012 1 次提交
    • K
      MIPS: Add CPU support for Loongson1B · 2fa36399
      Kelvin Cheung 提交于
      Loongson 1B is a 32-bit SoC designed by Institute of Computing Technology
      (ICT) and the Chinese Academy of Sciences (CAS), which implements the
      MIPS32 release 2 instruction set.
      
      [ralf@linux-mips.org: But which is not strictly a MIPS32 compliant device
      which also is why it identifies itself with the Legacy Vendor ID in the
      PrID register.  When applying the patch I shoveled some code around to
      keep things in alphabetical order and avoid forward declarations.]
      Signed-off-by: NKelvin Cheung <keguang.zhang@gmail.com>
      Cc: To: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: wuzhangjin@gmail.com
      Cc: zhzhl555@gmail.com
      Cc: Kelvin Cheung <keguang.zhang@gmail.com>
      Patchwork: https://patchwork.linux-mips.org/patch/3976/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      2fa36399
  2. 19 7月, 2012 3 次提交
  3. 07 7月, 2012 1 次提交
  4. 17 5月, 2012 3 次提交
  5. 15 5月, 2012 1 次提交
  6. 29 3月, 2012 1 次提交
  7. 21 2月, 2012 1 次提交
  8. 13 1月, 2012 2 次提交
  9. 08 12月, 2011 3 次提交
  10. 11 11月, 2011 1 次提交
    • M
      MIPS: ASID conflict after CPU hotplug · 5c200197
      Maksim Rayskiy 提交于
      I am running SMP Linux 2.6.37-rc1 on BMIPS5000 (single core dual thread)
      and observe some abnormalities when doing system suspend/resume which I
      narrowed down to cpu hotplugging. The suspend brings the second thread
      processor down and then restarts it, after which I see memory corruption
      in userspace. I started digging and found out that problem occurs because
      while doing execve() the child process is getting the same ASID as the
      parent, which obviously corrupts parent's address space.
      
      Further digging showed that activate_mm() calls get_new_mmu_context() to
      get a new ASID, but at this time ASID field in entryHi is 1, and
      asid_cache(cpu) is 0x100 (it was just reset to ASID_FIRST_VERSION when
      the secondary TP was booting).
      
      So, get_new_mmu_context() increments the asid_cache(cpu) value to
      0x101, and thus puts 0x01 into entryHi. The result - ASID field does
      not get changed as it was supposed to.
      
      My solution is very simple - do not reset asid_cache(cpu) on TP warm
      restart.
      
      Patchwork: https://patchwork.linux-mips.org/patch/1797/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      5c200197
  11. 01 11月, 2011 1 次提交
  12. 02 10月, 2011 1 次提交
  13. 21 9月, 2011 1 次提交
  14. 01 7月, 2011 1 次提交
    • P
      perf: Remove the nmi parameter from the swevent and overflow interface · a8b0ca17
      Peter Zijlstra 提交于
      The nmi parameter indicated if we could do wakeups from the current
      context, if not, we would set some state and self-IPI and let the
      resulting interrupt do the wakeup.
      
      For the various event classes:
      
        - hardware: nmi=0; PMI is in fact an NMI or we run irq_work_run from
          the PMI-tail (ARM etc.)
        - tracepoint: nmi=0; since tracepoint could be from NMI context.
        - software: nmi=[0,1]; some, like the schedule thing cannot
          perform wakeups, and hence need 0.
      
      As one can see, there is very little nmi=1 usage, and the down-side of
      not using it is that on some platforms some software events can have a
      jiffy delay in wakeup (when arch_irq_work_raise isn't implemented).
      
      The up-side however is that we can remove the nmi parameter and save a
      bunch of conditionals in fast paths.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Michael Cree <mcree@orcon.net.nz>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@gmail.com>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Eric B Munson <emunson@mgebm.net>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Link: http://lkml.kernel.org/n/tip-agjev8eu666tvknpb3iaj0fg@git.kernel.orgSigned-off-by: NIngo Molnar <mingo@elte.hu>
      a8b0ca17
  15. 18 5月, 2011 1 次提交
  16. 19 1月, 2011 1 次提交
  17. 17 12月, 2010 1 次提交
  18. 30 10月, 2010 2 次提交
  19. 07 10月, 2010 1 次提交
  20. 05 8月, 2010 4 次提交
  21. 06 7月, 2010 1 次提交
  22. 22 5月, 2010 1 次提交
  23. 21 5月, 2010 1 次提交
    • J
      mips,kgdb: kdb low level trap catch and stack trace · 5dd11d5d
      Jason Wessel 提交于
      The only way the debugger can handle a trap in inside rcu_lock,
      notify_die, or atomic_notifier_call_chain without a recursive fault is
      to have a low level "first opportunity handler" do_trap_or_bp() handler.
      
      Generally this will be something the vast majority of folks will not
      need, but for those who need it, it is added as a kernel .config
      option called KGDB_LOW_LEVEL_TRAP.
      
      Also added was a die notification for oops such that kdb can catch an
      oops for analysis.
      
      There appeared to be no obvious way to pass the struct pt_regs from
      the original exception back to the stack back tracer, so a special
      case was added to show_stack() for when kdb is active because you
      generally desire to generally look at the back trace of the original
      exception.
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      5dd11d5d
  24. 01 5月, 2010 2 次提交
  25. 13 4月, 2010 1 次提交
  26. 27 2月, 2010 2 次提交
  27. 11 2月, 2010 1 次提交