From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Valid DP connection without EDID? Date: Mon, 17 Sep 2012 10:16:49 +0200 Message-ID: References: <50534C4F.6020607@redhat.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by gabe.freedesktop.org (Postfix) with ESMTP id 5B18C9E9AE for ; Mon, 17 Sep 2012 01:16:50 -0700 (PDT) In-Reply-To: <50534C4F.6020607@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Adam Jackson Cc: mmarek@suse.cz, intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org 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