Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 26 11月, 2014 1 次提交
    • V
      drm/i915: Cancel vdd off work before suspend · afa4e53a
      由 Ville Syrjälä 提交于 
      Currently we just make sure vdd is off before suspending, but we don't
cancel the vdd off work. The work wil not touch vdd if
want_panel_vdd==false so in theory this is fine.

In the past that was perfectly fine since the vdd off work didn't do
anything when want_panel_vdd==false, so even if the work would have been
run during system resume before i915 has resumed, nothing would happen.

However since pps_lock() will now grab the power domain references before
it can check want_panel_vdd, we may end up toggling the power wells on/off
already before the driver has resumed. That is not really acceptable, so
cancel the vdd off work when suspending the encoder.

The problem appeared when pps_lock() was introduced in:
 commit 773538e8
 Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
 Date:   Thu Sep 4 14:54:56 2014 +0300

    drm/i915: Reset power sequencer pipe tracking when disp2d is off
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      afa4e53a
  3. 30 10月, 2014 1 次提交
  5. 27 10月, 2014 2 次提交
    • V
      drm/i915: Ignore long hpds on eDP ports · 7a7f84cc
      由 Ville Syrjälä 提交于 
      Turning vdd on/off can generate a long hpd pulse on eDP ports. In order
to handle hpd we would need to turn on vdd to perform aux transfers.
This would lead to an endless cycle of
"vdd off -> long hpd -> vdd on -> detect -> vdd off -> ..."

So ignore long hpd pulses on eDP ports. eDP panels should be physically
tied to the machine anyway so they should not actually disappear and
thus don't need long hpd handling. Short hpds are still needed for link
re-train and whatnot so we can't just turn off the hpd interrupt
entirely for eDP ports. Perhaps we could turn it off whenever the panel
is disabled, but just ignoring the long hpd seems sufficient.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: NDave Airlie <airlied@redhat.com>
Reviewed-by: NTodd Previte <tprevite@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      7a7f84cc
    • V
      drm/i915: Do a dummy DPCD read before the actual read · f6a19066
      由 Ville Syrjälä 提交于 
      Sometimes we seem to get utter garbage from DPCD reads. The resulting
buffer is filled with the same byte, and the operation completed without
errors. My HP ZR24w monitor seems particularly susceptible to this
problem once it's gone into a sleep mode.

The issue seems to happen only for the first AUX message that wakes the
sink up. But as the first AUX read we often do is the DPCD receiver
cap it does wreak a bit of havoc with subsequent link training etc. when
the receiver cap bw/lane/etc. information is garbage.

A sufficient workaround seems to be to perform a single byte dummy read
before reading the actual data. I suppose that just wakes up the sink
sufficiently and we can just throw away the returned data in case it's
crap. DP_DPCD_REV seems like a sufficiently safe location to read here.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NTodd Previte <tprevite@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      f6a19066
  7. 19 9月, 2014 4 次提交
  9. 18 9月, 2014 1 次提交
  11. 04 9月, 2014 8 次提交
  13. 03 9月, 2014 17 次提交
  15. 01 9月, 2014 1 次提交
  17. 18 8月, 2014 3 次提交
  19. 12 8月, 2014 1 次提交
  21. 08 8月, 2014 1 次提交