Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 19 2月, 2013 1 次提交
  3. 17 2月, 2013 4 次提交
  5. 14 12月, 2012 1 次提交
  7. 12 12月, 2012 1 次提交
  9. 11 10月, 2012 2 次提交
  11. 14 9月, 2012 2 次提交
  13. 08 12月, 2011 1 次提交
  15. 25 10月, 2011 1 次提交
  17. 31 3月, 2011 1 次提交
  19. 30 10月, 2010 1 次提交
  21. 05 8月, 2010 1 次提交
  23. 16 5月, 2010 1 次提交
    • S
      MIPS FPU emulator: allow Cause bits of FCSR to be writeable by ctc1 · 95e8f634
      由 Shane McDonald 提交于 
          
    In the FPU emulator code of the MIPS, the Cause bits of the FCSR register
    are not currently writeable by the ctc1 instruction.  In odd corner cases,
    this can cause problems.  For example, a case existed where a divide-by-zero
    exception was generated by the FPU, and the signal handler attempted to
    restore the FPU registers to their state before the exception occurred.  In
    this particular setup, writing the old value to the FCSR register would
    cause another divide-by-zero exception to occur immediately.  The solution
    is to change the ctc1 instruction emulator code to allow the Cause bits of
    the FCSR register to be writeable.  This is the behaviour of the hardware
    that the code is emulating.
    
    This problem was found by Shane McDonald, but the credit for the fix goes
    to Kevin Kissell.  In Kevin's words:
    
    I submit that the bug is indeed in that ctc_op:  case of the emulator.  The
    Cause bits (17:12) are supposed to be writable by that instruction, but the
    CTC1 emulation won't let them be updated by the instruction.  I think that
    actually if you just completely removed lines 387-388 [...] things would
    work a good deal better.  At least, it would be a more accurate emulation of
    the architecturally defined FPU.  If I wanted to be really, really pedantic
    (which I sometimes do), I'd also protect the reserved bits that aren't
    necessarily writable.
Signed-off-by: NShane McDonald <mcdonald.shane@gmail.com>
    To: anemo@mba.ocn.ne.jp
    To: kevink@paralogos.com
    To: sshtylyov@mvista.com
    Patchwork: http://patchwork.linux-mips.org/patch/1205/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

---
      95e8f634
  25. 27 2月, 2010 2 次提交
  27. 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
  29. 17 6月, 2009 1 次提交
  31. 14 5月, 2009 3 次提交
  33. 24 3月, 2009 1 次提交
  35. 11 1月, 2009 2 次提交
  37. 28 10月, 2008 1 次提交
  39. 11 10月, 2008 1 次提交
  41. 04 10月, 2008 1 次提交
  43. 06 6月, 2008 1 次提交
  45. 12 10月, 2007 1 次提交
  47. 13 7月, 2007 1 次提交
  49. 11 7月, 2007 2 次提交
  51. 06 7月, 2007 1 次提交
    • R
      [MIPS] Fix scheduling latency issue on 24K, 34K and 74K cores · 4b3e975e
      由 Ralf Baechle 提交于 
      The idle loop goes to sleep using the WAIT instruction if !need_resched().
This has is suffering from from a race condition that if if just after
need_resched has returned 0 an interrupt might set TIF_NEED_RESCHED but
we've just completed the test so go to sleep anyway.  This would be
trivial to fix by just disabling interrupts during that sequence as in:

        local_irq_disable();
        if (!need_resched())
                __asm__("wait");
        local_irq_enable();

but the processor architecture leaves it undefined if a processor calling
WAIT with interrupts disabled will ever restart its pipeline and indeed
some processors have made use of the freedom provided by the architecture
definition.  This has been resolved and the Config7.WII bit indicates that
the use of WAIT is safe on 24K, 24KE and 34K cores.  It also is safe on
74K starting revision 2.1.0 so enable the use of WAIT with interrupts
disabled for 74K based on a c0_prid of at least that.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      4b3e975e
  53. 30 11月, 2006 1 次提交
  55. 14 7月, 2006 3 次提交