1. 13 Feb, 2015 3 commits
    • Tvrtko Ursulin's avatar
      drm/i915: Track old framebuffer instead of object · ab8d6675
      Tvrtko Ursulin authored
      Daniel Vetter spotted a bug while reviewing some of my refactoring in this
      are of the code. I'll quote:
      
      """
      > @@ -9764,6 +9768,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
      >  	work->event = event;
      >  	work->crtc = crtc;
      >  	work->old_fb_obj = intel_fb_obj(old_fb);
      > +	work->old_tiling_mode = to_intel_framebuffer(old_fb)->tiling_mode;
      
      Hm, that's actually an interesting bugfix - currently userspace could be
      sneaky and destroy the old fb immediately after the flip completes and the
      change the tiling of the underlying object before the unpin work had a
      chance to run (needs some fudgin with rt prios to starve workers to make
      this work though).
      
      Imo the right fix is to hold a reference onto the fb and not the
      underlying gem object. With that tiling is guaranteed not to change.
      """
      
      This patch tries to implement the above proposed change.
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ab8d6675
    • Matt Roper's avatar
      drm/i915: Switch planes from transitional helpers to full atomic helpers · 3f678c96
      Matt Roper authored
      There are two sets of helper functions provided by the DRM core that can
      implement the .update_plane() and .disable_plane() hooks in terms of a
      driver's atomic entrypoints.  The transitional helpers (which we have
      been using so far) create a plane state and then use the plane's atomic
      entrypoints to perform the atomic begin/check/prepare/commit/finish
      sequence on that single plane only.  The full atomic helpers create a
      top-level atomic state (which is capable of holding multiple object
      states for planes, crtc's, and/or connectors) and then passes the
      top-level atomic state through the full "atomic modeset" pipeline.
      
      Switching from the transitional to full helpers here shouldn't result in
      any functional change, but will enable us to exercise/test more of the
      internal atomic pipeline with the legacy API's used by existing
      applications.
      Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      3f678c96
    • Matt Roper's avatar
      drm/i915: Keep plane->state updated on pageflip · 1ed1f968
      Matt Roper authored
      Until all drivers have transitioned to atomic, the framebuffer
      associated with a plane is tracked in both plane->fb (for legacy) and
      plane->state->fb (for all the new atomic codeflow).  All of our modeset
      and plane updates use drm_plane->update_plane(), so in theory plane->fb
      and plane->state->fb should always stay in sync and point at the same
      thing for i915.  However we forgot about the pageflip ioctl case, which
      currently only updates plane->fb and leaves plane->state->fb at a stale
      value.
      
      Surprisingly, this doesn't cause any real problems at the moment since
      internally we use the plane->fb pointer in most of the places that
      matter, and on the next .update_plane() call, we use plane->fb to figure
      out which framebuffer to cleanup.  However when we switch to the full
      atomic helpers for update_plane()/disable_plane(), those helpers use
      plane->state->fb to figure out which framebuffer to cleanup, so not
      having updated the plane->state->fb pointer causes things to blow up
      following a pageflip ioctl.
      
      The fix here is to just make sure we update plane->state->fb at the same
      time we update plane->fb in the pageflip ioctl.
      Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      1ed1f968
  2. 03 Feb, 2015 1 commit
    • Daniel Vetter's avatar
      drm/i915: Remove bogus locking check in the hangcheck code · b838cbee
      Daniel Vetter authored
      You can _never_ assert that a lock is not held, except in some very
      restricted corner cases where it's guranteed that your code is running
      single-threade (e.g. driver load before you've published any pointers
      leading to that lock).
      
      In addition the early return breaks a bunch of testcases since with
      highly concurrent hangcheck stress tests the reset fails to work and
      the test doesn't recover and time out.
      
      This regression has been introduced in
      
      commit b8d24a06
      Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Date:   Wed Jan 28 17:03:14 2015 +0200
      
          drm/i915: Remove nested work in gpu error handling
      
      Aside: It is possible to check whether a given task doesn't hold a
      lock, but only when lockdep is enabled, using the lockdep_assert_held
      stuff.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88908Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      b838cbee
  3. 30 Jan, 2015 7 commits
  4. 29 Jan, 2015 8 commits
  5. 28 Jan, 2015 6 commits
    • Sonika Jindal's avatar
      drm/i915/skl: Enabling PSR on Skylake · e3d99845
      Sonika Jindal authored
      Mainly taking care of some register offsets, otherwise things are similar to
      hsw. Also, programming ddi aux to use hardcoded values for psr data select.
      
      v2: introduce  EDP_PSR_AUX_BASE macro (Chris)
      v3: Moving to HW tracking for SKL+ platforms, so activating source psr during
      psr_enabling and then avoiding psr entries and exits for each frontbuffer
      updates.
      v4: Using SKL DDI AUX regs instead of changing PSR_AUX regs definition (Rodrigo)
      Signed-off-by: default avatarSonika Jindal <sonika.jindal@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      [danvet: Drop the hunks to short-circuit sw tracking: We'd need to
      push this down one level, and I don't fully trust the test coverage
      yet to do so. So much prefer we pick a whitelist approach for the
      cases we know work correctly.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e3d99845
    • Chris Wilson's avatar
      Revert "drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES" · a5094051
      Chris Wilson authored
      The core fix was applied in
      
      commit a63b03e2
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Tue Jan 6 10:29:35 2015 +0000
      
          mutex: Always clear owner field upon mutex_unlock()
      
      (note the absence of stable@ tag)
      
      so we can now revert our band-aid commit 226e5ae9 for -next.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a5094051
    • Mika Kuoppala's avatar
      drm/i915: Be consistent on printing seqnos · 20e28fba
      Mika Kuoppala authored
      We have had %x and %u intermixed. Bring everything in line and
      use %x
      Signed-off-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      20e28fba
    • Chris Wilson's avatar
      drm/i915: Display current hangcheck status in debugfs · f654449a
      Chris Wilson authored
      For example,
      
      /sys/kernel/debug/dri/0/i915_hangcheck_info:
      
      Hangcheck active, fires in 15887800ms
      render ring:
              seqno = -4059 [current -583]
              action = 2
              score = 0
              ACTHD = 1ee8 [current 21f980]
              max ACTHD = 0
      
      v2: Include expiration ETA. Can anyone spot a problem?
      v3: Convert for workqueued hangcheck (Mika)
      v4: Print seqnos as unsigned ints (Ville)
      v5: Print seqnos as hex (Chris)
      
      Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) (v2)
      Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
      Signed-off-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f654449a
    • Chris Wilson's avatar
      drm/i915: Convert hangcheck from a timer into a delayed work item · 737b1506
      Chris Wilson authored
      When run as a timer, i915_hangcheck_elapsed() must adhere to all the
      rules of running in a softirq context. This is advantageous to us as we
      want to minimise the risk that a driver bug will prevent us from
      detecting a hung GPU. However, that is irrelevant if the driver bug
      prevents us from resetting and recovering. Still it is prudent not to
      rely on mutexes inside the checker, but given the coarseness of
      dev->struct_mutex doing so is extremely hard.
      
      Give in and run from a work queue, i.e. outside of softirq.
      
      v2: Use own workqueue to avoid deadlocks (Daniel)
          Cleanup commit msg and add comment to i915_queue_hangcheck() (Chris)
      
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Daniel Vetter <dnaiel.vetter@ffwll.chm>
      Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
      Signed-off-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      [danvet: Remove accidental kerneldoc comment starter, to appease the 0
      day builder.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      737b1506
    • Chris Wilson's avatar
      agp/intel: Serialise after GTT updates · 983d308c
      Chris Wilson authored
      An interesting bug occurs on Pineview through which the root cause is
      that the writes of the PTE values into the GTT is not serialised with
      subsequent memory access through the GTT (when using WC updates of the
      PTE values). This is despite there being a posting read after the GTT
      update. However, by changing the address of the posting read, the memory
      access is indeed serialised correctly.
      
      Whilst we are manipulating the memory barriers, we can remove the
      compiler :memory restraint on the intermediate PTE writes knowing that
      we explicitly perform a posting read afterwards.
      
      v2: Replace posting reads with explicit write memory barriers - in
      particular this is advantages in case of single page objects. Update
      comments to mention this issue is only with WC writes.
      
      Testcase: igt/gem_exec_big #pnv
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88191
      Tested-by: huax.lu@intel.com (v1)
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      983d308c
  6. 27 Jan, 2015 15 commits