On Thu, May 14, 2015 at 11:52 PM, Dave Jones <davej@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx> 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 | \
From e3e5efb1e3f9d3f16a6521c56cde7a7b1c83a2e8 Mon Sep 17 00:00:00 2001 From: Alex Deucher <alexander.deucher@xxxxxxx> Date: Wed, 20 May 2015 17:58:49 -0400 Subject: [PATCH] drm/radeon: fix error flag checking in native aux path That atom table does not check these bits. Fixes aux regressions on some boards. Signed-off-by: Alex Deucher <alexander.deucher@xxxxxxx> Cc: stable@xxxxxxxxxxxxxxx --- drivers/gpu/drm/radeon/radeon_dp_auxch.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_dp_auxch.c b/drivers/gpu/drm/radeon/radeon_dp_auxch.c index bf1fecc..fcbd60b 100644 --- a/drivers/gpu/drm/radeon/radeon_dp_auxch.c +++ b/drivers/gpu/drm/radeon/radeon_dp_auxch.c @@ -30,8 +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 | \ AUX_SW_RX_INVALID_START | \ -- 1.8.3.1
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
