On Wed, Jun 01, 2016 at 11:20:04AM +0300, Ville Syrjälä wrote: > On Wed, Jun 01, 2016 at 08:27:50AM +0100, Chris Wilson wrote: > > If the VBT says that a certain port should be eDP (and hence fused off > > from HDMI), but in reality it isn't, we need to try and acquire the HDMI > > connection instead. So only trust the VBT edp setting if we can connect > > to an eDP device on that port. > > > > Fixes: d2182a6608 (drm/i915: Don't register HDMI connectors for eDP ports on VLV/CHV) > > References: https://bugs.freedesktop.org/show_bug.cgi?id=96288 > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Tested-by: Phidias Chiang <phidias.chiang@xxxxxxxxxxxxx> > > Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > Cc: Jani Nikula <jani.nikula@xxxxxxxxx> > > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx> > > --- > > drivers/gpu/drm/i915/intel_display.c | 20 ++++++++++---------- > > drivers/gpu/drm/i915/intel_dp.c | 13 ++++++------- > > drivers/gpu/drm/i915/intel_drv.h | 2 +- > > 3 files changed, 17 insertions(+), 18 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > > index 82796d1a87d7..0be8cede60e3 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/intel_display.c > > @@ -14642,6 +14642,8 @@ static void intel_setup_outputs(struct drm_device *dev) > > if (I915_READ(PCH_DP_D) & DP_DETECTED) > > intel_dp_init(dev, PCH_DP_D, PORT_D); > > } else if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) { > > + bool has_edp; > > + > > /* > > * The DP_DETECTED bit is the latched state of the DDC > > * SDA pin at boot. However since eDP doesn't require DDC > > @@ -14651,19 +14653,17 @@ static void intel_setup_outputs(struct drm_device *dev) > > * eDP ports. Consult the VBT as well as DP_DETECTED to > > * detect eDP ports. > > */ > > - if (I915_READ(VLV_HDMIB) & SDVO_DETECTED && > > - !intel_dp_is_edp(dev, PORT_B)) > > + has_edp = intel_dp_is_edp(dev, PORT_B); > > + if (I915_READ(VLV_DP_B) & DP_DETECTED || has_edp) > > + has_edp &= intel_dp_init(dev, VLV_DP_B, PORT_B); > > + if (I915_READ(VLV_HDMIB) & SDVO_DETECTED && !has_edp) > > intel_hdmi_init(dev, VLV_HDMIB, PORT_B); > > - if (I915_READ(VLV_DP_B) & DP_DETECTED || > > - intel_dp_is_edp(dev, PORT_B)) > > - intel_dp_init(dev, VLV_DP_B, PORT_B); > > This will change the order in which the connectors/encoders are > registered. Shouldn't really matter. We use the DP,HDMI order on > some other platforms as well. I wonder if we should change everything > to use that order for consistency? I'm tempted to, just to solve the same problem of false eDP disabling valid outputs on other platforms, e.g. ivb. However, changing the order feels like a "it can't possibly break anything, but does!" situation, so gradual is best. Certainly, on the older sdvo chipsets, the order is more constrained, but on the ddi platforms where hdmi/dp are interchangeable, it should be flexible. > Also if the eDP init fails we'll not register a regular DP port, but > that's sort of OK since our eDP init doesn't actually check if the sink > is really eDP. Instead it just checks that DPCD can be read. So if we > would have a board with a normal user accesible DP connector which the > VBT claims to be eDP, we'd run into some hilarity when the user boots > w/o a display connected, yanks the cable after boot, or hotplugs in > another display. But I'm thinking we can just ignore that scenario > until we encounter such a board. Right. That we could probably resolve just by dropping the dp->is_edp flag if intel_edp_init_connector fails and just leaving the connector established for DP - but only if it is reported as detected (rather than the VBT override). Then we would change the HDMI setup to only ignore known eDP links (for which we would need a stronger is-eDP verification). The challenge is "who would this regress"? The older bug is https://bugs.freedesktop.org/show_bug.cgi?id=88331 if anyone feels inspired on handling HDMI vs eDP vs DP more consistently between platforms (if that is even possible!). -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
