[Intel-gfx] Valid DP connection without EDID?

Takashi Iwai tiwai at suse.de
Mon Sep 17 10:16:49 CEST 2012


Hi Adam,

At Fri, 14 Sep 2012 11:25:03 -0400,
Adam Jackson wrote:
> 
> On 9/14/12 10:19 AM, Takashi Iwai wrote:
> > Hi,
> >
> > we've got a machine showing a ghost DP2 output on a docking station.
> > The docking station has only one DP port and it's connected to DP1.
> > As a result, we get an DP2 active output containing the bogus VESA
> > standard modes 1024x768, 800x600, 640x480 although it's not connected
> > at all.
> >
> > Looking a bit deeply on it, it seems that the connector gives actually
> > the valid DPCD.  So intel_dp_detect() returns
> > connector_status_connected.  But since there is no real connection,
> > EDID isn't obtained.  Thus of course no valid modes set.
> 
> Can you be more specific here?  What DPCD does it return?

It shows "DPCD: 110a820100030181"

> Does it claim 
> to be a branch device?  We don't currently get that case right, try for 
> instance plugging in a DP->VGA pigtail.
 
Well, the port doesn't exist physically at all.  The docking station
has only one physical DP output although it exposes two.  (And the
machine has one another built-in DP port as DP3, but it works well.)

So it's definitely a hardware problem.  But we can still work around
it.

> > A quick patch below adds (moves) a check of EDID and returns the
> > disconnected state when no valid EDID is returned.  An open question
> > is whether this is really safe.  Is there any case where no valid EDID
> > is returned but the connection is still valid?
> 
> DisplayPort requires EDID.  There may be a platform method for obtaining 
> it for eDP, but for normal DP it has to exist over AUXCH.
> 
> DVI and HDMI require it too, in fact.  The only one that doesn't is VGA.

OK, so a workaround like my patch (just checking the validity of EDID)
won't bring regressions in theory?


thanks,

Takashi



More information about the Intel-gfx mailing list