1. 06 5月, 2008 1 次提交
  2. 05 5月, 2008 10 次提交
    • L
      [POWERPC] spufs: handle faults while the context switch pending flag is set · de102892
      Luke Browning 提交于
      Currently, page fault handlers don't issue a mfc restart if the context
      switch pending flag is set, which can leave us with a hanging DMA after
      a context restore.
      
      This patch introduces fault pending flag that is set by the fault
      handler and read by the context switch code, so that the latter can add
      the restart bit at the right spot, after it has successfuly saved the
      state of the mfc control register.
      Signed-off-by: NLuke Browning <lukebr@linux.vnet.ibm.com>
      Signed-off-by: NJeremy Kerr <jk@ozlabs.org>
      de102892
    • L
      [POWERPC] spufs: fix concurrent delivery of class 0 & 1 exceptions · f3d69e05
      Luke Browning 提交于
      SPU class 0 & 1 exceptions may occur in parallel, so we may end up
      overwriting csa.dsisr.
      
      This change adds dedicated fields for each class to the spu and the spu
      context so that fault data is not overwritten.
      Signed-off-by: NLuke Browning <lukebr@linux.vnet.ibm.com>
      Signed-off-by: NJeremy Kerr <jk@ozlabs.org>
      f3d69e05
    • L
      [POWERPC] spufs: try to route SPU interrupts to local node · 7a214200
      Luke Browning 提交于
      Currently, we re-route SPU interrupts to the current cpu, which may be
      on a remote node. In the case of time slicing, all spu interrupts will
      end up routed to the same cpu, where the spusched_tick occurs.
      
      This change routes mfc interrupts to the cpu where the controlling
      thread last ran, provided that cpu is on the same node as the spu
      (otherwise don't reroute interrupts).
      
      This should improve performance and provide a more predictable
      environment for processing spu exceptions. In the past we have seen
      concurrent delivery of spu exceptions to two cpus. This eliminates that
      concern.
      Signed-off-by: NLuke Browning <lukebr@linux.vnet.ibm.com>
      Signed-off-by: NJeremy Kerr <jk@ozlabs.org>
      7a214200
    • L
      [POWERPC] spufs: set SPU_CONTEXT_SWITCH_PENDING before synchronising SPU irqs · 093c16bf
      Luke Browning 提交于
      synchronize_irq() provides the serialization for
      SPU_CONTEXT_SWITCH_PENDING which is read with a simple load. This
      routine guarantees that the relevant interrupt handlers are not running,
      so that the next time they do run they will see the update
      memory value.
      
      This must be done correctly so that exception handling code does not
      restart the mfc in the middle of a context switch while we are trying
      to atomically stop it and save state.
      Signed-off-by: NLuke Browning <lukebr@linux.vnet.ibm.com>
      Signed-off-by: NJeremy Kerr <jk@ozlabs.org>
      093c16bf
    • J
      [POWERPC] spufs: don't acquire state_mutex interruptible while performing callback · d29694f0
      Jeremy Kerr 提交于
      There's currently no way to tell if spu_process_callback has
      returned with the state mutex held, as -EINTR may be returned
      by either the syscall or the spu_acquire fail case.
      
      Instead, just do a non-interruptible mutex_lock here.
      Signed-off-by: NJeremy Kerr <jk@ozlabs.org>
      d29694f0
    • J
      [POWERPC] spufs: update master runcntl with context lock held · c0bace5c
      Jeremy Kerr 提交于
      Currently, we update the SPU master run control bit (ie,
      spu_enable_spu) in spufs_run_spu before we grab the context mutex. This
      can result in races with other processes accessing this context's
      resources.
      
      This change moves the spu_enable_spu to after we have acquired the
      context lock.
      Signed-off-by: NJeremy Kerr <jk@ozlabs.org>
      c0bace5c
    • J
      [POWERPC] spufs: fix post-stopped update of MFC_CNTL register · 55d7cd74
      Jeremy Kerr 提交于
      We currently have two issues with the MFC save code:
      
       * save_mfc_decr doesn't handle a transition of 1 -> 0 of the Ds bit
       * The Q bit may be stale in the CSA
      
      This change fixes the first issue by clearing the relevant bits from
      the MFC_CNTL value in the CSA before or-ing in the updated status.
      Also, we add the Q bit to the updated status.
      Signed-off-by: NJeremy Kerr <jk@ozlabs.org>
      55d7cd74
    • 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
  3. 02 5月, 2008 13 次提交
  4. 30 4月, 2008 10 次提交
  5. 29 4月, 2008 6 次提交