1. 05 Jul, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915: non-interruptible sleeps can't handle -EAGAIN · d6b2c790
      Daniel Vetter authored
      So don't return -EAGAIN, even in the case of a gpu hang. Remap it to
      -EIO instead. Note that this isn't really an issue with
      interruptability, but more that we have quite a few codepaths (mostly
      around kms stuff) that simply can't handle any errors and hence not
      even -EAGAIN. Instead of adding proper failure paths so that we could
      restart these ioctls we've opted for the cheap way out of sleeping
      non-interruptibly.  Which works everywhere but when the gpu dies,
      which this patch fixes.
      So essentially interruptible == false means 'wait for the gpu or die
      This patch is a bit ugly because intel_ring_begin is all non-interruptible
      and hence only returns -EIO. But as the comment in there says,
      auditing all the callsites would be a pain.
      To avoid duplicating code, reuse i915_gem_check_wedge in __wait_seqno
      and intel_wait_ring_buffer. Also use the opportunity to clarify the
      different cases in i915_gem_check_wedge a bit with comments.
      v2: Don't access dev_priv->mm.interruptible from check_wedge - we
      might not hold dev->struct_mutex, making this racy. Instead pass
      interruptible in as a parameter. I've noticed this because I've hit a
      BUG_ON(!mutex_is_locked) at the top of check_wedge. This has been
      added in
      commit b4aca010
      Author: Ben Widawsky <ben@bwidawsk.net>
      Date:   Wed Apr 25 20:50:12 2012 -0700
          drm/i915: extract some common olr+wedge code
      although that commit is missing any justification for this. I guess
      it's just copy&paste, because the same commit add the same BUG_ON
      check to check_olr, where it indeed makes sense.
      But in check_wedge everything we access is protected by other means,
      so this is superflous. And because it now gets in the way (we add a
      new caller in __wait_seqno, which can be called without
      dev->struct_mutext) let's just remove it.
      v3: Group all the i915_gem_check_wedge refactoring into this patch, so
      that this patch here is all about not returning -EAGAIN to callsites
      that can't handle syscall restarting.
      v4: Add clarification what interuptible == fales means in our code,
      requested by Ben Widawsky.
      v5: Fix EAGAIN mispell noticed by Chris Wilson.
      Reviewed-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  2. 20 Jun, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915: disable flushing_list/gpu_write_list · cc889e0f
      Daniel Vetter authored
      This is just the minimal patch to disable all this code so that we can
      do decent amounts of QA before we rip it all out.
      The complicating thing is that we need to flush the gpu caches after
      the batchbuffer is emitted. Which is past the point of no return where
      execbuffer can't fail any more (otherwise we risk submitting the same
      batch multiple times).
      Hence we need to add a flag to track whether any caches associated
      with that ring are dirty. And emit the flush in add_request if that's
      the case.
      Note that this has a quite a few behaviour changes:
      - Caches get flushed/invalidated unconditionally.
      - Invalidation now happens after potential inter-ring sync.
      I've bantered around a bit with Chris on irc whether this fixes
      anything, and it might or might not. The only thing clear is that with
      these changes it's much easier to reason about correctness.
      Also rip out a lone get_next_request_seqno in the execbuffer
      retire_commands function. I've dug around and I couldn't figure out
      why that is still there, with the outstanding lazy request stuff it
      shouldn't be necessary.
      v2: Chris Wilson complained that I also invalidate the read caches
      when flushing after a batchbuffer. Now optimized.
      v3: Added some comments to explain the new flushing behaviour.
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  3. 14 Jun, 2012 2 commits
    • Ben Widawsky's avatar
      drm/i915: switch to default context on idle · f2ef6eb1
      Ben Widawsky authored
      To keep things as sane as possible, switch to the default context before
      idling. This should help free context objects, as well as put things in
      a more well defined state before suspending.
      v2: remove seqno from context switch call (daniel)
      return error on failed context switch instead of WARN+continue (daniel)
      v3: move idling to i915_gpu idle (from i915_gem_idle) (Chris)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
    • Ben Widawsky's avatar
      drm/i915: preliminary context support · 254f965c
      Ben Widawsky authored
      Very basic code for context setup/destruction in the driver.
      Adds the file i915_gem_context.c This file implements HW context
      support. On gen5+ a HW context consists of an opaque GPU object which is
      referenced at times of context saves and restores.  With RC6 enabled,
      the context is also referenced as the GPU enters and exists from RC6
      (GPU has it's own internal power context, except on gen5).  Though
      something like a context does exist for the media ring, the code only
      supports contexts for the render ring.
      In software, there is a distinction between contexts created by the
      user, and the default HW context. The default HW context is used by GPU
      clients that do not request setup of their own hardware context. The
      default context's state is never restored to help prevent programming
      errors. This would happen if a client ran and piggy-backed off another
      clients GPU state.  The default context only exists to give the GPU some
      offset to load as the current to invoke a save of the context we
      actually care about. In fact, the code could likely be constructed,
      albeit in a more complicated fashion, to never use the default context,
      though that limits the driver's ability to swap out, and/or destroy
      other contexts.
      All other contexts are created as a request by the GPU client. These
      contexts store GPU state, and thus allow GPU clients to not re-emit
      state (and potentially query certain state) at any time. The kernel
      driver makes certain that the appropriate commands are inserted.
      There are 4 entry points into the contexts, init, fini, open, close.
      The names are self-explanatory except that init can be called during
      reset, and also during pm thaw/resume. As we expect our context to be
      preserved across these events, we do not reinitialize in this case.
      As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
      considered too big is arbitrary. The reason for this is even though
      context sizes are increasing with every generation, they have yet to
      eclipse even 32k. If we somehow read back way more than that, it
      probably means BIOS has done something strange, or we're running on a
      platform that wasn't designed for this.
      v2: rename load/unload to init/fini (daniel)
      remove ILK support for get_size() (indirectly daniel)
      add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
      added comments (Ben)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
  4. 12 Jun, 2012 2 commits
  5. 06 Jun, 2012 1 commit
    • Ben Widawsky's avatar
      drm/i915: Inifite timeout for wait ioctl · eac1f14f
      Ben Widawsky authored
      Change the ns_timeout parameter of the wait ioctl to a signed value.
      Doing this allows the kernel to provide an infinite wait when a timeout
      of less than 0 is provided. This mimics select/poll.
      Initially the parameter was meant to match up with the GL spec 1:1, but
      after being made aware of how much 2^64 - 1 nanoseconds actually is, I
      do not think anyone will ever notice the loss of 1 bit.
      The infinite timeout on waiting is similar to the existing i915
      userspace interface with the exception that struct_mutex is dropped
      while doing the wait in this ioctl.
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  6. 02 Jun, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915: extract object active state flushing code · 30dfebf3
      Daniel Vetter authored
      Both busy_ioctl and the new wait_ioct need to do the same dance (or at
      least should). Some slight changes:
      - busy_ioctl now unconditionally checks for olr. Before emitting a
        require flush would have prevent the olr check and hence required a
        second call to the busy ioctl to really emit the request.
      - the timeout wait now also retires request. Not really required for
        abi-reasons, but makes a notch more sense imo.
      I've tested this by pimping the i-g-t test some more and also checking
      the polling behviour of the wait_rendering_timeout ioctl versus what
      busy_ioctl returns.
      v2: Too many people complained about unplug, new color is
      v3: Kill the comment about the unplug moniker.
      v4: s/un-active/inactive/
      Reviewed-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  7. 31 May, 2012 1 commit
  8. 25 May, 2012 5 commits
    • Ben Widawsky's avatar
      drm/i915: s/i915_wait_request/i915_wait_seqno/g · 199b2bc2
      Ben Widawsky authored
      Wait request is poorly named IMO. After working with these functions for
      some time, I feel it's much clearer to name the functions more
      Of course we must update the callers to use the new name as well.
      This leaves room within our namespace for a *real* wait request function
      at some point.
      Note to maintainer: this patch is optional.
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Ben Widawsky's avatar
      drm/i915: wait render timeout ioctl · 23ba4fd0
      Ben Widawsky authored
      This helps implement GL_ARB_sync but stops short of allowing full blown
      sync objects. Finally we can use the new timed seqno waiting function
      to allow userspace to wait on a buffer object with a timeout. This
      implements that interface.
      The IOCTL will take as input a buffer object handle, and a timeout in
      nanoseconds (flags is currently optional but will likely be used for
      permutations of flush operations). Users may specify 0 nanoseconds to
      instantly check.
      The wait ioctl with a timeout of 0 reimplements the busy ioctl. With any
      non-zero timeout parameter the wait ioctl will wait for the given number
      of nanoseconds on an object becoming unbusy. Since the wait itself does
      so holding struct_mutex the object may become re-busied before this
      completes. A similar but shorter race condition exists in the busy
      v2: ETIME/ERESTARTSYS instead of changing to EBUSY, and EGAIN (Chris)
      Flush the object from the gpu write domain (Chris + Daniel)
      Fix leaked refcount in good case (Chris)
      Naturally align ioctl struct (Chris)
      v3: Drop lock after getting seqno to avoid ugly dance (Chris)
      v4: check for 0 timeout after olr check to allow polling (Chris)
      v5: Updated the comment. (Chris)
      v6: Return -ETIME instead of -EBUSY when timeout_ns is 0 (Daniel)
      Fix the commit message comment to be less ugly (Ben)
      Add a warning to check the return timespec (Ben)
      v7: Use DRM_AUTH for the ioctl. (Eugeni)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Chris Wilson's avatar
      drm/i915: Remove the error message for unbinding pinned buffers · 31d8d651
      Chris Wilson authored
      This is now used intentionally to prevent proliferation of is-pinned
      checks upon the inactive list following:
      commit 1b50247a
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Tue Apr 24 15:47:30 2012 +0100
          drm/i915: Remove the list of pinned inactive objects
      Reported-and-tested-by: guang.a.yang@intel.com
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50075
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Chris Wilson's avatar
      drm/i915: Limit page allocations to lowmem (dma32) for i965 · bed1ea95
      Chris Wilson authored
      Broadwater and Crestline share a limitation that prevent it from
      relocating general surface state above 4GiB. The only recourse we have
      since any buffer object may be used as a relocation target is then to
      limit all object allocations on 965g[m] to DMA32.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Ben Widawsky's avatar
      drm/i915: timeout parameter for seqno wait · 5c81fe85
      Ben Widawsky authored
      Insert a wait parameter in the code so we can possibly timeout on a
      seqno wait if need be. The code should be functionally the same as
      before because all the callers will continue to retry if an arbitrary
      timeout elapses.
      We'd like to have nanosecond granularity, but the only way to do this is
      with hrtimer, and that doesn't fit well with the needs of this code.
      v2: Fix rebase error (Chris)
      Return proper time even in wedged + signal case (Chris + Ben)
      Use timespec constructs (Ben)
      Didn't take Daniel's advice regarding the Frankenstein-ness of the
        function. I did try his advice, but in the end I liked the way the
        original code looked, better.
      v3: Make wakeups far less frequent for infinite waits (Chris)
      v4: Remove dummy_wait variable (Daniel)
      Use raw monotonic time instead of jiffies (made the code a bit cleaner) (Ben)
      Added a couple of warnings (Ben)
      v5: Remove warnings (Daniel)
      Use more accurate time diff for default case (Daniel)
      Bikeshed for setting the return timespec in timeout case (Daniel)
      s/jiffies/time in one of the comments
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  9. 23 May, 2012 1 commit
    • Daniel Vetter's avatar
      i915: add dmabuf/prime buffer sharing support. · 1286ff73
      Daniel Vetter authored
      This adds handle->fd and fd->handle support to i915, this is to allow
      for offloading of rendering in one direction and outputs in the other.
      v2 from Daniel Vetter:
      - fixup conflicts with the prepare/finish gtt prep work.
      - implement ppgtt binding support.
      Note that we have squat i-g-t testcoverage for any of the lifetime and
      access rules dma_buf/prime support brings along. And there are quite a
      few intricate situations here.
      Also note that the integration with the existing code is a bit
      hackish, especially around get_gtt_pages and put_gtt_pages. It imo
      would be easier with the prep code from Chris Wilson's unbound series,
      but that is for 3.6.
      Also note that I didn't bother to put the new prepare/finish gtt hooks
      to good use by moving the dma_buf_map/unmap_attachment calls in there
      (like we've originally planned for).
      Last but not least this patch is only compile-tested, but I've changed
      very little compared to Dave Airlie's version. So there's a decent
      chance v2 on drm-next works as well as v1 on 3.4-rc.
      v3: Right when I've hit sent I've noticed that I've screwed up one
      obj->sg_list (for dmar support) and obj->sg_table (for prime support)
      disdinction. We should be able to merge these 2 paths, but that's
      material for another patch.
      v4: fix the error reporting bugs pointed out by ickle.
      v5: fix another error, and stop non-gtt mmaps on shared objects
      stop pread/pwrite on imported objects, add fake kmap
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  10. 19 May, 2012 1 commit
    • Chris Wilson's avatar
      drm/i915: Introduce for_each_ring() macro · b4519513
      Chris Wilson authored
      In many places we wish to iterate over the rings associated with the
      GPU, so refactor them to use a common macro.
      Along the way, there are a few code removals that should be side-effect
      free and some rearrangement which should only have a cosmetic impact,
      such as error-state.
      Note that this slightly changes the semantics in the hangcheck code:
      We now always cycle through all enabled rings instead of
      short-circuiting the logic.
      v2: Pull in a couple of suggestions from Ben and Daniel for
      intel_ring_initialized() and not removing the warning (just moving them
      to a new home, closer to the error).
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarBen Widawsky <ben@bwidawsk.net>
      [danvet: Added note to commit message about the small behaviour
      change, suggested by Ben Widawsky.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  11. 03 May, 2012 21 commits
  12. 20 Apr, 2012 1 commit
    • Linus Torvalds's avatar
      VM: add "vm_mmap()" helper function · 6be5ceb0
      Linus Torvalds authored
      This continues the theme started with vm_brk() and vm_munmap():
      vm_mmap() does the same thing as do_mmap(), but additionally does the
      required VM locking.
      This uninlines (and rewrites it to be clearer) do_mmap(), which sadly
      duplicates it in mm/mmap.c and mm/nommu.c.  But that way we don't have
      to export our internal do_mmap_pgoff() function.
      Some day we hopefully don't have to export do_mmap() either, if all
      modular users can become the simpler vm_mmap() instead.  We're actually
      very close to that already, with the notable exception of the (broken)
      use in i810, and a couple of stragglers in binfmt_elf.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  13. 18 Apr, 2012 2 commits