1. 06 Jun, 2012 1 commit
  2. 25 May, 2012 1 commit
    • 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
      ioctl.
      
      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>
      23ba4fd0
  3. 19 May, 2012 1 commit
  4. 13 May, 2012 1 commit
  5. 03 May, 2012 17 commits
  6. 02 May, 2012 1 commit
  7. 17 Apr, 2012 1 commit
  8. 12 Apr, 2012 1 commit
    • Ben Widawsky's avatar
      drm/i915: rc6 in sysfs · 0136db58
      Ben Widawsky authored
      
      
      Merge rc6 information into the power group for our device. Until now the
      i915 driver has not had any sysfs entries (aside from the connector
      stuff enabled by drm core). Since it seems like we're likely to have
      more in the future I created a new file for sysfs stubs, as well as the
      rc6 sysfs functions which don't really belong elsewhere (perhaps
      i915_suspend, but most of the stuff is in intel_display,c).
      
      displays rc6 modes enabled (as a hex mask):
      cat /sys/class/drm/card0/power/rc6_enable
      
      displays #ms GPU has been in rc6 since boot:
      cat /sys/class/drm/card0/power/rc6_residency_ms
      
      displays #ms GPU has been in deep rc6 since boot:
      cat /sys/class/drm/card0/power/rc6p_residency_ms
      
      displays #ms GPU has been in deepest rc6 since boot:
      cat /sys/class/drm/card0/power/rc6pp_residency_ms
      
      Important note: I've seen on SNB that even when RC6 is *not* enabled the
      rc6 register seems to have a random value in it. I can only guess at the
      reason reason for this. Those writing tools that utilize this value need
      to be careful and probably want to scrutinize the value very carefully.
      
      v2: use common rc6 residency units to milliseconds for the other RC6 types
      
      v3: don't create sysfs files for GEN <= 5
      add a rc6_enable to show a mask of enabled rc6 types
      use unmerge instead of remove for sysfs group
      squash intel_enable_rc6() extraction into this patch
      
      v4: rename sysfs files (Chris)
      
      CC: Chris Wilson <chris@chris-wilson.co.uk>
      CC: Daniel Vetter <daniel.vetter@ffwll.ch>f
      CC: Arjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarBen Widawsky <benjamin.widawsky@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      [danvet: squash in the 64bit division fix by Chris Wilson.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0136db58
  9. 09 Apr, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915: refuse to load on gen6+ without kms · 26394d92
      Daniel Vetter authored
      
      
      Spurred by an irc discussion, let's start to clear up which parts of
      our kms + ums/gem + ums/dri1 + vbios/dri1 kernel driver pieces
      userspace in the wild actually uses.
      
      The idea is that we introduce checks at entry-points (module load
      time, ioctls, ...) first and then reap any obviously dead code in a
      second step.
      
      As a first step refuse to load without kms on chips where userspace
      never supported ums. Now upstream hasn't supported ums on ilk, ever.
      But RHEL had the great idea to backport the kms support to their ums
      driver.
      
      Cc: Dave Airlie <airlied@gmail.com>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      26394d92
  10. 03 Apr, 2012 1 commit
  11. 02 Apr, 2012 1 commit
  12. 28 Mar, 2012 1 commit
  13. 27 Mar, 2012 3 commits
  14. 20 Mar, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915: add HAS_ALIASING_PPGTT parameter for userspace · 777ee96f
      Daniel Vetter authored
      
      
      On Sanybridge a few MI read/write commands only work when ppgtt is
      enabled.  Userspace therefore needs to be able to check whether ppgtt
      is enabled. For added hilarity, you need to reset the "use global GTT"
      bit on snb when ppgtt is enabled, otherwise it won't work.  Despite
      what bspec says about automatically using ppgtt ...
      
      Luckily PIPE_CONTROL (the only write cmd current userspace uses) is
      not affected by all this, as tested by tests/gem_pipe_control_store_loop.
      Reviewed-and-tested-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      777ee96f
  15. 18 Mar, 2012 3 commits
  16. 16 Feb, 2012 1 commit
    • Dave Airlie's avatar
      drm: move pci bus master enable into driver. · 466e69b8
      Dave Airlie authored
      
      
      The current enabling of bus mastering in the drm midlayer allows a large
      race condition under kexec. When a kexec'ed kernel re-enables bus mastering
      for the GPU, previously setup dma blocks may cause writes to random pieces
      of memory. On radeon the writeback mechanism can cause these sorts of issues.
      
      This patch doesn't fix the problem, but it moves the bus master enable under
      the individual drivers control so they can move enabling it until later in
      their load cycle and close the race.
      
      Fix for radeon kms driver will be in a follow-up patch.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      466e69b8
  17. 13 Feb, 2012 1 commit
  18. 09 Feb, 2012 2 commits
  19. 08 Feb, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915: swizzling support for snb/ivb · f691e2f4
      Daniel Vetter authored
      
      
      We have to do this manually. Somebody had a Great Idea.
      
      I've measured speed-ups just a few percent above the noise level
      (below 5% for the best case), but no slowdows. Chris Wilson measured
      quite a bit more (10-20% above the usual snb variance) on a more
      recent and better tuned version of sna, but also recorded a few
      slow-downs on benchmarks know for uglier amounts of snb-induced
      variance.
      
      v2: Incorporate Ben Widawsky's preliminary review comments and
      elaborate a bit about the performance impact in the changelog.
      
      v3: Add a comment as to why we don't need to check the 3rd memory
      channel.
      
      v4: Fixup whitespace.
      Acked-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f691e2f4