Radeon Verde displayport failure.

[Alex Deucher]

On Mon, May 11, 2015 at 2:40 PM, Dave Jones <davej at codemonkey.org.uk> wrote:
> On Fri, May 08, 2015 at 11:40:55AM -0400, Dave Jones wrote:
>  > On Fri, May 08, 2015 at 01:23:59PM +0000, Deucher, Alexander wrote:
>
>  >  > > I just bought a new radeon (1002:682c), to pair with my shiny new displayport
>  >  > > monitor.
>  >  > > It shows a display during through the BIOS POST, and grub, but when the
>  >  > > kernel
>  >  > > starts up, it's a coin toss whether or not I get anything.
>  >  > > Sometimes it just goes straight into power saving.
>  >  > >
>  >  > > When I do get something on the console, it continues to boot and then X
>  >  > > starts up and
>  >  > > puts it into power saving too. Trying to flip back to tty1 doesn't light up the
>  >  > > display again.
>  >  > >
>  >  > > I'm running On debian stable, with copied-by-hand verde_* firmware files
>  >  > > from the linux-firmware git tree.
>  >  > > Here's a log from the 4.0-rc2 kernel.
>  >  > >
>  >  > > Any other info I can provide ?
>  >  >
>  >  > The link training with the monitor seems to fail periodically.  You may have to play with the timing in the link training sequence.  It looks like you also have some power management related issues.  Does booting with radeon.dpm=0 on the kernel command line in grub help?  Also does the monitor support audio?  You might also try radeon.audio=0.
>  >
>  > Pretty much the same story with those options..
>  >
>  > [    8.162285] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_enable_smc_cac failed
>  > [    8.170753] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
>  > [    8.170778] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
>  >
>  > I did manage to get it to display something for a while. By disabling DP1.2 with the
>  > LCDs OSD, but then it would only do a maximum of 1024x768. And after a reboot,
>  > I saw the same messages above, and straight to power saving.
>
> 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

Alex