1. 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
  2. 07 10月, 2010 1 次提交
  3. 05 8月, 2010 1 次提交
  4. 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
  5. 02 11月, 2009 1 次提交
  6. 25 6月, 2009 1 次提交
  7. 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
  8. 13 12月, 2008 1 次提交
  9. 04 10月, 2008 1 次提交
  10. 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
  11. 30 10月, 2007 4 次提交
  12. 23 10月, 2007 1 次提交
  13. 20 10月, 2007 1 次提交
  14. 19 10月, 2007 1 次提交