From: "Deucher, Alexander" <Alexander.Deucher@amd.com>
To: Jerome Glisse <j.glisse@gmail.com>, "cpaul@redhat.com" <cpaul@redhat.com>
CC: "Koenig, Christian" <Christian.Koenig@amd.com>,
        David Airlie <airlied@linux.ie>,
        "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Jerome Glisse <jglisse@redhat.com>,
        "Benjamin Tissoires" <benjamin.tissoires@redhat.com>,
        "stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH] DRM - radeon: Don't link train DisplayPort on HPD until
 we get the dpcd
Thread-Topic: [PATCH] DRM - radeon: Don't link train DisplayPort on HPD
 until we get the dpcd
Thread-Index: AQHQ3D2aryCAxWOUb0yLAvdnXj+rjp4bcXeA//+9gvA=
Date: Mon, 24 Aug 2015 13:50:11 +0000
Message-ID: <A3397C8B8B789E45844E7EC5DEAD89D06E8FDC38@satlexdag05.amd.com>
References: <1440180972-29580-1-git-send-email-cpaul@redhat.com>
 <20150824134740.GA1941@gmail.com>
In-Reply-To: <20150824134740.GA1941@gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Aug 2015 13:50:13.9796
 (UTC)
X-MS-Exchange-CrossTenant-Id: fde4dada-be84-483f-92cc-e026cbee8e96
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=fde4dada-be84-483f-92cc-e026cbee8e96;Ip=[165.204.84.222];Helo=[atltwp02.amd.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR02MB1152
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 4228
Lines: 106

> -----Original Message-----
> From: Jerome Glisse [mailto:j.glisse@gmail.com]
> Sent: Monday, August 24, 2015 9:48 AM
> To: cpaul@redhat.com
> Cc: Deucher, Alexander; Koenig, Christian; 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
> 
> On Fri, Aug 21, 2015 at 02:16:12PM -0400, cpaul@redhat.com wrote:
> > From: Stephen Chandler Paul <cpaul@redhat.com>
> >
> > 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 <cpaul@redhat.com>
> > Reviewed-by: Jerome Glisse <jglisse@redhat.com>
> 
> This should be added to stable
> 
> cc: <stable@vger.kernel.org>
> 

I already added that when I pulled it into my tree :)

Thanks,

Alex

> 
> 
> > ---
> >  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/