1. 24 7月, 2013 1 次提交
  2. 19 7月, 2013 1 次提交
  3. 18 7月, 2013 4 次提交
    • B
      drm/i915: Create VMAs · 2f633156
      Ben Widawsky 提交于
      Formerly: "drm/i915: Create VMAs (part 1)"
      
      In a previous patch, the notion of a VM was introduced. A VMA describes
      an area of part of the VM address space. A VMA is similar to the concept
      in the linux mm. However, instead of representing regular memory, a VMA
      is backed by a GEM BO. There may be many VMAs for a given object, one
      for each VM the object is to be used in. This may occur through flink,
      dma-buf, or a number of other transient states.
      
      Currently the code depends on only 1 VMA per object, for the global GTT
      (and aliasing PPGTT). The following patches will address this and make
      the rest of the infrastructure more suited
      
      v2: s/i915_obj/i915_gem_obj (Chris)
      
      v3: Only move an object to the now global unbound list if there are no
      more VMAs for the object which are bound into a VM (ie. the list is
      empty).
      
      v4: killed obj->gtt_space
      some reworks due to rebase
      
      v5: Free vma on error path (Imre)
      
      v6: Another missed vma free in i915_gem_object_bind_to_gtt error path
      (Imre)
      Fixed vma freeing in stolen preallocation (Imre)
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      [danvet: Squash in fixup from Ben to not deref a non-existing vma in
      set_cache_level, reported by Chris.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      2f633156
    • B
      drm/i915: Free stolen node on failed preallocation · f7f18184
      Ben Widawsky 提交于
      The odds of this happening are *extremely* unlikely.
      Reported-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f7f18184
    • B
      drm/i915: Move active/inactive lists to new mm · 5cef07e1
      Ben Widawsky 提交于
      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: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5cef07e1
    • B
      drm/i915: Put the mm in the parent address space · 93bd8649
      Ben Widawsky 提交于
      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: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      93bd8649
  4. 09 7月, 2013 6 次提交
    • D
      drm/i915: WARN if the bios reserved range is bigger than stolen size · 897f9ed0
      Daniel Vetter 提交于
      v2: Bail out if we hit the WARN_ON to avoid fallout later on. Spotted
      by Chris Wilson.
      Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      897f9ed0
    • C
      drm/i915: Verify that our stolen memory doesn't conflict · eaba1b8f
      Chris Wilson 提交于
      Sanity check that the memory region found through the Graphics Base
      of Stolen Memory is reserved and hidden from the rest of the system
      through the use of the resource API.
      
      v2: "Graphics Stolen Memory" is such a more bodacious name than the lame
          "i915 stolen", and convert to using devres for automagical cleanup of
          the resource. (danvet)
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      [danvet: Dump proper hexcodes.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      eaba1b8f
    • B
      drm/i915: Embed drm_mm_node in i915 gem obj · c6cfb325
      Ben Widawsky 提交于
      Embedding the node in the obj is more natural in the transition to VMAs
      which will also have embedded nodes. This change also helps transition
      away from put_block to remove node.
      
      Though it's quite an uncommon occurrence, it's somewhat convenient to not
      fail at bind time because we cannot allocate the node. Though in
      practice there are other allocations (like the request structure) which
      would probably make this point not terribly useful.
      
      Quoting Daniel:
      Note that the only difference between put_block and remove_node is
      that the former fills up the preallocation cache. Which we don't need
      anyway and hence is just wasted space.
      
      v2: Clean up the stolen preallocation code.
      Rebased on the reserve_node patches
      renames ggtt_ stuff to gtt_ stuff
      WARN_ON if the object is already bound (which doesn't mean it's in the
      bound list, tricky)
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c6cfb325
    • B
      drm/i915: Kill obj->gtt_offset · edd41a87
      Ben Widawsky 提交于
      With the getters in place from the previous patch this members serves no
      purpose other than saving one spare pointer chase, which will be killed
      in the next patch anyway.
      
      Moving to VMAs, this members adds unnecessary confusion since an object
      may exist at different offsets in different VMs.
      
      v2: Properly preserve the stolen offset. This code is a bit hacky but it
      all goes away when we embed the drm_mm_node and removes the need for the
      incorrect patch I submitted previously: "Use gtt_space->start for stolen
      reservation"
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      edd41a87
    • B
      drm: Change create block to reserve node · 338710e7
      Ben Widawsky 提交于
      With the previous patch we no longer actually create a node, we simply
      find the correct hole and occupy it. This very well could have been
      squashed with the last patch, but since I already had David's review, I
      figured it's easiest to keep it distinct.
      
      Also update the users in i915. Conveniently this is the only user of the
      interface.
      
      CC: David Airlie <airlied@linux.ie>
      CC: <dri-devel@lists.freedesktop.org>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Acked-by: NDavid Airlie <airlied@linux.ie>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      338710e7
    • B
      drm: pre allocate node for create_block · b3a070cc
      Ben Widawsky 提交于
      For an upcoming patch where we introduce the i915 VMA, it's ideal to
      have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
      Part of the conversion to VMAs is to kill off obj->gtt_space. Doing this
      will break a bunch of code, but amongst them are 2 callers of
      drm_mm_create_block(), both related to stolen memory.
      
      It also allows us to embed the drm_mm_node into the object currently
      which provides a nice transition over to the new code.
      
      v2: Reordered to do before ripping out obj->gtt_offset.
      Some minor cleanups made available because of reordering.
      
      v3: s/continue/break on failed stolen node allocation (David)
      Set obj->gtt_space on failed node allocation (David)
      Only unref stolen (fix double free) on failed create_stolen (David)
      Free node, and NULL it in failed create_stolen (David)
      Add back accidentally removed newline (David)
      
      CC: <dri-devel@lists.freedesktop.org>
      Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Acked-by: NDavid Airlie <airlied@linux.ie>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      b3a070cc
  5. 06 7月, 2013 1 次提交
    • D
      drm/i915: less magic for stolen preallocated objects w/o gtt offset · 190d6cd5
      Daniel Vetter 提交于
      A magic -1 is a obscure, especially since it's actually passed as an
      unsigned, so depends upon the magic sign extension rules in C. This has
      been added in
      
      commit 3727d55e
      Author: Jesse Barnes <jbarnes@virtuousgeek.org>
      Date:   Wed May 8 10:45:14 2013 -0700
      
          drm/i915: allow stolen, pre-allocated objects to avoid GTT allocation v2
      
      Use a proper #define instead. Spotted while reviewing Ben's
      drm_mm_create_block changes.
      
      v2: Cast the constant to u32 since otherwise we again have a type
      mismatch. Suggested by Chris Wilson.
      
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      190d6cd5
  6. 01 7月, 2013 1 次提交
  7. 03 6月, 2013 2 次提交
  8. 11 5月, 2013 2 次提交
  9. 27 4月, 2013 1 次提交
  10. 28 3月, 2013 1 次提交
  11. 27 3月, 2013 1 次提交
  12. 23 3月, 2013 1 次提交
    • I
      drm/i915: set dummy page for stolen objects · 5bd4687e
      Imre Deak 提交于
      This is needed since currently sg_for_each_page assumes that we have
      a valid page in each sg item. It is only a real problem for
      CONFIG_SPARSEMEM where the page is dereferenced, in other cases the
      iterator works ok with an invalid page pointer.
      
      We can remove this workaround when we have fixed sg_page_iter to work on
      scatterlists without backing pages.
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      5bd4687e
  13. 31 1月, 2013 1 次提交
  14. 18 12月, 2012 1 次提交
    • D
      drm/i915: fixup overlay stolen memory leak · 4d7bb011
      Daniel Vetter 提交于
      We need to clean up the overlay first, before taking down the
      stolen memory allocator.
      
      This regression has been introducec in
      
      commit 80405138
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Thu Nov 15 11:32:29 2012 +0000
      
          drm/i915: Allocate overlay registers from stolen memory
      
      v2: Rework the patch a bit as suggested by Chris Wilson:
      - move the overlay teardown up, into the modeset cleanup
      - move the stolen mm takedown into i915_gem_cleanup_stolen
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      4d7bb011
  15. 01 12月, 2012 4 次提交
    • C
      drm/i915: Use a slab for object allocation · 42dcedd4
      Chris Wilson 提交于
      The primary purpose of this was to debug some use-after-free memory
      corruption that was causing an OOPS inside drm/i915. As it turned out
      the corruption was being caused elsewhere and i915.ko as a major user of
      many objects was being hit hardest.
      
      Indeed as we do frequent the generic kmalloc caches, dedicating one to
      ourselves (or at least naming one for us depending upon the core) aids
      debugging our own slab usage.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      42dcedd4
    • C
      drm/i915: Introduce i915_gem_object_create_stolen() · 0104fdbb
      Chris Wilson 提交于
      Allow for the creation of GEM objects backed by stolen memory. As these
      are not backed by ordinary pages, we create a fake dma mapping and store
      the address in the scatterlist rather than obj->pages.
      
      v2: Mark _i915_gem_object_create_stolen() as static, as noticed by Jesse
      Barnes.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0104fdbb
    • C
      drm/i915: Delay allocation of stolen space for FBC · 11be49eb
      Chris Wilson 提交于
      As FBC is commonly disabled due to limitations of the chipset upon
      output configurations, on many systems FBC is never enabled. For those
      systems, it is advantageous to make use of the stolen memory for other
      objects and so we defer allocation of the FBC chunk until we actually
      require it. This increases the likelihood of that allocation failing,
      but that in turns means that we are already taking advantage of the
      stolen memory!
      
      As well as delaying the allocation from driver initialisation until the
      first use of FBC, we also return the stolen block after we finish using
      it - allowing greater flexibility in our usage of stolen space. A side
      effect of this is that we can then attempt to allocate only the required
      amount of space (with a little slack to reduce reallocation rate and
      avoid fragmentation).
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      11be49eb
    • C
      drm/i915: Fix detection of base of stolen memory · e12a2d53
      Chris Wilson 提交于
      The routine to query the base of stolen memory was using the wrong
      registers and the wrong encodings on virtually every platform.
      
      It was not until the G33 refresh, that a PCI config register was
      introduced that explicitly said where the stolen memory was. Prior to
      865G there was not even a register that said where the end of usable
      low memory was and where the stolen memory began (or ended depending
      upon chipset). Before then, one has to look at the BIOS memory maps to
      find the Top of Memory. Alas that is not exported by arch/x86 and so we
      have to resort to disabling stolen memory on gen2 for the time being.
      
      Then SandyBridge enlarged the PCI register to a full 32-bits and change
      the encoding of the address, so even though we happened to be querying
      the right register, we read the wrong bits and ended up using address 0
      for our stolen data, i.e. notably FBC.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e12a2d53
  16. 03 10月, 2012 2 次提交
  17. 03 5月, 2012 1 次提交