1. 29 8月, 2017 1 次提交
  2. 28 3月, 2017 1 次提交
    • J
      KVM: MIPS: Implement VZ support · c992a4f6
      James Hogan 提交于
      Add the main support for the MIPS Virtualization ASE (A.K.A. VZ) to MIPS
      KVM. The bulk of this work is in vz.c, with various new state and
      definitions elsewhere.
      
      Enough is implemented to be able to run on a minimal VZ core. Further
      patches will fill out support for guest features which are optional or
      can be disabled.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: "Radim Krčmář" <rkrcmar@redhat.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      Cc: linux-doc@vger.kernel.org
      c992a4f6
  3. 11 12月, 2016 1 次提交
  4. 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
  5. 18 9月, 2013 1 次提交
  6. 03 9月, 2013 1 次提交
    • M
      MIPS: R4k clock source initialization bug fix · afddce0c
      Maciej W. Rozycki 提交于
      This is a fix for a bug introduced with commit
      447cdf26, submitted as archived here:
      http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20080312235002.c717dde3.yoichi_yuasa%40tripeaks.co.jp
      regrettably with no further explanation.
      
      The issue is with the CP0 Count register read erratum present on R4000 and
      some R4400 processors.  If this erratum is present, then a read from this
      register that happens around the time it reaches the value stored in the
      CP0 Compare register causes a CP0 timer interrupt that is supposed to
      happen when the values in the two registers match to be missed.  The
      implication for the chips affected is the CP0 timer can be used either as
      a source of a timer interrupt (a clock event) or as a source of a
      high-resolution counter (a clock source), but not both at a time.
      
      The erratum does not affect timer interrupt operation itself, because in
      this case the CP0 Count register is only read while the timer interrupt
      has already been raised, while high-resolution counter references happen
      at random times.
      
      Additionally some systems apparently have issues with the timer interrupt
      line being routed externally and not following the usual CP0 Count/Compare
      semantics.  In this case we don't want to use the R4k clock event.
      
      We've meant to address the erratum and the timer interrupt routing issue
      in time_init, however the commit referred to above broke our solution.
      What we currently have is we enable the R4k clock source if the R4k clock
      event initialization has succeeded (the timer is present and has no timer
      interrupt routing issue) or there is no CP0 Count register read erratum.
      Which gives the following boolean matrix:
      
      clock event | count erratum => clock source
      ------------+---------------+--------------
           0      |       0       |      1 (OK)
           0      |       1       |      0 (bug!) -> no interference, could use
           1      |       0       |      1 (OK)
           1      |       1       |      1 (bug!) -> can't use, interference
      
      What we want instead is to enable the R4k clock source if there is no CP0
      Count register read erratum (obviously) or the R4k clock event
      initialization has *failed* -- because in the latter case we won't be
      using the timer interrupt anyway, so we don't care about any interference
      CP0 Count reads might cause with the interrupt.  This corresponds to the
      following boolean matrix:
      
      clock event | count erratum => clock source
      ------------+---------------+--------------
           0      |       0       |      1
           0      |       1       |      1
           1      |       0       |      1
           1      |       1       |      0
      
      This is implemented here, effectively reverting the problematic commit,
      and a short explanation is given next to code modified so that the
      rationale is known to future readers and confusion is prevented from
      happening here again.
      
      It is worth noting that mips_clockevent_init returns 0 upon success while
      cpu_has_mfc0_count_bug returns 0 upon failure.  This is because the former
      function returns an error code while the latter returns a boolean value.
      To signify the difference I have therefore chosen to compare the result of
      the former call explicitly against 0.
      Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/5799/
      afddce0c
  7. 01 2月, 2013 1 次提交
  8. 01 11月, 2011 1 次提交
  9. 31 3月, 2011 1 次提交
  10. 14 11月, 2009 1 次提交
  11. 29 4月, 2008 2 次提交
  12. 01 4月, 2008 1 次提交
  13. 29 1月, 2008 1 次提交
  14. 07 1月, 2008 1 次提交
  15. 15 12月, 2007 1 次提交
    • R
      [MIPS] time: Delete weak definition of plat_time_init() due to gcc bug. · 4037500e
      Ralf Baechle 提交于
      Frank Rowand <frank.rowand@am.sony.com> reports:
      
      > In linux-2.6.24-rc4 the Toshiba RBTX4927 hangs on boot.
      >
      > The cause is that plat_time_init() from arch/mips/tx4927/common/
      > tx4927_setup.c does not override the __weak plat_time_init() from
      > arch/mips/kernel/time.c.  This is due to a compiler bug in gcc 4.1.1.  The
      > bug is reported to not exist in earlier versions of gcc, and to be fixed in
      > 4.1.2.  The problem is that the __weak plat_time_init() is empty and thus
      > gets optimized out of existence (thus the linker is never given the option
      > to replace the __weak function).
      
      [ He meant the call to plat_time_init() from time_init() gets optimized away ]
      
      > For more info on the gcc bug see
      >
      >    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27781
      >
      > The attached patch is one workaround.  Another possible workaround
      
      [ His patch adds -fno-unit-at-a-time for time.c ]
      
      > would be to change the __weak plat_time_init() to be a non-empty
      > function.
      
      The __weak definition of plat_time_init was only ever meant to be a
      migration helper to keep platforms that don't have a plat_time_init
      compiling.  A few greps says that all platforms now supply their own
      plat_time_init() so the weak definition is no longer needed.  So I
      instead delete it.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      4037500e
  16. 27 11月, 2007 2 次提交
    • R
      [MIPS] Only build r4k clocksource for systems that work ok with it. · 940f6b48
      Ralf Baechle 提交于
      In particular as-is it's not suited for multicore and mutiprocessors
      systems where there is on guarantee that the counter are synchronized
      or running from the same clock at all.  This broke Sibyte and probably
      others since the "[MIPS] Handle R4000/R4400 mfc0 from count register."
      commit.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      940f6b48
    • R
      [MIPS] Handle R4000/R4400 mfc0 from count register. · 5aa85c9f
      Ralf Baechle 提交于
      The R4000 and R4400 have an errata where if the cp0 count register is read
      in the exact moment when it matches the compare register no interrupt will
      be generated.
      
      This bug may be triggered if the cp0 count register is being used as
      clocksource and the compare interrupt as clockevent.  So a simple
      workaround is to avoid using the compare for both facilities on the
      affected CPUs.
      
      This is different from the workaround suggested in the old errata documents;
      at some opportunity probably the official version should be implemented
      and tested.  Another thing to find out is which processor versions
      exactly are affected.  I only have errata documents upto R4400 V3.0
      available so for the moment the code treats all R4000 and R4400 as broken.
      
      This is potencially a problem for some machines that have no other decent
      clocksource available; this workaround will cause them to fall back to
      another clocksource, worst case the "jiffies" source.
      5aa85c9f
  17. 03 11月, 2007 2 次提交
  18. 30 10月, 2007 1 次提交
  19. 23 10月, 2007 1 次提交
  20. 20 10月, 2007 2 次提交
  21. 19 10月, 2007 2 次提交
  22. 18 10月, 2007 1 次提交
  23. 17 10月, 2007 1 次提交
  24. 12 10月, 2007 7 次提交
  25. 15 9月, 2007 1 次提交
  26. 21 6月, 2007 1 次提交
  27. 15 6月, 2007 1 次提交
  28. 11 5月, 2007 1 次提交
  29. 17 2月, 2007 1 次提交