From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Jackson Subject: Re: Valid DP connection without EDID? Date: Tue, 18 Sep 2012 10:04:33 -0400 Message-ID: <1347977073.25266.78.camel@atropine> References: <50534C4F.6020607@redhat.com> <1347899076.25266.46.camel@atropine> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0504906363==" Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by gabe.freedesktop.org (Postfix) with ESMTP id 15D84A08EF for ; Tue, 18 Sep 2012 07:04:37 -0700 (PDT) In-Reply-To: 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: Takashi Iwai Cc: mmarek@suse.cz, intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============0504906363== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-dqdaZkHwu+9VUHBgreNn" --=-dqdaZkHwu+9VUHBgreNn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. >=20 > Thanks! I evaluated it now (with a typo fix suggested by Jani). > Unfortunately, it doesn't improve the situation. >=20 > 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: =3D=3D=3D diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_d= p.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) =20 if (!intel_dp_get_dpcd(intel_dp)) return connector_status_disconnected; - =20 + /* if there's no downstream port, we're done */ if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT)) return connector_status_connected; =20 /* If we're HPD-aware, SINK_COUNT changes dynamically */ hpd =3D !!(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 &=3D DP_SINK_COUNT_MASK; + return sink_count ? connector_status_connected + : connector_status_disconnected; + } =20 /* If no HPD, poke DDC gently */ if (drm_probe_ddc(&intel_dp->adapter)) =3D=3D=3D 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 --=-dqdaZkHwu+9VUHBgreNn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAlBYf3IACgkQW4otUKDs0NMbbwCdEYe5ReK20p/VuHN/nhuAYS/3 klkAnjy57SgUjwiiOYizBwoQ4/HMs4Xq =nSNI -----END PGP SIGNATURE----- --=-dqdaZkHwu+9VUHBgreNn-- --===============0504906363== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============0504906363==--