1. 05 5月, 2008 3 次提交
    • J
      [POWERPC] spufs: fix save of mfc_cntl register · 1ca4264e
      Jeremy Kerr 提交于
      Currently, we can introduce invalid entries into the MFC queues:
      
      1) context starts a DMA
      
      2) context gets scheduled out during a DMA
        - kernel saves MFC queue to CSA
        - kernel saves 0x0 in csa->mfc_control_RW
      
      3) context gets scheduled in
        - csa->mfc_control[Q] ('queues empty') isn't set, so DMA queues are
          restored from the CSA
      
      4) context's DMA is completed
      
      5) context gets scheduled out again, no DMA occuring this time
        - kernel sees that MFC_CNTL[Q] ('queues empty') is set, so doesn't
          touch saved queue data in CSA
        - kernel saves 0x0 in csa->mfc_control_RW
      
      6) context gets scheduled in
        - csa->mfc_control[Q] ('queues empty') isn't set (we saved is as 0!),
          so DMA queues are restored from the CSA
      
      In this last restore, we've restored the queue status from step 2,
      which are now invalid.
      
      This change makes save_mfc_cntl() closer to the save/restore sequence,
      as specified in the CBE handbook.
      
      With changes from Luke Browning.
      Signed-off-by: NJeremy Kerr <jk@ozlabs.org>
      1ca4264e
    • J
      [POWERPC] spufs: don't touch suspend bits when purging DMA queue · 943906ba
      Jeremy Kerr 提交于
      When we issue a MFC purge request, we may inadvertantly clear the
      suspended status.
      
      This change adds the MFC_CNTL_SUSPEND_MASK when we issue a purge
      request, so that the suspend bit is masked out.
      Signed-off-by: NJeremy Kerr <jk@ozlabs.org>
      943906ba
    • J
      [POWERPC] cell: Fix lost interrupts due to fasteoi handler · 5711fe90
      Jeremy Kerr 提交于
      We may currently lose interrupts during SPE context switch, as we alter
      the INT_Route register. Because the IIC uses a per-thread priority
      status, changing the interrupt routing to a different thread means that
      the IRQ is no longer masked by the priority status, so we end up with
      two fasteoi IRQ handlers executing for the one irq_desc. The fasteoi
      handler doesn't handle multiple IRQs, so drops the second one.
      
      Fix this by using our own flow handler. This is based on
      handle_edge_irq, but issues an eoi after IRQs are handled, and doesn't
      do any mask/unmasking.
      Signed-off-by: NJeremy Kerr <jk@ozlabs.org>
      5711fe90
  2. 02 5月, 2008 13 次提交
  3. 30 4月, 2008 10 次提交
  4. 29 4月, 2008 14 次提交