1. 07 8月, 2014 1 次提交
  2. 11 7月, 2014 1 次提交
  3. 17 6月, 2014 1 次提交
    • A
      drm/i915: Added write-enable pte bit supportt · 24f3a8cf
      Akash Goel 提交于
      This adds support for a write-enable bit in the entry of GTT.
      This is handled via a read-only flag in the GEM buffer object which
      is then used to see how to set the bit when writing the GTT entries.
      Currently by default the Batch buffer & Ring buffers are marked as read only.
      
      v2: Moved the pte override code for read-only bit to 'byt_pte_encode'. (Chris)
          Fixed the issue of leaving 'gt_old_ro' as unused. (Chris)
      
      v3: Removed the 'gt_old_ro' field, now setting RO bit only for Ring Buffers(Daniel).
      
      v4: Added a new 'flags' parameter to all the pte(gen6) encode & insert_entries functions,
          in lieu of overloading the cache_level enum (Daniel).
      
      v5: Removed the superfluous VLV check & changed the definition location of PTE_READ_ONLY flag (Imre)
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NAkash Goel <akash.goel@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      24f3a8cf
  4. 14 6月, 2014 1 次提交
  5. 07 6月, 2014 1 次提交
  6. 05 6月, 2014 1 次提交
  7. 27 5月, 2014 1 次提交
    • C
      drm/i915: Prevent negative relocation deltas from wrapping · d23db88c
      Chris Wilson 提交于
      This is pure evil. Userspace, I'm looking at you SNA, repacks batch
      buffers on the fly after generation as they are being passed to the
      kernel for execution. These batches also contain self-referenced
      relocations as a single buffer encompasses the state commands, kernels,
      vertices and sampler. During generation the buffers are placed at known
      offsets within the full batch, and then the relocation deltas (as passed
      to the kernel) are tweaked as the batch is repacked into a smaller buffer.
      This means that userspace is passing negative relocations deltas, which
      subsequently wrap to large values if the batch is at a low address. The
      GPU hangs when it then tries to use the large value as a base for its
      address offsets, rather than wrapping back to the real value (as one
      would hope). As the GPU uses positive offsets from the base, we can
      treat the relocation address as the minimum address read by the GPU.
      For the upper bound, we trust that userspace will not read beyond the
      end of the buffer.
      
      So, how do we fix negative relocations from wrapping? We can either
      check that every relocation looks valid when we write it, and then
      position each object such that we prevent the offset wraparound, or we
      just special-case the self-referential behaviour of SNA and force all
      batches to be above 256k. Daniel prefers the latter approach.
      
      This fixes a GPU hang when it tries to use an address (relocation +
      offset) greater than the GTT size. The issue would occur quite easily
      with full-ppgtt as each fd gets its own VM space, so low offsets would
      often be handed out. However, with the rearrangement of the low GTT due
      to capturing the BIOS framebuffer, it is already affecting kernels 3.15
      onwards. I think only IVB+ is susceptible to this bug, but the workaround
      should only kick in rarely, so it seems sensible to always apply it.
      
      v3: Use a bias for batch buffers to prevent small negative delta relocations
      from wrapping.
      
      v4 from Daniel:
      - s/BIAS/BATCH_OFFSET_BIAS/
      - Extract eb_vma_misplaced/i915_vma_misplaced since the conditions
        were growing rather cumbersome.
      - Add a comment to eb_get_batch explaining why we do this.
      - Apply the batch offset bias everywhere but mention that we've only
        observed it on gen7 gpus.
      - Drop PIN_OFFSET_FIX for now, that slipped in from a feature patch.
      
      v5: Add static to eb_get_batch, spotted by 0-day tester.
      
      Testcase: igt/gem_bad_reloc
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78533
      Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v3)
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d23db88c
  8. 23 5月, 2014 1 次提交
  9. 13 5月, 2014 1 次提交
  10. 07 5月, 2014 3 次提交
  11. 05 5月, 2014 1 次提交
  12. 29 4月, 2014 1 次提交
  13. 24 4月, 2014 1 次提交
  14. 04 4月, 2014 1 次提交
    • L
      drm: Add support for two-ended allocation, v3 · 62347f9e
      Lauri Kasanen 提交于
      Clients like i915 need to segregate cache domains within the GTT which
      can lead to small amounts of fragmentation. By allocating the uncached
      buffers from the bottom and the cacheable buffers from the top, we can
      reduce the amount of wasted space and also optimize allocation of the
      mappable portion of the GTT to only those buffers that require CPU
      access through the GTT.
      
      For other drivers, allocating small bos from one end and large ones
      from the other helps improve the quality of fragmentation.
      
      Based on drm_mm work by Chris Wilson.
      
      v3: Changed to use a TTM placement flag
      v2: Updated kerneldoc
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Cc: Christian König <deathsimple@vodafone.de>
      Signed-off-by: NLauri Kasanen <cand@gmx.com>
      Signed-off-by: NDavid Airlie <airlied@redhat.com>
      62347f9e
  15. 03 4月, 2014 1 次提交
  16. 02 4月, 2014 2 次提交
    • B
      drm/i915: Allow full PPGTT with param override · 8d214b7d
      Ben Widawsky 提交于
      When PPGTT was disabled by default, the patch also prevented the user
      from overriding this behavior via module parameter. Being able to test
      this on arbitrary kernels is extremely beneficial to track down the
      remaining bugs. The patch that prevented this was:
      
      commit 93a25a9e
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Thu Mar 6 09:40:43 2014 +0100
      
          drm/i915: Disable full ppgtt by default
      
      By default PPGTT is set to -1. 0 means off, 1 means aliasing only, 2
      means full, all other values are reserved.
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      8d214b7d
    • B
      drm/i915: Split out GTT specific header file · 0260c420
      Ben Widawsky 提交于
      This file contains all necessary defines, prototypes and typesdefs for
      manipulating GEN graphics address translation (this does not include the
      legacy AGP driver)
      
      Reiterating the comment in the header,
      "Please try to maintain the following order within this file unless it
      makes sense to do otherwise. From top to bottom:
      1. typedefs
      2. #defines, and macros
      3. structure definitions
      4. function prototypes
      
      Within each section, please try to order by generation in ascending
      order, from top to bottom (ie. GEN6 on the top, GEN8 on the bottom)."
      
      I've made some minor cleanups, and fixed a couple of typos while here -
      but there should be no functional changes.
      
      The purpose of the patch is to reduce clutter in our main header file,
      making room for new growth, and make documentation of our interfaces
      easier by splitting things out.
      
      With a little more work, like making i915_gtt a pointer, we could
      potentially completely isolate this header from i915_drv.h. At the
      moment however, I don't think it's worth the effort.
      
      Personally, I would have liked to put the PTE encoding functions in this
      file too, but I didn't want to rock the boat too much.
      
      A similar patch has been in use on my machine for some time. This exact
      patch though has only been compile tested.
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0260c420
  17. 31 3月, 2014 1 次提交
  18. 29 3月, 2014 1 次提交
  19. 28 3月, 2014 1 次提交
  20. 19 3月, 2014 1 次提交
  21. 13 3月, 2014 1 次提交
  22. 12 3月, 2014 2 次提交
  23. 08 3月, 2014 1 次提交
    • D
      drm/i915: Disable full ppgtt by default · 93a25a9e
      Daniel Vetter 提交于
      There are too many oustanding issues:
      
      - Fence handling in the current code is broken. There's a patch series
        from me, but it's blocked on and extended review (which includes
        writing the testcases).
      
      - IOMMU mapping handling is broken, we need to properly refcount it -
        currently it gets destroyed when the first vma is unbound, so way
        too early.
      
      - There's a pending reset issue on snb. Since Mika's reset work and
        full ppgtt have been pulled in in separate branches and ended up
        intermittingly breaking each another it's unclear who's the exact
        culprit here.
      
      - We still have persistent evidince of crazy recursion bugs through
        vma_unbind and ppgtt_relase, e.g.
      
        https://bugs.freedesktop.org/show_bug.cgi?id=73383
      
        This issue (and a few others meanwhile resolved) have blocked our
        performance measuring/tuning group since 3 months.
      
      - Secure batch dispatching is broken. This is blocking Brad Volkin's
        command checker work since 3 months.
      
      All these issues are confirmed to only happen when full ppgtt is
      enabled, falling back to aliasing ppgtt resolves them. But even
      aliasing ppgtt itself still has a regression:
      
      - We currently unconditionally bind objects into the aliasing ppgtt,
        which means all priviledged objects like ringbuffers are visible to
        unpriviledged access again. On top of that this also breaks the
        command checker for aliasing ppgtt, since it can't hide the
        validated batch any more.
      
      Furthermore topic/full-ppgtt has never been reviewed:
      
      - Lifetime rules around vma unbinding/release are unclear, resulting
        into this awesome hack called ppgtt_release. Which seems to take the
        blame for most of the recursion fallout.
      
      - Context/ring init works different on gpu reset than anywhere else.
        Such differeneces have in the past always lead to really hard to
        track down bugs.
      
      - Aliasing ppgtt is treated in a bunch of places as a real address
        space, but it isn't - the real address space is always the global
        gtt in that case. This results in a bit a mess between contexts and
        ppgtt object, further complication the context/ppgtt/vma lifetime
        rules.
      
      - We don't have any docs describing the overall concepts introduced
        with full ppgtt. A short, concise overview describing vmas and some
        of the strange bits around them (like the unbound vmas used by
        execbuf, or the new binding rules) really is needed.
      
      Note that a lot of the post topic/full-ppgtt merge fallout has already
      been addressed, this entire list here of 10 issues really only contains
      the still outstanding issues.
      
      Finally the 3.15 merge window is approaching and I think we need to
      use the remaining time to ensure that our fallback option of using
      aliasing ppgtt is in solid shape. Hence I think it's time to throw the
      switch. While at it demote the helper from static inline status
      because really.
      
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Cc: Dave Airlie <airlied@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      93a25a9e
  24. 06 3月, 2014 6 次提交
    • B
      drm/i915/bdw: Kill ppgtt->num_pt_pages · 5abbcca3
      Ben Widawsky 提交于
      With the original PPGTT implementation if the number of PDPs was not a
      power of two, the number of pages for the page tables would end up being
      rounded up. The code actually had a bug here afaict, but this is a
      theoretical bug as I don't believe this can actually occur with the
      current code/HW..
      
      With the rework of the page table allocations, there is no longer a
      distinction between number of page table pages, and number of page
      directory entries. To avoid confusion, kill the redundant (and newer)
      struct member.
      
      Cc: Imre Deak <imre.deak@intel.com>
      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>
      5abbcca3
    • B
      drm/i915: Split GEN6 PPGTT initialization up · b146520f
      Ben Widawsky 提交于
      Simply to match the GEN8 style of PPGTT initialization, split up the
      allocations and mappings. Unlike GEN8, we skip a separate dma_addr_t
      allocation function, as it is much simpler pre-gen8.
      
      With this code it would be easy to make a more general PPGTT
      initialization function with per GEN alloc/map/etc. or use a common
      helper, similar to the ringbuffer code. I don't see a benefit to doing
      this just yet, but who knows...
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      b146520f
    • B
      drm/i915: Split GEN6 PPGTT cleanup · a00d825d
      Ben Widawsky 提交于
      This cleanup is similar to the GEN8 cleanup (though less necessary).
      Having everything split will make cleaning the initialization path error
      paths easier to understand.
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a00d825d
    • B
      drm/i915: Update i915_gem_gtt.c copyright · c4ac524c
      Ben Widawsky 提交于
      I keep meaning to do this... by now almost the entire file has been
      written by an Intel employee (including Daniel post-2010).
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c4ac524c
    • B
      Revert "drm/i915/bdw: Limit GTT to 2GB" · 7907f45b
      Ben Widawsky 提交于
      This reverts commit 3a2ffb65.
      
      Now that the code is fixed to use smaller allocations, it should be safe
      to let the full GGTT be used on BDW.
      
      The testcase for this is anything which uses more than half of the GTT,
      thus eclipsing the old limit.
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7907f45b
    • B
      drm/i915/bdw: Reorganize PT allocations · 7ad47cf2
      Ben Widawsky 提交于
      The previous allocation mechanism would get 2 contiguous allocations,
      one for the page directories, and one for the page tables. As each page
      table is 1 page, and there are 512 of these per page directory, this
      goes to 2MB. An unfriendly request at best. Worse still, our HW now
      supports 4 page directories, and a 2MB allocation is not allowed.
      
      In order to fix this, this patch attempts to split up each page table
      allocation into a single, discrete allocation. There is nothing really
      fancy about the patch itself, it just has to manage an extra pointer
      indirection, and have a fancier bit of logic to free up the pages.
      
      To accommodate some of the added complexity, two new helpers are
      introduced to allocate, and free the page table pages.
      
      NOTE: I really wanted to split the way we do allocations, and the way in
      which we identify the page table/page directory being used. I found
      splitting this functionality up to be too unwieldy. I apologize in
      advance to the reviewer. I'd recommend looking at the result, rather
      than the diff.
      
      v2/NOTE2: This patch predated commit:
      6f1cc993
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Tue Dec 31 15:50:31 2013 +0000
      
          drm/i915: Avoid dereference past end of page arr
      
      It fixed the same issue as that patch, but because of the limbo state of
      PPGTT, Chris patch was merged instead. The excess churn is a result of
      my using my original patch, which has my preferred naming. Primarily
      act_* is changed to which_*, but it's mostly the same otherwise. I've
      kept the convention Chris used for the pte wrap (I had something
      slightly different, and broken - but fixable)
      
      v3: Rename which_p[..]e to drop which_ (Chris)
      Remove BUG_ON in inner loop (Chris)
      Redo the pde/pdpe wrap logic (Chris)
      
      v4: s/1MB/2MB in commit message (Imre)
      Plug leaking gen8_pt_pages in both the error path, as well as general
      free case (Imre)
      
      v5: Rename leftover "which_" variables (Imre)
      Add the pde = 0 wrap that was missed from v3 (Imre)
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      [danvet: Squash in fixup from Ben.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7ad47cf2
  25. 04 3月, 2014 4 次提交
    • B
      drm/i915: Make clear/insert vfuncs args absolute · 782f1495
      Ben Widawsky 提交于
      This patch converts insert_entries and clear_range, both functions which
      are specific to the VM. These functions tend to encapsulate the gen
      specific PTE writes. Passing absolute addresses to the insert_entries,
      and clear_range will help make the logic clearer within the functions as
      to what's going on. Currently, all callers simply do the appropriate
      page shift, which IMO, ends up looking weird with an upcoming change for
      the gen8 page table allocations.
      
      Up until now, the PPGTT was a funky 2 level page table. GEN8 changes
      this to look more like a 3 level page table, and to that extent we need
      a significant amount more memory simply for the page tables. To address
      this, the allocations will be split up in finer amounts.
      
      v2: Replace size_t with uint64_t (Chris, Imre)
      
      v3: Fix size in gen8_ppgtt_init (Ben)
      Fix Size in i915_gem_suspend_gtt_mappings/restore (Imre)
      
      Reviewed-by: Imre Deak <imre.deak@intel.com> (v2)
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      782f1495
    • B
      drm/i915/bdw: Split ppgtt initialization up · bf2b4ed2
      Ben Widawsky 提交于
      Like cleanup in an earlier patch, the code becomes much more readable,
      and easier to extend if we extract out helper functions for the various
      stages of init.
      
      Note that with this patch it becomes really simple, and tempting to begin
      using the 'goto out' idiom with explicit free/fini semantics. I've
      kept the error path as similar as possible to the cleanup() function to
      make sure cleanup is as robust as possible
      
      v2: Remove comment "NB:From here on, ppgtt->base.cleanup() should
      function properly"
      Update commit message to reflect above
      
      v3: Rebased on top of bugfixes found in the previous patch by Imre
      Moved number of pd pages assertion to the proper place (Imre)
      
      v4:
      Allocate dma address space for num_pd_pages, not num_pd_entries (Ben)
      Don't use gen8_pt_dma_addr after free on error path (Imre)
      With new fix from v4 of the previous patch.
      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>
      bf2b4ed2
    • B
      drm/i915/bdw: Reorganize PPGTT init · f3a964b9
      Ben Widawsky 提交于
      Create 3 clear stages in PPGTT init. This will help with upcoming
      changes be more readable. The 3 stages are, allocation, dma mapping, and
      writing the P[DT]Es
      
      One nice benefit to the patches is that it makes 2 very clear error
      points, allocation, and mapping, and avoids having to do any handling
      after writing PTEs (something which was likely buggy before). This
      simplified error handling I suspect will be helpful when we move to
      deferred/dynamic page table allocation and mapping.
      
      The patches also attempts to break up some of the steps into more
      logical reviewable chunks, particularly when we free.
      
      v2: Don't call cleanup on the error path since that takes down the
      drm_mm and list entry, which aren't setup at this point.
      
      v3: Fixes addressing Imre's comments from:
      <1392821989.19792.13.camel@intelbox>
      
      Don't do dynamic allocation for the page table DMA addresses. I can't
      remember why I did it in the first place. This addresses one of Imre's
      other issues.
      
      Fix error path leak of page tables.
      
      v4: Fix the fix of the error path leak. Original fix still leaked page
      tables. (Imre)
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f3a964b9
    • B
      drm/i915/bdw: Free PPGTT struct · b18b6bde
      Ben Widawsky 提交于
      GEN8 never freed the PPGTT struct. As GEN8 doesn't use full PPGTT, the
      leak is small and only found on a module reload. ie. I don't think this
      needs to go to stable.
      
      v2: The very naive, kfree in gen8 ppgtt cleanup, is subject to a double
      free on PPGTT initialization failure. (Spotted by Imre). Instead this
      patch pulls the ppgtt struct freeing out of the cleanup and leaves it to
      the allocators/callers or the one doing the last kref_put as in standard
      convention
      Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      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>
      b18b6bde
  26. 14 2月, 2014 2 次提交
  27. 13 2月, 2014 1 次提交