1. 09 5月, 2013 1 次提交
  2. 01 2月, 2013 1 次提交
  3. 14 9月, 2012 1 次提交
  4. 08 12月, 2011 1 次提交
  5. 09 11月, 2011 1 次提交
    • A
      MIPS: Kernel hangs occasionally during boot. · 4f1a1eb5
      Al Cooper 提交于
      The Kernel hangs occasionally during boot after "Calibrating delay loop..".
      This is caused by the c0_compare_int_usable() routine in cevt-r4k.c
      returning false which causes the system to disable the timer and hang later.
      The false return happens because the routine is using a series of four calls
      to irq_disable_hazard() as a delay while it waits for the timer changes to
      propagate to the cp0 cause register. On newer MIPS cores, like the 74K, the
      series of irq_disable_hazard() calls turn into ehb instructions and can take
      as little as a few clock ticks for all 4 instructions. This is not enough of
      a delay, so the routine thinks the timer is not working.  This fix uses up
      to a max number of cycle counter ticks for the delay and uses
      back_to_back_c0_hazard() instead of irq_disable_hazard() to handle the
      hazard condition between cp0 writes and cp0 reads.
      Signed-off-by: NAl Cooper <alcooperx@gmail.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/2911/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      4f1a1eb5
  6. 17 12月, 2010 1 次提交
    • K
      MIPS: Fix CP0 COUNTER clockevent race · 5878fc93
      Kevin Cernekee 提交于
      Consider the following test case:
      
      write_c0_compare(read_c0_count());
      
      Even if the counter doesn't increment during execution, this might not
      generate an interrupt until the counter wraps around.  The CPU may
      perform the comparison each time CP0 COUNT increments, not when CP0
      COMPARE is written.
      
      If mips_next_event() is called with a very small delta, and CP0 COUNT
      increments during the calculation of "cnt += delta", it is possible
      that CP0 COMPARE will be written with the current value of CP0 COUNT.
      If this is detected, the function should return -ETIME, to indicate
      that the interrupt might not have actually gotten scheduled.
      Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/1836/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      5878fc93
  7. 07 10月, 2010 1 次提交
  8. 05 8月, 2010 1 次提交
  9. 28 1月, 2010 1 次提交
    • D
      MIPS: PowerTV: Fix support for timer interrupts with > 64 external IRQs · 010c108d
      David VomLehn 提交于
      The MIPS processor is limited to 64 external interrupt sources. Using a
      greater number without IRQ sharing requires reading platform-specific
      registers. On such platforms, reading the IntCtl register to determine
      which interrupt corresponds to a timer interrupt will not work.
      
      On MIPSR2 systems there is a solution - the TI bit in the Cause register,
      specifically indicates that a timer interrupt has occured. This patch uses
      that bit to detect interrupts for MIPSR2 processors, which may be expected
      to work regardless of how the timer interrupt may be routed in the hardware.
      
      Signed-off-by: David VomLehn (dvomlehn@cisco.com)
      To: linux-mips@linux-mips.org
      Patchwork: http://patchwork.linux-mips.org/patch/804/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      010c108d
  10. 02 11月, 2009 1 次提交
  11. 25 6月, 2009 1 次提交
  12. 11 1月, 2009 1 次提交
    • M
      MIPS: make cp0 counter clocksource/event usable as fallback. · 779e7d41
      Manuel Lauss 提交于
      The current mips clock build infrastructure lets a system only use
      either the MIPS cp0 counter or a SoC specific timer as a clocksource /
      clockevent device.
      
      This patch renames the core cp0 counter clocksource / clockevent functions
      from mips_* to r4k_* and updates the wrappers in asm-mips/time.h to
      call these renamed functions instead.
      
      Chips which can detect whether it is safe to use a chip-specific timer
      can now fall back on the cp0 counter if necessary and possible
      (e.g. Alchemy with a follow-on patch).
      
      Existing behaviour is not changed in any way.
      Signed-off-by: NManuel Lauss <mano@roarinelk.homelinux.net>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      779e7d41
  13. 13 12月, 2008 1 次提交
  14. 04 10月, 2008 1 次提交
  15. 27 11月, 2007 2 次提交
    • 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
    • R
      aea68639
  16. 30 10月, 2007 4 次提交
  17. 23 10月, 2007 1 次提交
  18. 20 10月, 2007 1 次提交
  19. 19 10月, 2007 1 次提交