Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 25 5月, 2018 1 次提交
    • V
      drm/i915: Consult VBT "LVDS config" bits to determine whether internal LVDS is present · ca3b3fa3
      由 Ville Syrjälä 提交于 
      VBT seems to have some bits to tell us whether the internal LVDS port
has something hooked up. In theory one might expect the VBT to not have
a child device for the LVDS port if there's no panel hooked up, but
in practice many VBTs still add the child device. The "LVDS config" bits
seem more reliable though, so let's check those.

So far we've used the "LVDS config" bits to check for eDP support on
ILK+, and disable the internal LVDS when the value is 3. That value
is actually documented as "Both internal LVDS and SDVO LVDS", but in
practice it looks to mean "eDP" on all the ilk+ VBTs I've seen. So let's
keep that interpretation, but for pre-ILK we will consider the value
3 to also indicate the presence of the internal LVDS.

Currently we have 25 DMI matches for the "no internal LVDS" quirk. In an
effort to reduce that let's toss in a WARN when the DMI match and VBT
both tell us that the internal LVDS is not present. The hope is that
people will report a bug, and then we can just nuke the corresponding
entry from the DMI quirk list. Credits to Jani for this idea.

v2: Split the basic int_lvds_support thing to a separate patch (Jani)
v3: Rebase
v4: Limit this to VBT version >= 134

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518150138.18361-1-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
      ca3b3fa3
  3. 08 2月, 2018 1 次提交
  5. 02 2月, 2018 1 次提交
  7. 20 1月, 2018 1 次提交
  9. 19 1月, 2018 2 次提交
  11. 31 10月, 2017 1 次提交
  13. 30 10月, 2017 1 次提交
  15. 21 10月, 2017 1 次提交
    • R
      drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin. · 9c3b2689
      由 Rodrigo Vivi 提交于 
      Starting on CNL we now need to map VBT DDC Pin to
BSPec DDC Pin values. Not a direct translation anymore.

According to VBT
Block 2 (General Bytes Definition)
DDC Bus

+----------+-----------+--------------------+
| DDI Type | VBT Value | Bspec Mapped Value |
+----------+-----------+--------------------+
| DDI-B    | 0x1       | 0x1                |
| DDI-C    | 0x2       | 0x2                |
| DDI-D    | 0x3       | 0x4                |
| DDI-F    | 0x4       | 0x3                |
+----------+-----------+--------------------+

v2: Move defines to a better place.
    This is actually CNL_PCH not CNL only.
v3: Accepting Ville's suggestions: enums and array to
    to make this future proof.
v4: Protect the array access as Ville suggested.
    Also accepting all Jani's suggestions:
    	      - use already defined gmbus pin definitions.
	      - use map_ddc_pin for disambiguation.
	      - Add /* sic */ comment on inverted values
	      	so people can easily see it it nos a mistake
		we have the map 3 -> 4 and 4 -> 3 :/

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Clinton Taylor <clinton.a.taylor@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171020172641.16029-1-rodrigo.vivi@intel.com
      9c3b2689
  17. 28 8月, 2017 4 次提交
  19. 25 8月, 2017 9 次提交
  21. 23 12月, 2016 1 次提交
  23. 16 11月, 2016 1 次提交
  25. 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
  27. 10 6月, 2016 1 次提交
  29. 02 6月, 2016 1 次提交
  31. 23 5月, 2016 1 次提交
  33. 09 5月, 2016 1 次提交
  35. 02 5月, 2016 1 次提交
  37. 06 4月, 2016 1 次提交
  39. 17 3月, 2016 1 次提交
  41. 12 1月, 2016 3 次提交
  43. 05 1月, 2016 2 次提交
  45. 22 12月, 2015 1 次提交
  47. 17 12月, 2015 1 次提交
  49. 16 12月, 2015 1 次提交