Skip to content

K
Kernel

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

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 10 10月, 2017 3 次提交
  3. 25 9月, 2017 1 次提交
  5. 22 9月, 2017 1 次提交
  7. 28 8月, 2017 2 次提交
  9. 25 8月, 2017 4 次提交
  11. 16 8月, 2017 2 次提交
  13. 08 7月, 2017 1 次提交
  15. 14 3月, 2017 1 次提交
  17. 13 3月, 2017 1 次提交
  19. 07 1月, 2017 1 次提交
  21. 23 12月, 2016 1 次提交
  23. 22 12月, 2016 1 次提交
  25. 12 12月, 2016 1 次提交
  27. 02 12月, 2016 1 次提交
  29. 16 11月, 2016 1 次提交
  31. 14 11月, 2016 1 次提交
    • V
      drm/i915: Assume non-DP++ port if dvo_port is HDMI and there's no AUX ch specified in the VBT · 7a17995a
      由 Ville Syrjälä 提交于 
      My heuristic for detecting type 1 DVI DP++ adaptors based on the VBT
port information apparently didn't survive the reality of buggy VBTs.
In this particular case we have a machine with a natice HDMI port, but
the VBT tells us it's a DP++ port based on its capabilities.

The dvo_port information in VBT does claim that we're dealing with a
HDMI port though, but we have other machines which do the same even
when they actually have DP++ ports. So that piece of information alone
isn't sufficient to tell the two apart.

After staring at a bunch of VBTs from various machines, I have to
conclude that the only other semi-reliable clue we can use is the
presence of the AUX channel in the VBT. On this particular machine
AUX channel is specified as zero, whereas on some of the other machines
which listed the DP++ port as HDMI have a non-zero AUX channel.

I've also seen VBTs which have dvo_port a DP but have a zero AUX
channel. I believe those we need to treat as DP ports, so we'll limit
the AUX channel check to just the cases where dvo_port is HDMI.

If we encounter any more serious failures with this heuristic I think
we'll have to have to throw it out entirely. But that could mean that
there is a risk of type 1 DVI dongle users getting greeted by a
black screen, so I'd rather not go there unless absolutely necessary.

v2: Remove the duplicate PORT_A check (Daniel)
    Fix some typos in the commit message

Cc: Daniel Otero <daniel.otero@outlook.com>
Cc: stable@vger.kernel.org
Tested-by: NDaniel Otero <daniel.otero@outlook.com>
Fixes: d6199256 ("drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97994Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1478884464-14251-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7a17995a
  33. 28 10月, 2016 1 次提交
  35. 21 10月, 2016 1 次提交
  37. 18 10月, 2016 1 次提交
  39. 19 9月, 2016 1 次提交
  41. 05 7月, 2016 1 次提交
  43. 10 6月, 2016 3 次提交
  45. 07 6月, 2016 1 次提交
  47. 02 6月, 2016 2 次提交
  49. 23 5月, 2016 2 次提交
  51. 09 5月, 2016 1 次提交
  53. 02 5月, 2016 1 次提交
  55. 26 4月, 2016 1 次提交
  57. 12 4月, 2016 1 次提交
    • V
      drm/i915: Get panel_type from OpRegion panel details · a0562819
      由 Ville Syrjälä 提交于 
      We've had problems on several occasions with using the panel type
from the VBT block 40. Usually it seems to be 2, which often
doesn't give us the correct timings for the panel. After some
more digging I found a way to get a panel type via the OpRegion
SWSCI GBDA "Get Panel Details" method. Let's try to use it.

The spec has this to say about the output:
"Bits [15:8] - Panel Type
 Bits contain the panel type user setting from CMOS
 00h = Not Valid, use default Panel Type & Timings from VBT
 01h - 0Fh = Panel Number"

Another version of the spec lists the valid range as 1-16, which makes
more sense since VBT supports 16 panels. Based on actual results
from Rob's G45, 1-16 is what we need to accept.

The other bits in the output don't look relevant for the problem at
hand.

The input is specified as:
"Bits [31:4] - Reserved
 Reserved (must be zero)
 Bits [3:0] - Panel Number
 These bits contain the sequential index of Panel, starting at 0 and
 counting upwards from the first integrated Internal Flat-Panel Display
 Encoder present, and then from the first external Display Encoder
 (e.g., S/DVO-B then S/DVO-C) which supports Internal Flat-Panels.
 0h - 0Fh = Panel number"

For now I've just hardcoded the input panel number as 0. That would seem
like a decent choise for LVDS. Not so sure about eDP when port != A.

v2: Accept values 1-16
    Filter out bogus results in opregion code (Jani)
    Add debug logging for all the different branches (Jani)

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Rob Kramer <rob@solution-space.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1460359431-11003-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
Tested-by: NRob Kramer <rob@solution-space.com>
      a0562819