Radeon Verde displayport failure.

Commit Message

Dave Jones May 15, 2015, 3:52 a.m. UTC

On Thu, May 14, 2015 at 09:49:52AM -0400, Alex Deucher wrote:
 > On Tue, May 12, 2015 at 8:04 PM, Dave Jones <[e-mail]> wrote:
 > > On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:
 > >
 > >  > > I tried tweaking the delays in drm_dp_link_train_clock_recovery_delay, without any noticable
 > >  > > difference.  Is there something else I can try to make it try harder before giving up?
 > >  > >
 > >  >
 > >  > Can you attach your boot dmesg output with drm.debug=0xf set?
 > >  >
 > >  > You might also check the dpcd values in the driver during boot up and
 > >  > link training.  There appears to be an issue where that data gets
 > >  > corrupted in some cases:
 > >  > https://bugs.freedesktop.org/show_bug.cgi?id=73530
 > >
 > > I tried both the 'disable spread spectrum' and 'grab dpcd info from vbios for eDP'
 > > patches from that bug. Again, no obvious difference.
 > >
 > > Log from kernel with both applied attached.
 > >
 > > Also a log file from after I woke up the LCD when it was in sleep mode.
 > >
 > > Something else curious is how it only discovers a maximum mode from the LCD
 > > of 1024x768.
 > 
 > I looks like the monitor is not responding.  I'm not entirely sure
 > what's going on.  I posted a new debugging patch on the bug report
 > that will dump the dpcd at various times to see if and when it's
 > getting corrupt.  Fixing that should at least get the monitor to come
 > up reliably (assuming you are experiencing the same issue).
 
Thanks to some back-and-forth on irc, airlied got this mostly working.
The working combo seems to be..

- Switch monitor to DP 1.2
- boot with radeon.mst=1
- apply the patch below

With all that, it boots up, and X starts up in 2560x1440 like it should.

The only remaining problem is there are some visible glitches, mostly noticable
while scrolling a terminal.

Happy to continue applying further debug patches if you have any more ideas.

thanks,
	Dave

Comments

Michel Dänzer May 15, 2015, 9:16 a.m. UTC | #1

On 15.05.2015 12:52, Dave Jones wrote:
> 
> The only remaining problem is there are some visible glitches, mostly noticable
> while scrolling a terminal.

What kind of glitches? If it's tearing, with current xf86-video-ati Git
you can try Option "TearFree".

Dave Jones May 15, 2015, 12:44 p.m. UTC | #2

On Fri, May 15, 2015 at 06:16:59PM +0900, Michel Dänzer wrote:
 > On 15.05.2015 12:52, Dave Jones wrote:
 > > 
 > > The only remaining problem is there are some visible glitches, mostly noticable
 > > while scrolling a terminal.
 > 
 > What kind of glitches? If it's tearing, with current xf86-video-ati Git
 > you can try Option "TearFree".

Hard to describe, just sort of.. bursts of coloured sparkle noise in
random positions.
They don't remain part of the image permanently, and only appear for a
split second. They are pretty constant when scrolling though.

I'll see if I can get video of it when I'm in front of it again on Monday.

One other bug I noticed: Once it goes into DPMS, I can't wake it up again
and need to reboot. Likewise if I power off the monitor and back on,
it goes into power saving again.

	Dave

Patch

diff --git a/drivers/gpu/drm/radeon/radeon_dp_auxch.c b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
index bf1fecc6cceb..3b401cc8d209 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_auxch.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
@@ -30,7 +30,6 @@ 
 			    AUX_SW_RX_HPD_DISCON |	     \
 			    AUX_SW_RX_PARTIAL_BYTE |	     \
 			    AUX_SW_NON_AUX_MODE |	     \
-			    AUX_SW_RX_MIN_COUNT_VIOL |	     \
 			    AUX_SW_RX_INVALID_STOP |	     \
 			    AUX_SW_RX_SYNC_INVALID_L |	     \
 			    AUX_SW_RX_SYNC_INVALID_H |	     \