1. 29 Jan, 2015 4 commits
  2. 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
  3. 27 Jan, 2015 30 commits