Radeon Verde displayport failure.

[Alex Deucher]

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>