* Valid DP connection without EDID? @ 2012-09-14 14:19 Takashi Iwai 2012-09-14 15:25 ` Adam Jackson 0 siblings, 1 reply; 13+ messages in thread From: Takashi Iwai @ 2012-09-14 14:19 UTC (permalink / raw) To: intel-gfx; +Cc: mmarek 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. 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? 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; } ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: Valid DP connection without EDID? 2012-09-14 14:19 Valid DP connection without EDID? Takashi Iwai @ 2012-09-14 15:25 ` Adam Jackson 2012-09-17 8:16 ` Takashi Iwai 0 siblings, 1 reply; 13+ messages in thread From: Adam Jackson @ 2012-09-14 15:25 UTC (permalink / raw) To: Takashi Iwai; +Cc: mmarek, intel-gfx 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Valid DP connection without EDID? 2012-09-14 15:25 ` Adam Jackson @ 2012-09-17 8:16 ` Takashi Iwai 2012-09-17 8:21 ` Dave Airlie 0 siblings, 1 reply; 13+ messages in thread From: Takashi Iwai @ 2012-09-17 8:16 UTC (permalink / raw) To: Adam Jackson; +Cc: mmarek, intel-gfx 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Valid DP connection without EDID? 2012-09-17 8:16 ` Takashi Iwai @ 2012-09-17 8:21 ` Dave Airlie 2012-09-17 8:28 ` Takashi Iwai 0 siblings, 1 reply; 13+ messages in thread From: Dave Airlie @ 2012-09-17 8:21 UTC (permalink / raw) To: Takashi Iwai; +Cc: mmarek, intel-gfx 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Valid DP connection without EDID? 2012-09-17 8:21 ` Dave Airlie @ 2012-09-17 8:28 ` Takashi Iwai 2012-09-17 9:11 ` Dave Airlie 0 siblings, 1 reply; 13+ messages in thread From: Takashi Iwai @ 2012-09-17 8:28 UTC (permalink / raw) To: Dave Airlie; +Cc: mmarek, intel-gfx 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Valid DP connection without EDID? 2012-09-17 8:28 ` Takashi Iwai @ 2012-09-17 9:11 ` Dave Airlie 2012-09-17 9:32 ` Takashi Iwai 0 siblings, 1 reply; 13+ messages in thread From: Dave Airlie @ 2012-09-17 9:11 UTC (permalink / raw) To: Takashi Iwai; +Cc: mmarek, intel-gfx 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Valid DP connection without EDID? 2012-09-17 9:11 ` Dave Airlie @ 2012-09-17 9:32 ` Takashi Iwai 2012-09-17 16:24 ` Adam Jackson 0 siblings, 1 reply; 13+ messages in thread From: Takashi Iwai @ 2012-09-17 9:32 UTC (permalink / raw) To: Dave Airlie; +Cc: mmarek, intel-gfx 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Valid DP connection without EDID? 2012-09-17 9:32 ` Takashi Iwai @ 2012-09-17 16:24 ` Adam Jackson 2012-09-18 11:01 ` Takashi Iwai 0 siblings, 1 reply; 13+ messages in thread From: Adam Jackson @ 2012-09-17 16:24 UTC (permalink / raw) To: Takashi Iwai; +Cc: mmarek, intel-gfx [-- Attachment #1.1: Type: text/plain, Size: 1905 bytes --] 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 [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Valid DP connection without EDID? 2012-09-17 16:24 ` Adam Jackson @ 2012-09-18 11:01 ` Takashi Iwai 2012-09-18 14:04 ` Adam Jackson 0 siblings, 1 reply; 13+ messages in thread From: Takashi Iwai @ 2012-09-18 11:01 UTC (permalink / raw) To: Adam Jackson; +Cc: mmarek, intel-gfx 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Valid DP connection without EDID? 2012-09-18 11:01 ` Takashi Iwai @ 2012-09-18 14:04 ` Adam Jackson 2012-09-18 14:32 ` Takashi Iwai 0 siblings, 1 reply; 13+ messages in thread From: Adam Jackson @ 2012-09-18 14:04 UTC (permalink / raw) To: Takashi Iwai; +Cc: mmarek, intel-gfx [-- Attachment #1.1: Type: text/plain, Size: 2717 bytes --] On Tue, 2012-09-18 at 13:01 +0200, Takashi Iwai wrote: > > 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. Sorry, there's a bug in the patch. link_configuration[0] is not DP_SINK_COUNT, I have no idea why I thought it was. Try this on top of the series: === diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 9809c53..b6b9a18 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -2098,15 +2098,22 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp) if (!intel_dp_get_dpcd(intel_dp)) return connector_status_disconnected; - + /* if there's no downstream port, we're done */ if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT)) return connector_status_connected; /* If we're HPD-aware, SINK_COUNT changes dynamically */ hpd = !!(intel_dp->downstream_ports[0] & DP_DS_PORT_HPD); - if (hpd && (intel_dp->link_configuration[0] & DP_SINK_COUNT_MASK)) - return connector_status_connected; + if (hpd) { + uint8_t sink_count; + if (!intel_dp_aux_native_read_retry(intel_dp, DP_SINK_COUNT, + &sink_count, 1)) + return connector_status_unknown; + sink_count &= DP_SINK_COUNT_MASK; + return sink_count ? connector_status_connected + : connector_status_disconnected; + } /* If no HPD, poke DDC gently */ if (drm_probe_ddc(&intel_dp->adapter)) === If that doesn't work then the HPD-capable bit is useless - or if we're lucky just needs quirking by branch OUI - and we should just fall through to the drm_probe_ddc() path. What is the branch OUI, anyway? There's a third possibility, which is that HPD does work but that we're not doing enough to enable it. The DP 1.1a spec has a non-normative appendix describing one way a device could go about doing that as an optional feature, but the method described does not match how we're currently handling sink-specific IRQs. I have no idea what the 1.2 spec says on this point though. - ajax [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: Valid DP connection without EDID? 2012-09-18 14:04 ` Adam Jackson @ 2012-09-18 14:32 ` Takashi Iwai 2012-09-18 14:48 ` Adam Jackson 0 siblings, 1 reply; 13+ messages in thread From: Takashi Iwai @ 2012-09-18 14:32 UTC (permalink / raw) To: Adam Jackson; +Cc: mmarek, intel-gfx At Tue, 18 Sep 2012 10:04:33 -0400, Adam Jackson wrote: > > On Tue, 2012-09-18 at 13:01 +0200, Takashi Iwai wrote: > > > > 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. > > Sorry, there's a bug in the patch. link_configuration[0] is not > DP_SINK_COUNT, I have no idea why I thought it was. Try this on top of > the series: > > === > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 9809c53..b6b9a18 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -2098,15 +2098,22 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp) > > if (!intel_dp_get_dpcd(intel_dp)) > return connector_status_disconnected; > - > + > /* if there's no downstream port, we're done */ > if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT)) > return connector_status_connected; > > /* If we're HPD-aware, SINK_COUNT changes dynamically */ > hpd = !!(intel_dp->downstream_ports[0] & DP_DS_PORT_HPD); > - if (hpd && (intel_dp->link_configuration[0] & DP_SINK_COUNT_MASK)) > - return connector_status_connected; > + if (hpd) { > + uint8_t sink_count; > + if (!intel_dp_aux_native_read_retry(intel_dp, DP_SINK_COUNT, > + &sink_count, 1)) > + return connector_status_unknown; > + sink_count &= DP_SINK_COUNT_MASK; > + return sink_count ? connector_status_connected > + : connector_status_disconnected; > + } > > /* If no HPD, poke DDC gently */ > if (drm_probe_ddc(&intel_dp->adapter)) > === Woohoo, the patch works! This also avoids the driver spewing tons of error messages [drm:intel_dp_i2c_aux_ch] *ERROR* too many retries, giving up and [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting I guess it's because now the driver detects the disconnection properly. The hotplug / -unplug also seems working. Could you brush up and resend the patches for merging to 3.7 kernel? Or, would you like to fix the multiple branch devices first? When you resubmit patches, feel free to add: Tested-by: Takashi Iwai <tiwai@suse.de> Thanks! Takashi > If that doesn't work then the HPD-capable bit is useless - or if we're > lucky just needs quirking by branch OUI - and we should just fall > through to the drm_probe_ddc() path. What is the branch OUI, anyway? > > There's a third possibility, which is that HPD does work but that we're > not doing enough to enable it. The DP 1.1a spec has a non-normative > appendix describing one way a device could go about doing that as an > optional feature, but the method described does not match how we're > currently handling sink-specific IRQs. I have no idea what the 1.2 spec > says on this point though. > > - ajax ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Valid DP connection without EDID? 2012-09-18 14:32 ` Takashi Iwai @ 2012-09-18 14:48 ` Adam Jackson 2012-09-18 15:11 ` Takashi Iwai 0 siblings, 1 reply; 13+ messages in thread From: Adam Jackson @ 2012-09-18 14:48 UTC (permalink / raw) To: Takashi Iwai; +Cc: mmarek, intel-gfx [-- Attachment #1.1: Type: text/plain, Size: 989 bytes --] On Tue, 2012-09-18 at 16:32 +0200, Takashi Iwai wrote: > Woohoo, the patch works! \o/ > Could you brush up and resend the patches for merging to 3.7 kernel? > Or, would you like to fix the multiple branch devices first? I'm not too worried about branch devices with multiple downstreams just yet. I don't know of any you can buy anyway. Even if you could there's some open questions about how we'd present them to the user, and the whole concept will need rethinking once we get multiple-stream support. The only case I can think of where this might not work sanely is an active DP->HDMI adaptor with sinks for both audio and video? But again, I don't think those exist. If they do you'd expect both the A and V sinks to plug simultaneously, so sink count should always be either zero or non-zero, so it should work anyway. > When you resubmit patches, feel free to add: > Tested-by: Takashi Iwai <tiwai@suse.de> Will do, thanks for testing! - ajax [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Valid DP connection without EDID? 2012-09-18 14:48 ` Adam Jackson @ 2012-09-18 15:11 ` Takashi Iwai 0 siblings, 0 replies; 13+ messages in thread From: Takashi Iwai @ 2012-09-18 15:11 UTC (permalink / raw) To: Adam Jackson; +Cc: mmarek, intel-gfx At Tue, 18 Sep 2012 10:48:11 -0400, Adam Jackson wrote: > > On Tue, 2012-09-18 at 16:32 +0200, Takashi Iwai wrote: > > > Woohoo, the patch works! > > \o/ > > > Could you brush up and resend the patches for merging to 3.7 kernel? > > Or, would you like to fix the multiple branch devices first? > > I'm not too worried about branch devices with multiple downstreams just > yet. I don't know of any you can buy anyway. Even if you could there's > some open questions about how we'd present them to the user, and the > whole concept will need rethinking once we get multiple-stream support. > > The only case I can think of where this might not work sanely is an > active DP->HDMI adaptor with sinks for both audio and video? But again, > I don't think those exist. If they do you'd expect both the A and V > sinks to plug simultaneously, so sink count should always be either zero > or non-zero, so it should work anyway. FWIW, I tried an active DP->DVI adapter, and it seems working, too. But the sink count is 1, so it doesn't look like A+V sinks. Takashi ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2012-09-18 15:11 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-09-14 14:19 Valid DP connection without EDID? Takashi Iwai 2012-09-14 15:25 ` Adam Jackson 2012-09-17 8:16 ` Takashi Iwai 2012-09-17 8:21 ` Dave Airlie 2012-09-17 8:28 ` Takashi Iwai 2012-09-17 9:11 ` Dave Airlie 2012-09-17 9:32 ` Takashi Iwai 2012-09-17 16:24 ` Adam Jackson 2012-09-18 11:01 ` Takashi Iwai 2012-09-18 14:04 ` Adam Jackson 2012-09-18 14:32 ` Takashi Iwai 2012-09-18 14:48 ` Adam Jackson 2012-09-18 15:11 ` Takashi Iwai
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.