Skip to content

K
Kernel

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

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 07 11月, 2014 1 次提交
  3. 03 11月, 2014 7 次提交
  5. 31 10月, 2014 3 次提交
  7. 30 10月, 2014 2 次提交
  9. 29 10月, 2014 1 次提交
  11. 28 10月, 2014 4 次提交
  13. 27 10月, 2014 3 次提交
    • V
      drm/i915: Fix GMBUSFREQ on vlv/chv · 6be1e3d3
      由 Ville Syrjälä 提交于 
      vlv_cdclk_freq is in kHz but we need MHz for the GMBUSFREQ divider.

This is a regression from:
commit f8bf63fd
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Jun 13 13:37:54 2014 +0300

    drm/i915: Kill duplicated cdclk readout code from i2c
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      6be1e3d3
    • 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
  15. 24 10月, 2014 19 次提交