On Thu, May 14, 2015 at 11:52 PM, Dave Jones <davej at codemonkey.org.uk> wrote: > On Thu, May 14, 2015 at 09:49:52AM -0400, Alex Deucher wrote: > > On Tue, May 12, 2015 at 8:04 PM, Dave Jones <davej at codemonkey.org.uk> > 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. >
I think the attached patch should get aux working as reliably as the old atom code. The atom code ignores bits 12-14 when checking the transaction flags. Alex > thanks, > Dave > > > 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 | \ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-drm-radeon-fix-error-flag-checking-in-native-aux-pat.patch Type: text/x-patch Size: 1055 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150520/36501357/attachment.bin>
