Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754658AbbHXNrz (ORCPT ); Mon, 24 Aug 2015 09:47:55 -0400 Received: from mail-qg0-f44.google.com ([209.85.192.44]:33748 "EHLO mail-qg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754273AbbHXNrw (ORCPT ); Mon, 24 Aug 2015 09:47:52 -0400 Date: Mon, 24 Aug 2015 09:47:41 -0400 From: Jerome Glisse To: cpaul@redhat.com Cc: Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , David Airlie , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Jerome Glisse , Benjamin Tissoires , stable@vger.kernel.org Subject: Re: [PATCH] DRM - radeon: Don't link train DisplayPort on HPD until we get the dpcd Message-ID: <20150824134740.GA1941@gmail.com> References: <1440180972-29580-1-git-send-email-cpaul@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1440180972-29580-1-git-send-email-cpaul@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3573 Lines: 82 On Fri, Aug 21, 2015 at 02:16:12PM -0400, cpaul@redhat.com wrote: > From: Stephen Chandler Paul > > Most of the time this isn't an issue since hotplugging an adaptor will > trigger a crtc mode change which in turn, causes the driver to probe > every DisplayPort for a dpcd. However, in cases where hotplugging > doesn't cause a mode change (specifically when one unplugs a monitor > from a DisplayPort connector, then plugs that same monitor back in > seconds later on the same port without any other monitors connected), we > never probe for the dpcd before starting the initial link training. What > happens from there looks like this: > > - GPU has only one monitor connected. It's connected via > DisplayPort, and does not go through an adaptor of any sort. > > - User unplugs DisplayPort connector from GPU. > > - Change in HPD is detected by the driver, we probe every > DisplayPort for a possible connection. > > - Probe the port the user originally had the monitor connected > on for it's dpcd. This fails, and we clear the first (and only > the first) byte of the dpcd to indicate we no longer have a > dpcd for this port. > > - User plugs the previously disconnected monitor back into the > same DisplayPort. > > - radeon_connector_hotplug() is called before everyone else, > and tries to handle the link training. Since only the first > byte of the dpcd is zeroed, the driver is able to complete > link training but does so against the wrong dpcd, causing it > to initialize the link with the wrong settings. > > - Display stays blank (usually), dpcd is probed after the > initial link training, and the driver prints no obvious > messages to the log. > > In theory, since only one byte of the dpcd is chopped off (specifically, > the byte that contains the revision information for DisplayPort), it's > not entirely impossible that this bug may not show on certain monitors. > For instance, the only reason this bug was visible on my ASUS PB238 > monitor was due to the fact that this monitor using the enhanced framing > symbol sequence, the flag for which is ignored if the radeon driver > thinks that the DisplayPort version is below 1.1. > > Signed-off-by: Stephen Chandler Paul > Reviewed-by: Jerome Glisse This should be added to stable cc: > --- > drivers/gpu/drm/radeon/radeon_connectors.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c > index 94b21ae..5a2cafb 100644 > --- a/drivers/gpu/drm/radeon/radeon_connectors.c > +++ b/drivers/gpu/drm/radeon/radeon_connectors.c > @@ -95,6 +95,11 @@ void radeon_connector_hotplug(struct drm_connector *connector) > if (!radeon_hpd_sense(rdev, radeon_connector->hpd.hpd)) { > drm_helper_connector_dpms(connector, DRM_MODE_DPMS_OFF); > } else if (radeon_dp_needs_link_train(radeon_connector)) { > + /* Don't try to start link training before we > + * have the dpcd */ > + if (!radeon_dp_getdpcd(radeon_connector)) > + return; > + > /* set it to OFF so that drm_helper_connector_dpms() > * won't return immediately since the current state > * is ON at this point. > -- > 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/