1. 01 Mar, 2016 4 commits
  2. 29 Feb, 2016 4 commits
    • Eric Engestrom's avatar
      drm/i915: remove dead code · d9f8e52b
      Eric Engestrom authored
      79e53945 ("DRM: i915: add mode setting
      support") added those variables but never used them.
      Signed-off-by: default avatarEric Engestrom <eric.engestrom@imgtec.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1456763047-28828-2-git-send-email-eric.engestrom@imgtec.com
      d9f8e52b
    • Eric Engestrom's avatar
      drm/i915: remove left over dead code · c3454d57
      Eric Engestrom authored
      ae80152d ("drm/i915: Rewrite VLV/CHV
      watermark code") removed everything that would have used those vars.
      Signed-off-by: default avatarEric Engestrom <eric.engestrom@imgtec.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1456763047-28828-1-git-send-email-eric.engestrom@imgtec.com
      c3454d57
    • Matt Roper's avatar
      drm/i915: Add two-stage ILK-style watermark programming (v11) · ed4a6a7c
      Matt Roper authored
      In addition to calculating final watermarks, let's also pre-calculate a
      set of intermediate watermark values at atomic check time.  These
      intermediate watermarks are a combination of the watermarks for the old
      state and the new state; they should satisfy the requirements of both
      states which means they can be programmed immediately when we commit the
      atomic state (without waiting for a vblank).  Once the vblank does
      happen, we can then re-program watermarks to the more optimal final
      value.
      
      v2: Significant rebasing/rewriting.
      
      v3:
       - Move 'need_postvbl_update' flag to CRTC state (Daniel)
       - Don't forget to check intermediate watermark values for validity
         (Maarten)
       - Don't due async watermark optimization; just do it at the end of the
         atomic transaction, after waiting for vblanks.  We do want it to be
         async eventually, but adding that now will cause more trouble for
         Maarten's in-progress work.  (Maarten)
       - Don't allocate space in crtc_state for intermediate watermarks on
         platforms that don't need it (gen9+).
       - Move WaCxSRDisabledForSpriteScaling:ivb into intel_begin_crtc_commit
         now that ilk_update_wm is gone.
      
      v4:
       - Add a wm_mutex to cover updates to intel_crtc->active and the
         need_postvbl_update flag.  Since we don't have async yet it isn't
         terribly important yet, but might as well add it now.
       - Change interface to program watermarks.  Platforms will now expose
         .initial_watermarks() and .optimize_watermarks() functions to do
         watermark programming.  These should lock wm_mutex, copy the
         appropriate state values into intel_crtc->active, and then call
         the internal program watermarks function.
      
      v5:
       - Skip intermediate watermark calculation/check during initial hardware
         readout since we don't trust the existing HW values (and don't have
         valid values of our own yet).
       - Don't try to call .optimize_watermarks() on platforms that don't have
         atomic watermarks yet.  (Maarten)
      
      v6:
       - Rebase
      
      v7:
       - Further rebase
      
      v8:
       - A few minor indentation and line length fixes
      
      v9:
       - Yet another rebase since Maarten's patches reworked a bunch of the
         code (wm_pre, wm_post, etc.) that this was previously based on.
      
      v10:
       - Move wm_mutex to dev_priv to protect against racing commits against
         disjoint CRTC sets. (Maarten)
       - Drop unnecessary clearing of cstate->wm.need_postvbl_update (Maarten)
      
      v11:
       - Now that we've moved to atomic watermark updates, make sure we call
         the proper function to program watermarks in
         {ironlake,haswell}_crtc_enable(); the failure to do so on the
         previous patch iteration led to us not actually programming the
         watermarks before turning on the CRTC, which was the cause of the
         underruns that the CI system was seeing.
       - Fix inverted logic for determining when to optimize watermarks.  We
         were needlessly optimizing when the intermediate/optimal values were
         the same (harmless), but not actually optimizing when they differed
         (also harmless, but wasteful from a power/bandwidth perspective).
      
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1456276813-5689-1-git-send-email-matthew.d.roper@intel.com
      ed4a6a7c
    • Daniel Vetter's avatar
      5790ff74
  3. 26 Feb, 2016 6 commits
  4. 25 Feb, 2016 4 commits
  5. 22 Feb, 2016 8 commits
  6. 19 Feb, 2016 4 commits
  7. 18 Feb, 2016 8 commits
  8. 17 Feb, 2016 2 commits
    • Rodrigo Vivi's avatar
      drm/i915: Enable PSR by default on Haswell and Broadwell. · 9b58e352
      Rodrigo Vivi authored
      With a reliable frontbuffer tracking and all instability corner cases
      on Haswell and Broadwell solved let's re-enabled PSR by default on
      these platforms.
      
      In case a new issue is found and PSR is the main suspect, please check
      if i915.enable_psr=0 really makes your problem go away. If this is the case
      PSR is the culprit so after that please check if i915.enable_psr=2
      or i915.enable_psr=3 solves your issue and please let us know.
      There are many panels out there and not all implementations apparently
      work as we would expect.
      
      In case you needed to force it on standby or disabled or in case of any
      PSR related bug please report it at bugs.freedesktop.org.
      In a bugzilla entry for PSR is desirable:
      - dmesg (drm.debug=0xe)
      - output of /sys/kernel/debug/dri/0/i915_edp_psr_status
      - Platform information. Vendor, model, id, pci id.
      - Graphical environment: Gnome, KDE, openbox, etc...
      - Details how to reproduce.
      - Also good if you could run PSR test cases of Intel-gpu-tools
      - Please mention if forcing main link standby or main link off helps you.
      
      There are Intel-gpu-tools test cases that can be helpful to
      determine if PSR is working as expected:
      kms_psr_sink_crc and kms_psr_frontbuffer_tracking.
      
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1455278893-1307-2-git-send-email-rodrigo.vivi@intel.comSigned-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9b58e352
    • Rodrigo Vivi's avatar
      drm/i915: Enable PSR by default on Valleyview and Cherryview. · a38c274f
      Rodrigo Vivi authored
      With a reliable frontbuffer tracking and all instability corner cases
      solved for this platform let's re-enabled PSR by default.
      
      In case a new issue is found and PSR is the main suspect, please check
      if i915.enable_psr=0 really makes your problem go away,
      please report it at bugs.freedesktop.org.
      
      In a bugzilla entry for PSR is desirable:
      - dmesg (drm.debug=0xe)
      - output of /sys/kernel/debug/dri/0/i915_edp_psr_status
      - Platform information. Vendor, model, id, pci id.
      - Graphical environment: Gnome, KDE, openbox, etc...
      - Details how to reproduce.
      - Also good if you could run PSR test cases of Intel-gpu-tools
      - Please mention if forcing main link standby or main link off helps you.
      
      There are Intel-gpu-tools test cases that can be helpful to
      determine if PSR is working as expected:
       kms_psr_sink_crc and kms_psr_frontbuffer_tracking.
      
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a38c274f