1. 10 8月, 2016 4 次提交
  2. 06 8月, 2016 1 次提交
  3. 05 8月, 2016 1 次提交
  4. 04 8月, 2016 6 次提交
  5. 02 8月, 2016 1 次提交
  6. 18 7月, 2016 2 次提交
  7. 07 7月, 2016 4 次提交
  8. 05 7月, 2016 1 次提交
  9. 04 7月, 2016 1 次提交
  10. 30 6月, 2016 2 次提交
  11. 29 6月, 2016 3 次提交
    • I
      drm/i915: Avoid early timeout during AUX transfers · ba34a653
      Imre Deak 提交于
      Since wait_for_atomic doesn't re-check the wait-for condition after
      expiry of the timeout it can fail when called from non-atomic context
      even if the condition is set correctly before the expiry. Fix this by
      using the non-atomic wait_for instead.
      
      Due to the relatively long 10ms timeout, probably this didn't cause any
      real problems, but fix it in any case for consistency.
      
      Fixes: 0351b939 ("drm/i915: Do not lie about atomic timeout granularity")
      CC: Chris Wilson <chris@chris-wilson.co.uk>
      CC: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      CC: drm-intel-fixes@lists.freedesktop.org
      Link: http://patchwork.freedesktop.org/patch/msgid/1467110253-16046-5-git-send-email-imre.deak@intel.com
      (cherry picked from commit 713a6b66)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      ba34a653
    • V
      drm/i915: Refresh cached DP port register value on resume · 664a84d2
      Ville Syrjälä 提交于
      During hibernation the cached DP port register value will be left with
      whatever value we have there when we create the hibernation image.
      Currently that means the port (and eDP PLL) will be off in the cached
      value. However when we resume there is no guarantee that the value
      in the actual register will match the cached value. If i915 isn't
      loaded in the kernel that loads the hibernation image, the port may
      well be on (eg. left on by the BIOS). The encoder state readout
      does the right thing in this case and updates our encoder state
      to reflect the actual hardware state. However the post-resume modeset
      will then use the stale cached port register value in
      intel_dp_link_down() and potentially confuse the hardware.
      
      This was caught by the following assert
       WARNING: CPU: 3 PID: 5288 at ../drivers/gpu/drm/i915/intel_dp.c:2184 assert_edp_pll+0x99/0xa0 [i915]
       eDP PLL state assertion failure (expected on, current off)
      on account of the eDP PLL getting prematurely turned off when
      shutting down the port, since the DP_PLL_ENABLE bit wasn't set
      in the cached register value.
      
      Presumably I introduced this problem in
      commit 6fec7662 ("drm/i915: Use intel_dp->DP in eDP PLL setup")
      as before that we didn't update the cached value after shuttting the
      port down. That's assuming the port got enabled at least once prior
      to hibernating. If that didn't happen then the cached value would
      still have been totally out of sync with reality (eg. first boot w/o
      eDP on, then hibernate, and then resume with eDP on).
      
      So, let's fix this properly and refresh the cached register value from
      the hardware register during resume.
      
      DDI platforms shouldn't use the cached value during port disable at
      least, so shouldn't have this particular issue. They might still have
      issues if we skip the initial modeset and then try to retrain the link
      or something. But untangling this DP vs. DDI mess is a bigger topic,
      so let's jut punt on DDI for now.
      
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: stable@vger.kernel.org
      Fixes: 6fec7662 ("drm/i915: Use intel_dp->DP in eDP PLL setup")
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1463162036-27931-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>
      (cherry picked from commit 64989ca4)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      664a84d2
    • I
      drm/i915: Avoid early timeout during AUX transfers · 713a6b66
      Imre Deak 提交于
      Since wait_for_atomic doesn't re-check the wait-for condition after
      expiry of the timeout it can fail when called from non-atomic context
      even if the condition is set correctly before the expiry. Fix this by
      using the non-atomic wait_for instead.
      
      Due to the relatively long 10ms timeout, probably this didn't cause any
      real problems, but fix it in any case for consistency.
      
      Fixes: 0351b939 ("drm/i915: Do not lie about atomic timeout granularity")
      CC: Chris Wilson <chris@chris-wilson.co.uk>
      CC: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      CC: drm-intel-fixes@lists.freedesktop.org
      Link: http://patchwork.freedesktop.org/patch/msgid/1467110253-16046-5-git-send-email-imre.deak@intel.com
      713a6b66
  12. 24 6月, 2016 3 次提交
  13. 23 6月, 2016 5 次提交
  14. 22 6月, 2016 4 次提交
  15. 20 6月, 2016 2 次提交