| Message ID | s5hr4q4znyt.wl%tiwai@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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? 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. > 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. - ajax
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
On Mon, Sep 17, 2012 at 6:16 PM, Takashi Iwai <tiwai@suse.de> wrote: > 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" I don't see how it can be a floating port if something is answering DPCD, or how it could be a hardware problem. Like it doesn't seem likely they terminated the port with a special DP chip. Though you'd have to decode the DPCD to see what it is. Dave.
At Mon, 17 Sep 2012 18:21:47 +1000, Dave Airlie wrote: > > On Mon, Sep 17, 2012 at 6:16 PM, Takashi Iwai <tiwai@suse.de> wrote: > > 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" > > I don't see how it can be a floating port if something is answering > DPCD, or how it could be a hardware problem. Like it doesn't seem > likely they terminated the port with a special DP chip. The problem is that you have no DP output there in reality. So, when you plug the docking station, GNOME sets up the screen with a bogus DP output, either in an extended mode with a non-existing screen or a clone mode with a wrong low resolution. > Though you'd have to decode the DPCD to see what it is. Hmm, but isn't it the check of EDID existence enough? Checking DPCD bits might work, but I have no exact spec of DPCD, so no idea whether the above is really wrong or not. thanks, Takashi
On Mon, Sep 17, 2012 at 6:28 PM, Takashi Iwai <tiwai@suse.de> wrote: > At Mon, 17 Sep 2012 18:21:47 +1000, > Dave Airlie wrote: >> >> On Mon, Sep 17, 2012 at 6:16 PM, Takashi Iwai <tiwai@suse.de> wrote: >> > 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" >> >> I don't see how it can be a floating port if something is answering >> DPCD, or how it could be a hardware problem. Like it doesn't seem >> likely they terminated the port with a special DP chip. > > The problem is that you have no DP output there in reality. So, when > you plug the docking station, GNOME sets up the screen with a bogus DP > output, either in an extended mode with a non-existing screen or a > clone mode with a wrong low resolution. Yes I understand the problem, I'm disagreeing with your diagnosis of what the problem is, since DPCD response means something is there. DPCD comes from the other end of the cable. > >> Though you'd have to decode the DPCD to see what it is. > > Hmm, but isn't it the check of EDID existence enough? No thats a hack, that we might use, but I can't imagine a DP->VGA with a EDID-less VGA device producing an EDID, whereas it will produce a DPCD. > Checking DPCD bits might work, but I have no exact spec of DPCD, so no > idea whether the above is really wrong or not. Is there a VGA port on the docking station, it might have a DP->VGA in it, or dual-link DVI port. Dave.
At Mon, 17 Sep 2012 19:11:34 +1000, Dave Airlie wrote: > > On Mon, Sep 17, 2012 at 6:28 PM, Takashi Iwai <tiwai@suse.de> wrote: > > At Mon, 17 Sep 2012 18:21:47 +1000, > > Dave Airlie wrote: > >> > >> On Mon, Sep 17, 2012 at 6:16 PM, Takashi Iwai <tiwai@suse.de> wrote: > >> > 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" > >> > >> I don't see how it can be a floating port if something is answering > >> DPCD, or how it could be a hardware problem. Like it doesn't seem > >> likely they terminated the port with a special DP chip. > > > > The problem is that you have no DP output there in reality. So, when > > you plug the docking station, GNOME sets up the screen with a bogus DP > > output, either in an extended mode with a non-existing screen or a > > clone mode with a wrong low resolution. > > Yes I understand the problem, I'm disagreeing with your diagnosis of > what the problem is, since DPCD response means something is there. > DPCD comes from the other end of the cable. > > > >> Though you'd have to decode the DPCD to see what it is. > > > > Hmm, but isn't it the check of EDID existence enough? > > No thats a hack, that we might use, but I can't imagine a DP->VGA with > a EDID-less VGA device producing an EDID, whereas it will produce a > DPCD. > > > Checking DPCD bits might work, but I have no exact spec of DPCD, so no > > idea whether the above is really wrong or not. > > Is there a VGA port on the docking station, it might have a DP->VGA in > it, or dual-link DVI port. Ah, right, that's the missing piece! It's a DP->VGA conversion indeed. Plugging to a VGA connector appears as DP2. Oh well, I didn't think of this possibility at all. But then this makes me wonder how to solve the problem at best. It's obviously a bogus connection status returned from the driver. DP2 advertises itself as if connected. To summarize the behavior: - When a docking station is plugged without VGA cable, kernel gives the following error and provides DP2 with 1024x768: [ 2.934754] [drm:intel_dp_i2c_aux_ch] *ERROR* too many retries, giving up [ 2.937324] [drm:intel_dp_i2c_aux_ch] *ERROR* too many retries, giving up .... [ 3.998943] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting - Now plug a VGA cable, kernel gives the following error repeatedly [ 14.298251] [drm:intel_dp_i2c_aux_ch] *ERROR* too many retries, giving up [ 14.300791] [drm:intel_dp_i2c_aux_ch] *ERROR* too many retries, giving up and doesn't give proper modes. - When you unplug and plug again the docking station with VGA cable plugged, it probes the right modes. xranr gives: DP2 connected 1920x1080+1366+0 (normal left inverted right x axis y axis) 510mm x 287mm 1920x1080 60.0*+ 1680x1050 60.0 1680x945 60.0 1400x1050 74.9 60.0 1600x900 60.0 1280x1024 75.0 60.0 1440x900 75.0 59.9 1280x960 60.0 1366x768 60.0 1360x768 60.0 1280x800 74.9 59.8 1152x864 75.0 1280x768 74.9 59.9 1280x720 60.0 1024x768 75.1 70.1 60.0 1024x576 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 848x480 60.0 640x480 72.8 75.0 66.7 60.0 720x400 70.1 DP3 disconnected (normal left inverted right x axis y axis) - Then unplug the VGA cable, it goes back to the old bogus modes. DP2 connected 1920x1080+1366+0 (normal left inverted right x axis y axis) 510mm x 287mm 1024x768 60.0 800x600 60.3 56.2 848x480 60.0 640x480 59.9 DP3 disconnected (normal left inverted right x axis y axis) 1920x1080 (0xd7) 148.5MHz h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.5KHz v: height 1080 start 1084 end 1089 total 1125 clock 60.0Hz (This time DP3 shows also a strange state. It must be some side effect of the failed probe...) Takashi
On Mon, 2012-09-17 at 11:32 +0200, Takashi Iwai wrote: > At Mon, 17 Sep 2012 19:11:34 +1000, > Dave Airlie wrote: > > On Mon, Sep 17, 2012 at 6:28 PM, Takashi Iwai <tiwai@suse.de> wrote: > > > At Mon, 17 Sep 2012 18:21:47 +1000, > > > Dave Airlie wrote: > > >> On Mon, Sep 17, 2012 at 6:16 PM, Takashi Iwai <tiwai@suse.de> wrote: > > >> > At Fri, 14 Sep 2012 11:25:03 -0400, > > >> > Adam Jackson wrote: > > >> >> > > >> >> Can you be more specific here? What DPCD does it return? > > >> > > > >> > It shows "DPCD: 110a820100030181" So dpcd[0x5] is 0x03, and drm_dp_helper.h says: #define DP_DOWNSTREAMPORT_PRESENT 0x005 # define DP_DWN_STRM_PORT_PRESENT (1 << 0) # define DP_DWN_STRM_PORT_TYPE_MASK 0x06 /* 00b = DisplayPort */ /* 01b = Analog */ /* 10b = TMDS or HDMI */ /* 11b = Other */ # define DP_FORMAT_CONVERSION (1 << 3) So there we go, it's a branch device with VGA downstream of it. We need to figure out the connectivity of the downstream port. > > > Checking DPCD bits might work, but I have no exact spec of DPCD, so no > > > idea whether the above is really wrong or not. > > > > Is there a VGA port on the docking station, it might have a DP->VGA in > > it, or dual-link DVI port. > > Ah, right, that's the missing piece! > > It's a DP->VGA conversion indeed. Plugging to a VGA connector appears > as DP2. Oh well, I didn't think of this possibility at all. > > But then this makes me wonder how to solve the problem at best. > It's obviously a bogus connection status returned from the driver. > DP2 advertises itself as if connected. I wouldn't quite say it's bogus, more that we're describing the connection status of "the nearest DP device" as if it were the connection status of the whole wire. I started a patch series for this a bit ago, I'll send it on momentarily. - ajax
At Mon, 17 Sep 2012 12:24:36 -0400, Adam Jackson wrote: > > On Mon, 2012-09-17 at 11:32 +0200, Takashi Iwai wrote: > > At Mon, 17 Sep 2012 19:11:34 +1000, > > Dave Airlie wrote: > > > On Mon, Sep 17, 2012 at 6:28 PM, Takashi Iwai <tiwai@suse.de> wrote: > > > > At Mon, 17 Sep 2012 18:21:47 +1000, > > > > Dave Airlie wrote: > > > >> On Mon, Sep 17, 2012 at 6:16 PM, Takashi Iwai <tiwai@suse.de> wrote: > > > >> > At Fri, 14 Sep 2012 11:25:03 -0400, > > > >> > Adam Jackson wrote: > > > >> >> > > > >> >> Can you be more specific here? What DPCD does it return? > > > >> > > > > >> > It shows "DPCD: 110a820100030181" > > So dpcd[0x5] is 0x03, and drm_dp_helper.h says: > > #define DP_DOWNSTREAMPORT_PRESENT 0x005 > # define DP_DWN_STRM_PORT_PRESENT (1 << 0) > # define DP_DWN_STRM_PORT_TYPE_MASK 0x06 > /* 00b = DisplayPort */ > /* 01b = Analog */ > /* 10b = TMDS or HDMI */ > /* 11b = Other */ > # define DP_FORMAT_CONVERSION (1 << 3) > > So there we go, it's a branch device with VGA downstream of it. We need > to figure out the connectivity of the downstream port. Right. It's indeed a VGA. > > > > Checking DPCD bits might work, but I have no exact spec of DPCD, so no > > > > idea whether the above is really wrong or not. > > > > > > Is there a VGA port on the docking station, it might have a DP->VGA in > > > it, or dual-link DVI port. > > > > Ah, right, that's the missing piece! > > > > It's a DP->VGA conversion indeed. Plugging to a VGA connector appears > > as DP2. Oh well, I didn't think of this possibility at all. > > > > But then this makes me wonder how to solve the problem at best. > > It's obviously a bogus connection status returned from the driver. > > DP2 advertises itself as if connected. > > I wouldn't quite say it's bogus, more that we're describing the > connection status of "the nearest DP device" as if it were the > connection status of the whole wire. True. However, from the end user's perspective, it's not easily understandable why it's DP2 although we know it's a VGA and why it's constantly stated as connected. Or, just think from the user-space POV. The only information it gets so far is it's "DP-2", and it's always connected without EDID. It's a bit too little information to make apps judging the situation correctly. Something should be corrected, or the driver needs to expose more information. > I started a patch series for this a bit ago, I'll send it on > momentarily. Thanks! I evaluated it now (with a typo fix suggested by Jani). Unfortunately, it doesn't improve the situation. The fetch of downstream ports succeeds, and it gets 0x09. So, this indicates again it's a VGA downstream port. But that's all, so far. The 0x09 is reported no matter whether the VGA cable is plugged or not, so this can't be used as the detection of the downstream port plug state. Any alternative way to detect the downstream VGA plug state? thanks, Takashi
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index a6c426a..144da02 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -2200,16 +2200,17 @@ intel_dp_detect(struct drm_connector *connector, bool force) intel_dp_probe_oui(intel_dp); + edid = intel_dp_get_edid(connector, &intel_dp->adapter); + if (!edid) + return connector_status_disconnected; + if (intel_dp->force_audio != HDMI_AUDIO_AUTO) { intel_dp->has_audio = (intel_dp->force_audio == HDMI_AUDIO_ON); } else { - edid = intel_dp_get_edid(connector, &intel_dp->adapter); - if (edid) { - intel_dp->has_audio = drm_detect_monitor_audio(edid); - connector->display_info.raw_edid = NULL; - kfree(edid); - } + intel_dp->has_audio = drm_detect_monitor_audio(edid); } + connector->display_info.raw_edid = NULL; + kfree(edid); return connector_status_connected; }