1. 18 Jul, 2013 8 commits
  2. 17 Jul, 2013 5 commits
    • Ben Widawsky's avatar
      drm/i915: Free stolen node on failed preallocation · f7f18184
      Ben Widawsky authored
      The odds of this happening are *extremely* unlikely.
      Reported-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f7f18184
    • Ben Widawsky's avatar
      drm/i915: Move active/inactive lists to new mm · 5cef07e1
      Ben Widawsky authored
      Shamelessly manipulated out of Daniel :-)
      "When moving the lists around explain that the active/inactive stuff is
      used by eviction when we run out of address space, so needs to be
      per-vma and per-address space. Bound/unbound otoh is used by the
      shrinker which only cares about the amount of memory used and not one
      bit about in which address space this memory is all used in. Of course
      to actual kick out an object we need to unbind it from every address
      space, but for that we have the per-object list of vmas."
      
      v2: Leave the bound list as a global one. (Chris, indirectly)
      
      v3: Rebased with no i915_gtt_vm. In most places I added a new *vm local,
      since it will eventually be replaces by a vm argument.
      Put comment back inline, since it no longer makes sense to do otherwise.
      
      v4: Rebased on hangcheck/error state movement
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      5cef07e1
    • Ben Widawsky's avatar
      drm/i915: Create a global list of vms · a7bbbd63
      Ben Widawsky authored
      After we plumb our code to support multiple address spaces (VMs), there
      are a few situations where we want to be able to traverse the list of
      all address spaces in the system. Cases like eviction, or error state
      collection are obvious example.
      
      v2: Delete the global link instead of the list head. While this in and
      of itself shouldn't be really be a problem, doing this allows us to WARN
      on an non-empty list, which is a problem. (Daniel)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a7bbbd63
    • Ben Widawsky's avatar
      drm/i915: Put the mm in the parent address space · 93bd8649
      Ben Widawsky authored
      Every address space should support object allocation. It therefore makes
      sense to have the allocator be part of the "superclass" which GGTT and
      PPGTT will derive.
      
      Since our maximum address space size is only 2GB we're not yet able to
      avoid doing allocation/eviction; but we'd hope one day this becomes
      almost irrelvant.
      
      v2: Rebased
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      93bd8649
    • Ben Widawsky's avatar
      drm/i915: Move gtt and ppgtt under address space umbrella · 853ba5d2
      Ben Widawsky authored
      The GTT and PPGTT can be thought of more generally as GPU address
      spaces. Many of their actions (insert entries), state (LRU lists), and
      many of their characteristics (size) can be shared. Do that.
      
      The change itself doesn't actually impact most of the VMA/VM rework
      coming up, it just fits in with the grand scheme of abstracting the GPU
      VM operations. GGTT will usually be a special case where we either know
      an object must be in the GGTT (dislay engine, workarounds, etc.).
      
      The scratch page is left as part of the VM (even though it's currently
      shared with the ppgtt code) because in the future when we have Full
      PPGTT, I intend to create a separate scratch page for each.
      
      v2: Drop usage of i915_gtt_vm (Daniel)
      Make cleanup also part of the parent class (Ben)
      Modified commit msg
      Rebased
      
      v3: Properly share scratch page (Imre)
      Finish commit message (Daniel, Imre)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      853ba5d2
  3. 16 Jul, 2013 17 commits
  4. 12 Jul, 2013 5 commits
  5. 11 Jul, 2013 5 commits