1. 31 Jan, 2010 4 commits
  2. 24 Jan, 2010 18 commits
  3. 20 Jan, 2010 14 commits
  4. 17 Jan, 2010 4 commits
    • Ben Skeggs's avatar
      drm/nv50: prevent accidently turning off encoders we're actually using · 58d65b84
      Ben Skeggs authored
      
      
      On most cards the DisplayPort connector is created with 2 encoders sharing
      a single SOR (for native DP, and for DVI-over-DP).  The previous logic
      for turning off unused encoders didn't take into account that we could
      have multiple drm_encoders on a single hw encoder and ended up turning off
      encoders that were actually being used still.
      
      This patch fixes that issue.  We probably want to look at something a bit
      better later on, and only expose one drm_encoder per hw encoder block.
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      58d65b84
    • Ben Skeggs's avatar
      drm/nv50: fix alignment of per-channel fifo cache · 134f248b
      Ben Skeggs authored
      
      
      GPU pointer to the structure is shifted right by 10 bits, so we need to
      align to 1024 bytes, not 256.
      Reported-by: default avatarMaarten Maathuis <madman2003@gmail.com>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      134f248b
    • Luca Barbieri's avatar
      drm/nouveau: Evict buffers in VRAM before freeing sgdma · 71666475
      Luca Barbieri authored
      
      
      Currently, we take down the sgdma engine without evicting all buffers
      from VRAM.
      
      The TTM device release will try to evict anything in VRAM to GART
      memory, but this will fail since sgdma has already been taken down.
      
      This causes an infinite loop in kernel mode on module unload.
      It usually doesn't happen because there aren't any buffer on close.
      However, if the GPU is locked up, this condition is easily triggered.
      
      This patch fixes it in the simplest way possible by cleaning VRAM
      right before cleaning SGDMA memory.
      Signed-off-by: default avatarLuca Barbieri <luca@luca-barbieri.com>
      Signed-off-by: default avatarFrancisco Jerez <currojerez@riseup.net>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      71666475
    • Luca Barbieri's avatar
      drm/nouveau: Acknowledge DMA_VTX_PROTECTION PGRAPH interrupts · d051bbb2
      Luca Barbieri authored
      
      
      Currently Nouveau is unable to dismiss DMA_VTX_PROTECTION errors,
      which results in an infinite loop in the interrupt handler.
      
      These errors are caused both by bugs in the Gallium driver and by
      user-specified index buffers with out of bounds indices.
      
      By mmio-tracing the nVidia drivers, I found out how this is done.
      On DMA_VTX_PROTECTION, The nVidia driver reads the register 0x402000,
      always getting the value 4, and then writes 4 back to 0x402000.
      
      This patch adds that logic by reading 0x402000 and writing the same
      value back.
      It's unclear what should happen if the value read is not 4, and
      the current approach might not be the correct one.
      
      To test this, modify mesa/progs/trivial/vbo-drawrange.c, defining
      ELTOBJ to 1 and replacing indices with huge out of bounds integers.
      
      Without this patch, the GPU and/or kernel should lock up.
      With this patch, it should misrender as expected but not lock up.
      
      The errors are still logged since they are useful for development.
      
      This has been tested on NV49 and may not work on other cards.
      
      To find out how things work on other cards, run the aforementioned
      test using the blob with mmiotrace and grep for a read of the PGRAPH
      source register.
      Signed-off-by: default avatarLuca Barbieri <luca@luca-barbieri.com>
      Signed-off-by: default avatarFrancisco Jerez <currojerez@riseup.net>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      d051bbb2