1. 13 Mar, 2012 1 commit
    • Ben Skeggs's avatar
      drm/nv50: add memory type detection · 1072856a
      Ben Skeggs authored
      
      
      DDR1/DDR[23] confirmed on NVA8 (see note about DDR3 in source) by changing
      the value and watching the binary driver's behaviour.
      
      GDDR3/4 values confirmed on a NV96 via the same method above.  That GDDR4
      is present is interesting, as far as I can see no boards using it were ever
      released.
      
      GDDR5 value is based on VBIOS images of known GDDR5 boards.
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      1072856a
  2. 09 Nov, 2011 1 commit
  3. 20 Sep, 2011 1 commit
  4. 23 Jun, 2011 1 commit
    • Ben Skeggs's avatar
      drm/nouveau: rework vram init/fini ordering a little · 24f246ac
      Ben Skeggs authored
      
      
      Commit "drm/nouveau: add some debug output if nouveau_mm busy at destroy time"
      revealed an issue where vram mm takedown would actually fail due to there
      still being nodes present, causing nouveau to leak a small amount of memory
      on module unload.
      
      This splits TTM/nouveau_mm a bit more cleanly and ensures nouveau_mm fini
      isn't done until all gpuobjs are also destroyed.
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      24f246ac
  5. 24 Feb, 2011 2 commits
  6. 20 Dec, 2010 1 commit
  7. 07 Dec, 2010 2 commits
    • Ben Skeggs's avatar
      drm/nouveau: kick vram functions out into an "engine" · 60d2a88a
      Ben Skeggs authored
      
      
      NVC0 will be able to share some of nv50's paths this way.  This also makes
      it the card-specific vram code responsible for deciding if a given set
      of tile_flags is valid, rather than duplicating the allowed types in
      nv50_vram.c and nouveau_gem.c
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      60d2a88a
    • Ben Skeggs's avatar
      drm/nv50: implement custom vram mm · 573a2a37
      Ben Skeggs authored
      
      
      This is required on nv50 as we need to be able to have more precise control
      over physical VRAM allocations to avoid buffer corruption when using
      buffers of mixed memory types.
      
      This removes some nasty overallocation/alignment that we were previously
      using to "control" this problem.
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      573a2a37