*** Bug 73529 has been marked as a duplicate of this bug. ***

Created attachment 91918 [details]
Linux kernel ring buffer (`dmesg`)

Please note the Linux kernel command line, which has `radeon.modeset=0`, `drm.debug=14` and `acpi_osi=Linux`. Later the the Radeon module is removed with `sudo modprobe -r radeon` and reloaded with `sudo modprobe radeon modeset=1`.

Created attachment 91919 [details]
X server log file

X server log after reloading the Radeon module with modesetting enabled and then restarting the X server by restarting GDM with `sudo service gdm3 restart`.

(In reply to comment #2)
> Created attachment 91918 [details]
> Linux kernel ring buffer (`dmesg`)
> 
> Please note the Linux kernel command line, which has `radeon.modeset=0`,
> `drm.debug=14` and `acpi_osi=Linux`. Later the the Radeon module is removed
> with `sudo modprobe -r radeon` and reloaded with `sudo modprobe radeon
> modeset=1`.

I don't seen any radeon messages.  It doesn't look like it loaded properly.

It looks like their are also two modes in your EDID for your panel:

[  1248.508] (II) RADEON(0): Supported detailed timing:
[  1248.508] (II) RADEON(0): clock: 138.8 MHz   Image Size:  282 x 165 mm
[  1248.508] (II) RADEON(0): h_active: 1920  h_sync: 1966  h_sync_end 1996 h_blank_end 2080 h_border: 0
[  1248.508] (II) RADEON(0): v_active: 1080  v_sync: 1082  v_sync_end 1086 v_blanking: 1112 v_border: 0
[  1248.508] (II) RADEON(0): Supported detailed timing:
[  1248.508] (II) RADEON(0): clock: 92.5 MHz   Image Size:  282 x 165 mm
[  1248.508] (II) RADEON(0): h_active: 1920  h_sync: 1966  h_sync_end 1996 h_blank_end 2080 h_border: 0
[  1248.508] (II) RADEON(0): v_active: 1080  v_sync: 1082  v_sync_end 1086 v_blanking: 1112 v_border: 0

[  1248.508] (II) RADEON(0): Modeline "1920x1080"x60.0  138.78  1920 1966 1996 2080  1080 1082 1086 1112 -hsync -vsync (66.7 kHz eP)
[  1248.508] (II) RADEON(0): Modeline "1920x1080"x40.0   92.52  1920 1966 1996 2080  1080 1082 1086 1112 -hsync -vsync (44.5 kHz e)

perhaps one of the modes is problematic.

Created attachment 92048 [details] [review]
disable ss

Does this kernel patch help?

Created attachment 92049 [details] [review]
debugging output

Can you also attach the dmesg output with this patch applied?

Just a note, that the Debian Linux kernel has fbcon compiled in.

    CONFIG_FRAMEBUFFER_CONSOLE=y

Applying your patch to disable ss to Linux 3.13-rc8 worked. The monitor displays now something even with KMS. Thanks!

It could still be that something else fixed it in Linux 3.13-rc8 which was not yet in 3.12.6. I’ll post the logs so you can decide.

$ git log --format=oneline | head -2
9e6494b67886c1bf7ba5834ac43beb6d82661876 patch by Alex Deucher
a6da83f98267bc8ee4e34aa899169991eb0ceb93 Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
$ xrandr -q --verbose
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
eDP connected primary 1920x1080+0+0 (0x57) normal (normal left inverted right x axis y axis) 282mm x 165mm
	Identifier: 0x53
	Timestamp:  139873
	Subpixel:   horizontal rgb
	Gamma:      1.0:1.0:1.0
	Brightness: 1.0
	Clones:    
	CRTC:       0
	CRTCs:      0 1 2 3
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	EDID: 
		00ffffffffffff000dae431300000000
		34150104a51c10780293ada9534c9625
		114f5300000001010101010101010101
		010101010101363680a0703820402e1e
		24001aa510000018242480a070382040
		2e1e24001aa510000018000000fe0043
		4d4e0a202020202020202020000000fe
		004e3133334853452d4541310a2000cd
	scaling mode: Full 
		supported: None, Full, Center, Full aspect
  1920x1080 (0x57)  138.8MHz -HSync -VSync *current +preferred
        h: width  1920 start 1966 end 1996 total 2080 skew    0 clock   66.7KHz
        v: height 1080 start 1082 end 1086 total 1112           clock   60.0Hz
  1920x1080 (0x58)   92.5MHz -HSync -VSync
        h: width  1920 start 1966 end 1996 total 2080 skew    0 clock   44.5KHz
        v: height 1080 start 1082 end 1086 total 1112           clock   40.0Hz
  1680x1050 (0x59)  146.2MHz -HSync +VSync
        h: width  1680 start 1784 end 1960 total 2240 skew    0 clock   65.3KHz
        v: height 1050 start 1053 end 1059 total 1089           clock   60.0Hz
  1400x1050 (0x5a)  121.8MHz -HSync +VSync
        h: width  1400 start 1488 end 1632 total 1864 skew    0 clock   65.3KHz
        v: height 1050 start 1053 end 1057 total 1089           clock   60.0Hz
  1280x1024 (0x5b)  109.0MHz -HSync +VSync
        h: width  1280 start 1368 end 1496 total 1712 skew    0 clock   63.7KHz
        v: height 1024 start 1027 end 1034 total 1063           clock   59.9Hz
  1440x900 (0x5c)  106.5MHz -HSync +VSync
        h: width  1440 start 1528 end 1672 total 1904 skew    0 clock   55.9KHz
        v: height  900 start  903 end  909 total  934           clock   59.9Hz
  1280x960 (0x5d)  101.2MHz -HSync +VSync
        h: width  1280 start 1360 end 1488 total 1696 skew    0 clock   59.7KHz
        v: height  960 start  963 end  967 total  996           clock   59.9Hz
  1280x854 (0x5e)   89.2MHz -HSync +VSync
        h: width  1280 start 1352 end 1480 total 1680 skew    0 clock   53.1KHz
        v: height  854 start  857 end  867 total  887           clock   59.9Hz
  1280x800 (0x5f)   83.5MHz -HSync +VSync
        h: width  1280 start 1352 end 1480 total 1680 skew    0 clock   49.7KHz
        v: height  800 start  803 end  809 total  831           clock   59.8Hz
  1280x720 (0x60)   74.5MHz -HSync +VSync
        h: width  1280 start 1344 end 1472 total 1664 skew    0 clock   44.8KHz
        v: height  720 start  723 end  728 total  748           clock   59.9Hz
  1152x768 (0x61)   71.8MHz -HSync +VSync
        h: width  1152 start 1216 end 1328 total 1504 skew    0 clock   47.7KHz
        v: height  768 start  771 end  781 total  798           clock   59.8Hz
  1024x768 (0x62)   63.5MHz -HSync +VSync
        h: width  1024 start 1072 end 1176 total 1328 skew    0 clock   47.8KHz
        v: height  768 start  771 end  775 total  798           clock   59.9Hz
  800x600 (0x63)   38.2MHz -HSync +VSync
        h: width   800 start  832 end  912 total 1024 skew    0 clock   37.4KHz
        v: height  600 start  603 end  607 total  624           clock   59.9Hz
  848x480 (0x64)   31.5MHz -HSync +VSync
        h: width   848 start  872 end  952 total 1056 skew    0 clock   29.8KHz
        v: height  480 start  483 end  493 total  500           clock   59.7Hz
  720x480 (0x65)   26.8MHz -HSync +VSync
        h: width   720 start  744 end  808 total  896 skew    0 clock   29.9KHz
        v: height  480 start  483 end  493 total  500           clock   59.7Hz
  640x480 (0x66)   23.8MHz -HSync +VSync
        h: width   640 start  664 end  720 total  800 skew    0 clock   29.7KHz
        v: height  480 start  483 end  487 total  500           clock   59.4Hz
VGA-0 disconnected (normal left inverted right x axis y axis)
	Identifier: 0x54
	Timestamp:  139873
	Subpixel:   no subpixels
	Clones:    
	CRTCs:      0 1 2 3
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	load detection: 1 
		range: (0, 1)
HDMI-0 disconnected (normal left inverted right x axis y axis)
	Identifier: 0x55
	Timestamp:  139873
	Subpixel:   horizontal rgb
	Clones:    
	CRTCs:      0 1 2 3
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	dither: off 
		supported: off, on
	audio: auto 
		supported: off, on, auto
	underscan vborder: 0 
		range: (0, 128)
	underscan hborder: 0 
		range: (0, 128)
	underscan: off 
		supported: off, on, auto
	coherent: 1 
		range: (0, 1)

Created attachment 92126 [details]
Linux kernel 3.13-rc8+-disable-ss ring buffer (`dmesg`)

Some seconds seem to be missing as the ring buffer overflowed. Please tell me if something important is missing.

Created attachment 92128 [details]
X server log file with Linux 3.13-rc8-disable-ss

I attached an USB mouse later on.

Alex, please tell me if you still need the Linux output with your second patch applied or anything else. Thanks again!

One other question, how does MS Windows figure out the correct modelines when the EDID of the monitor is incorrect? (I did not try the shipped Windows 8 at all but assume it works.)

(In reply to comment #9)
> Applying your patch to disable ss to Linux 3.13-rc8 worked. The monitor
> displays now something even with KMS. Thanks!
> 
> It could still be that something else fixed it in Linux 3.13-rc8 which was
> not yet in 3.12.6. I’ll post the logs so you can decide.

Can you test 3.13-rc8 without the ss-patch to confirm what fixed it?

(In reply to comment #13)
> One other question, how does MS Windows figure out the correct modelines
> when the EDID of the monitor is incorrect? (I did not try the shipped
> Windows 8 at all but assume it works.)

It's not incorrect, you can have multiple modes with different clocks for saving power.  E.g., when the system is idle for a while, switch to the lower clocked mode.

(In reply to comment #15)
> (In reply to comment #13)
> > One other question, how does MS Windows figure out the correct modelines
> > when the EDID of the monitor is incorrect? (I did not try the shipped
> > Windows 8 at all but assume it works.)
> 
> It's not incorrect, you can have multiple modes with different clocks for
> saving power.  E.g., when the system is idle for a while, switch to the
> lower clocked mode.

If the display is not able to display something with a certain modeline, I’d call it incorrect. What did I miss?

(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #13)
> > > One other question, how does MS Windows figure out the correct modelines
> > > when the EDID of the monitor is incorrect? (I did not try the shipped
> > > Windows 8 at all but assume it works.)
> > 
> > It's not incorrect, you can have multiple modes with different clocks for
> > saving power.  E.g., when the system is idle for a while, switch to the
> > lower clocked mode.
> 
> If the display is not able to display something with a certain modeline, I’d
> call it incorrect. What did I miss?

I was just guessing at a possible cause for the display problem.  It turns out it's not the issue anyway.

Created attachment 92171 [details] [review]
patch 1/2

Can you try the two attached patches and see if they help?  Patch 2/2 is the actual fix.  If you have any problems with both patches, drop patch 1/2.

Created attachment 92172 [details] [review]
patch 2/2

Patch 2/2.  The actual fix for this bug.

I guess I spoke too soon. :( Now starting the system a second time, the display is black again with the backlight enabled. I was able to login blindly into GNOME using GDM, so X is running. I’ll post the log files. Hopefully something can be spotted.

$ xrandr -q --verbose
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
eDP connected primary 1920x1080+0+0 (0x57) normal (normal left inverted right x axis y axis) 282mm x 165mm
	Identifier: 0x53
	Timestamp:  60512
	Subpixel:   horizontal rgb
	Gamma:      1.0:1.0:1.0
	Brightness: 1.0
	Clones:    
	CRTC:       0
	CRTCs:      0 1 2 3
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	EDID: 
		00ffffffffffff000dae431300000000
		34150104a51c10780293ada9534c9625
		114f5300000001010101010101010101
		010101010101363680a0703820402e1e
		24001aa510000018242480a070382040
		2e1e24001aa510000018000000fe0043
		4d4e0a202020202020202020000000fe
		004e3133334853452d4541310a2000cd
	scaling mode: Full 
		supported: None, Full, Center, Full aspect
  1920x1080 (0x57)  138.8MHz -HSync -VSync *current +preferred
        h: width  1920 start 1966 end 1996 total 2080 skew    0 clock   66.7KHz
        v: height 1080 start 1082 end 1086 total 1112           clock   60.0Hz
  1920x1080 (0x58)   92.5MHz -HSync -VSync
        h: width  1920 start 1966 end 1996 total 2080 skew    0 clock   44.5KHz
        v: height 1080 start 1082 end 1086 total 1112           clock   40.0Hz
  1680x1050 (0x59)  146.2MHz -HSync +VSync
        h: width  1680 start 1784 end 1960 total 2240 skew    0 clock   65.3KHz
        v: height 1050 start 1053 end 1059 total 1089           clock   60.0Hz
  1400x1050 (0x5a)  121.8MHz -HSync +VSync
        h: width  1400 start 1488 end 1632 total 1864 skew    0 clock   65.3KHz
        v: height 1050 start 1053 end 1057 total 1089           clock   60.0Hz
  1280x1024 (0x5b)  109.0MHz -HSync +VSync
        h: width  1280 start 1368 end 1496 total 1712 skew    0 clock   63.7KHz
        v: height 1024 start 1027 end 1034 total 1063           clock   59.9Hz
  1440x900 (0x5c)  106.5MHz -HSync +VSync
        h: width  1440 start 1528 end 1672 total 1904 skew    0 clock   55.9KHz
        v: height  900 start  903 end  909 total  934           clock   59.9Hz
  1280x960 (0x5d)  101.2MHz -HSync +VSync
        h: width  1280 start 1360 end 1488 total 1696 skew    0 clock   59.7KHz
        v: height  960 start  963 end  967 total  996           clock   59.9Hz
  1280x854 (0x5e)   89.2MHz -HSync +VSync
        h: width  1280 start 1352 end 1480 total 1680 skew    0 clock   53.1KHz
        v: height  854 start  857 end  867 total  887           clock   59.9Hz
  1280x800 (0x5f)   83.5MHz -HSync +VSync
        h: width  1280 start 1352 end 1480 total 1680 skew    0 clock   49.7KHz
        v: height  800 start  803 end  809 total  831           clock   59.8Hz
  1280x720 (0x60)   74.5MHz -HSync +VSync
        h: width  1280 start 1344 end 1472 total 1664 skew    0 clock   44.8KHz
        v: height  720 start  723 end  728 total  748           clock   59.9Hz
  1152x768 (0x61)   71.8MHz -HSync +VSync
        h: width  1152 start 1216 end 1328 total 1504 skew    0 clock   47.7KHz
        v: height  768 start  771 end  781 total  798           clock   59.8Hz
  1024x768 (0x62)   63.5MHz -HSync +VSync
        h: width  1024 start 1072 end 1176 total 1328 skew    0 clock   47.8KHz
        v: height  768 start  771 end  775 total  798           clock   59.9Hz
  800x600 (0x63)   38.2MHz -HSync +VSync
        h: width   800 start  832 end  912 total 1024 skew    0 clock   37.4KHz
        v: height  600 start  603 end  607 total  624           clock   59.9Hz
  848x480 (0x64)   31.5MHz -HSync +VSync
        h: width   848 start  872 end  952 total 1056 skew    0 clock   29.8KHz
        v: height  480 start  483 end  493 total  500           clock   59.7Hz
  720x480 (0x65)   26.8MHz -HSync +VSync
        h: width   720 start  744 end  808 total  896 skew    0 clock   29.9KHz
        v: height  480 start  483 end  493 total  500           clock   59.7Hz
  640x480 (0x66)   23.8MHz -HSync +VSync
        h: width   640 start  664 end  720 total  800 skew    0 clock   29.7KHz
        v: height  480 start  483 end  487 total  500           clock   59.4Hz
VGA-0 disconnected (normal left inverted right x axis y axis)
	Identifier: 0x54
	Timestamp:  60512
	Subpixel:   no subpixels
	Clones:    
	CRTCs:      0 1 2 3
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	load detection: 1 
		range: (0, 1)
HDMI-0 disconnected (normal left inverted right x axis y axis)
	Identifier: 0x55
	Timestamp:  60512
	Subpixel:   horizontal rgb
	Clones:    
	CRTCs:      0 1 2 3
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	dither: off 
		supported: off, on
	audio: auto 
		supported: off, on, auto
	underscan vborder: 0 
		range: (0, 128)
	underscan hborder: 0 
		range: (0, 128)
	underscan: off 
		supported: off, on, auto
	coherent: 1 
		range: (0, 1)

(In reply to comment #20)
> I guess I spoke too soon. :( Now starting the system a second time, the
> display is black again with the backlight enabled. I was able to login
> blindly into GNOME using GDM, so X is running. I’ll post the log files.
> Hopefully something can be spotted.

Make sure you booted the correct kernel.

Does forcing a dpms cycle help?  e.g.,

sleep 5; xset dpms force off

and then after the monitor blanks, move the mouse to trigger a wake up.

Turning the display off and on again, the display works fine.

    $ xrandr --output eDP --off
    $ xrandr --output eDP --auto

(In reply to comment #23)
> Turning the display off and on again, the display works fine.
> 
>     $ xrandr --output eDP --off
>     $ xrandr --output eDP --auto

Does that work without patches or only with one of the patches from this bug?  If it requires a patch or patches, which one(s)?

Alex, thank you for the quick replies!

When doing the tests, should I save certain logs? Do you want me to pass special debug parameters?

(In reply to comment #25)
> Alex, thank you for the quick replies!
> 
> When doing the tests, should I save certain logs? Do you want me to pass
> special debug parameters?

I don't need any logs at the moment.  I just need to know which patches (if any) are necessary to get the display working.

So turning the display off and on with xrandr or xset does not always work even with the patched Linux kernel.

I was able to get the display to work with Debian’s Linux kernel 3.12.6 (with none of your patches applied) using `xrandr --output eDP --off` and `xrandr --output eDP --auto`. So it looks like no patch is needed after all.

Do you want me to test something else or can we assume that no Linux kernel patch is needed and the display has to be dealt with? As commented, turning it off and on does not always get it to work.

Have you tested the patch in attachment 92172 [details] [review]?  Does it help at all?

Sorry, I missed the two patches. I’ll test them now.

Applying both patches 1/2 and 2/2 did not help anything with the situation. I had to run `xrandr --output eDP --off` and `xrandr --output eDP --auto` three times to get the display to work.

Only testing patch 2/2 also did not fix the issue. The display was just black and I had to do the `xrandr` dance to get it to work.

No idea, if it’ll give a clue, but often the display did not work even after turning it off and on more than five times. Blindly logging out again, which closes the X session, goes to tty1 and then back to the new X session with the GDM login screen and logging back in, often I am able to get the display back to work by less than four off-on xrandr cycles.

Created attachment 92230 [details] [review]
possible fix

There's nothing in your logs indicating a link failure when setting up the DP link.  It seems like your panel is just especially picky about the timing in the link training or something like that.  Try the attached patch.  I've also pushed a branch with some other DP related patches that might help if you want to try it:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.14-wip

(In reply to comment #35)
> Created attachment 92230 [details] [review] [review]
> possible fix
> 
> There's nothing in your logs indicating a link failure when setting up the
> DP link.  It seems like your panel is just especially picky about the timing
> in the link training or something like that.  Try the attached patch.

That patch did not help either. Rebooting the first time, the display was black and was working then after one xrandr off/auto cycle.

The second time I had to do 15 xrandr off/auto cycles.

> I've also pushed a branch with some other DP related patches that might help
> if you want to try it:
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.14-wip

I did not tried that yet.

(In reply to comment #36)
> (In reply to comment #35)

[…]

> > I've also pushed a branch with some other DP related patches that might help
> > if you want to try it:
> > http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.14-wip
> 
> I did not tried that yet.

The Linux kernel built from your branch 3.14-wip does not work either.

Is there a way to look at the Windows driver to know what the timing should be?

Once the display works, it seems to work always during consecutive off/on cycles.

Created attachment 92262 [details]
Picture of a wrong timing(?)

With

commit 7424173698775ad90a039d8e00cbee333de536ec
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Jan 14 10:45:51 2014 -0500

    drm/radeon/dp: sleep after powering up the display
    
    According to the DP 1.1 spec, the sink must power
    up within 1ms.  Noticed while reviewing Thierry's
    drm/dp patches.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c
index fb3ae07..ba7157a 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -671,9 +671,11 @@ static int radeon_dp_link_train_init(struct radeon_dp_link_train_info *dp_info)
        u8 tmp;
 
        /* power up the sink */
-       if (dp_info->dpcd[0] >= 0x11)
+       if (dp_info->dpcd[0] >= 0x11) {
                radeon_write_dpcd_reg(dp_info->radeon_connector,
                                      DP_SET_POWER, DP_SET_POWER_D0);
+               usleep_range(1000, 2000);
+       }
 
        /* possibly enable downspread on the sink */
        if (dp_info->dpcd[3] & 0x1)

I got the attached image after two xrandr off/on cycles. After the next off/on cycle the display worked. I did not notice such a behavior in my other tests.

Created attachment 92264 [details]
Picture of another wrong timing(?)

This morning I noticed the same behavior with the same patch.

commit 7424173698775ad90a039d8e00cbee333de536ec
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Jan 14 10:45:51 2014 -0500

    drm/radeon/dp: sleep after powering up the display
    
    According to the DP 1.1 spec, the sink must power
    up within 1ms.  Noticed while reviewing Thierry's
    drm/dp patches.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c
index fb3ae07..ba7157a 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -671,9 +671,11 @@ static int radeon_dp_link_train_init(struct radeon_dp_link_train_info *dp_info)
        u8 tmp;
 
        /* power up the sink */
-       if (dp_info->dpcd[0] >= 0x11)
+       if (dp_info->dpcd[0] >= 0x11) {
                radeon_write_dpcd_reg(dp_info->radeon_connector,
                                      DP_SET_POWER, DP_SET_POWER_D0);
+               usleep_range(1000, 2000);
+       }
 
        /* possibly enable downspread on the sink */
        if (dp_info->dpcd[3] & 0x1)

The attached picture was gotten after the first xrandr off/on cycle. The next xrandr off/on cycle got the display to work too.

Do you still need the debugging output of the native(?) mode lines and want me to apply your patch and test it?

Would other tests like using a different modeline 1680x1050 be useful? Can that be set on the Linux command line? Reading `/sbin/modinfo radeon` I could not find the parameter.

(In reply to comment #43)
> Would other tests like using a different modeline 1680x1050 be useful? Can
> that be set on the Linux command line? Reading `/sbin/modinfo radeon` I
> could not find the parameter.

The panel has fixed timing so you can only program it with it's native mode.  All other modes are scaled using the GPU.

Anything I should try/look at over the weekend?

Current status is that I mostly get it to work after the first xrandr off/auto cycle, meaning 80 % of the cases.

The other 19 % of the cases it takes longer and in 1 % it works right away.

I still do not understand how training works, meaning why it has a higher chance of working in subsequent tries and is not uniformly distributed.

Looking at the panel/monitor CMN 1343, I found a list with more information [1].

    Chi Mei Innolux N133HSE-EA1
    Asus U38N(-C4010H)
    Asus Zenbook UX31A, UX32VD
    Clevo W230ST
    1920x1080, IPS, matte
    30 pin eDP
    shop: diytrade.com
    review: Notebook
    review: The Verge
    shortname: CMN 1343

It seems that it is used in other systems and works with GNU/Linux there. Though I only found Intel systems [1][2] and I have no idea if the panel is really connected using eDP, though the note above says so.

So it might be a problem specific to the Radeon driver.

[1] https://hackpad.com/Best-Panels-Wiki-D5UvkrtVvJ9
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687203
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724510

You might try adjusting the delays in radeon_dp_link_train() and the functions it calls.  Some panels are really picky about the timing during the training sequence.

With the debug patch applied to your 3.14-wip branch (based on 3.13-rc4), the following is printed by the Linux kernel.

    [   12.005985] [drm:radeon_fixup_lvds_native_mode], Native mode: 1920x1080-138780

The clock looks strange to me, as I would have expected the refresh rate. But I guess I just do not know what it is supposed to do.

(I had to do eight xrandr off/auto cycles to get the display to work.)

That line was the same testing the same built Linux kernel a second time.

    [drm:radeon_fixup_lvds_native_mode], Native mode: 1920x1080-138780

It also took one xrandr off/auto cycle to get the display working.

I tried Linux 3.13 with the patch below and I could not get the display to work at all with the following script.

    while true; do xrandr --output eDP --off && xrandr --output eDP --auto && sleep 4; done

        ---
         drivers/gpu/drm/radeon/atombios_dp.c | 8 ++++++++
         1 file changed, 8 insertions(+)

        diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c
        index fb3ae07..564bac0 100644
        --- a/drivers/gpu/drm/radeon/atombios_dp.c
        +++ b/drivers/gpu/drm/radeon/atombios_dp.c
        @@ -912,13 +912,21 @@ void radeon_dp_link_train(struct drm_encoder *encoder,
         	dp_info.dp_lane_count = dig_connector->dp_lane_count;
         	dp_info.dp_clock = dig_connector->dp_clock;
         
        +	DRM_DEBUG_KMS("Before train_init\n");
        +	msleep(10);
         	if (radeon_dp_link_train_init(&dp_info))
         		goto done;
        +	DRM_DEBUG_KMS("Before train_cr\n");
        +	msleep(10);
         	if (radeon_dp_link_train_cr(&dp_info))
         		goto done;
        +	msleep(10);
        +	DRM_DEBUG_KMS("Before train_ce\n");
         	if (radeon_dp_link_train_ce(&dp_info))
         		goto done;
         done:
        +	msleep(10);
        +	DRM_DEBUG_KMS("Before train_finish\n");
         	if (radeon_dp_link_train_finish(&dp_info))
         		return;
         }
        -- 
        1.9.rc1

I’ll post the errors tomorrow.

Created attachment 93042 [details]
`/var/log/kern.log` from 3.13 with debug and delay patch

Here are the errors.

	[  297.778990] [drm:radeon_dp_link_train], Before train_cr
	[  297.794470] [drm:radeon_process_aux_ch], dp_aux_ch timeout
	[  297.796597] [drm:radeon_dp_get_link_status], link status 00 00 80 00 00 00
	[  297.796604] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.4V pre_emph 0dB
	[  297.796609] [drm:dp_get_adjust_train], using signal parameters: voltage 0.4V pre_emph 0dB
	[  297.798313] [drm:radeon_dp_get_link_status], link status 00 00 00 00 00 00
	[  297.798318] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.4V pre_emph 0dB
	[  297.798322] [drm:dp_get_adjust_train], using signal parameters: voltage 0.4V pre_emph 0dB
	[  297.800044] [drm:radeon_dp_get_link_status], link status 00 00 00 00 00 00
	[  297.800048] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.4V pre_emph 0dB
	[  297.800052] [drm:dp_get_adjust_train], using signal parameters: voltage 0.4V pre_emph 0dB
	[  297.801762] [drm:radeon_dp_get_link_status], link status 00 00 00 00 00 00
	[  297.801766] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.4V pre_emph 0dB
	[  297.801770] [drm:dp_get_adjust_train], using signal parameters: voltage 0.4V pre_emph 0dB
	[  297.803490] [drm:radeon_dp_get_link_status], link status 00 00 00 00 00 00
	[  297.803494] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.4V pre_emph 0dB
	[  297.803496] [drm:dp_get_adjust_train], using signal parameters: voltage 0.4V pre_emph 0dB
	[  297.805187] [drm:radeon_dp_get_link_status], link status 00 00 00 00 00 00
	[  297.805190] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery tried 5 times
	[  297.805194] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed

So where can I get the specifications about DisplayPort link training? Is it in [1]?

[1] http://www.vesa.org/vesa-standards/free-standards/

I think you need to be a vesa member to download the DP specs.  There may be some older copies floating around on the internet.  They are also available to Xorg members if you wanted to become an Xorg member.

As to the problem, the link training sequence has defined delays for various parts of the training sequence.  I would suggest tweaking the existing delays rather than adding new ones.  E.g., the udelay(400); in radeon_dp_link_train_cr() and radeon_dp_link_train_finish() and the delays in drm_dp_link_train_clock_recovery_delay() and drm_dp_link_train_channel_eq_delay().  Or possibly passing different delays to radeon_dp_aux_native_read() or radeon_dp_aux_native_write().

Changing the 400 μs to 800 μs and 400 μs did not change anything.

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c
index 676ddf8..3e533bb 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -204,7 +204,7 @@ static int radeon_dp_aux_native_read(struct radeon_connector *radeon_connector,
                if ((ack & AUX_NATIVE_REPLY_MASK) == AUX_NATIVE_REPLY_ACK)
                        return ret;
                else if ((ack & AUX_NATIVE_REPLY_MASK) == AUX_NATIVE_REPLY_DEFER)
-                       udelay(800);
+                       udelay(200);
                else if (ret == 0)
                        return -EPROTO;
                else
@@ -293,7 +293,7 @@ int radeon_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
                        return -EREMOTEIO;
                case AUX_NATIVE_REPLY_DEFER:
                        DRM_DEBUG_KMS("aux_ch native defer\n");
-                       udelay(800);
+                       udelay(200);
                        continue;
                default:
                        DRM_ERROR("aux_ch invalid native reply 0x%02x\n", ack);
@@ -310,7 +310,7 @@ int radeon_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
                        return -EREMOTEIO;
                case AUX_I2C_REPLY_DEFER:
                        DRM_DEBUG_KMS("aux_i2c defer\n");
-                       udelay(800);
+                       udelay(200);
                        break;
                default:
                        DRM_ERROR("aux_i2c invalid reply 0x%02x\n", ack);
@@ -716,7 +716,7 @@ static int radeon_dp_link_train_init(struct radeon_dp_link_train_info *dp_info)
 
 static int radeon_dp_link_train_finish(struct radeon_dp_link_train_info *dp_info)
 {
-       udelay(800);
+       udelay(200);
 
        /* disable the training pattern on the sink */
        radeon_write_dpcd_reg(dp_info->radeon_connector,
@@ -744,7 +744,7 @@ static int radeon_dp_link_train_cr(struct radeon_dp_link_train_info *dp_info)
        memset(dp_info->train_set, 0, 4);
        radeon_dp_update_vs_emph(dp_info);
 
-       udelay(800);
+       udelay(200);
 
        /* clock recovery loop */
        clock_recovery = false;

In the Linux kernel log after the xrandr cycle and a working display afterward, the following is shown, which is not shown during start-up.

	Feb  1 09:46:31 my_asus_u38n_system kernel: [   86.286840] [drm:drm_mode_addfb], [FB:42]
	Feb  1 09:46:31 my_asus_u38n_system kernel: [   86.287184] [drm:drm_mode_setcrtc], [CRTC:12]
	Feb  1 09:46:31 my_asus_u38n_system kernel: [   86.287195] [drm:drm_mode_setcrtc], [CONNECTOR:17:eDP-1]
	Feb  1 09:46:31 my_asus_u38n_system kernel: [   86.287200] [drm:drm_crtc_helper_set_config], 
	Feb  1 09:46:31 my_asus_u38n_system kernel: [   86.287204] [drm:drm_crtc_helper_set_config], [CRTC:12] [FB:42] #connectors=1 (x y) (0 0)

Any idea, why this is not run during start-up?

Created attachment 93163 [details]
Linux kernel log 3.13 with patch from previous comment (200 μs)

Same behavior, backlight turned on but everything was black.

Created attachment 93164 [details]
Linux kernel log 3.13 with patch from previous comment (200 μs) after xrandr --off/--auto cycle

Display worked after this xrandr cycle.

One other though, could you talk with your appartment to get you an Asus U38N-C4010 laptop so you can work with it (probably quicker than relying on and relaying stuff to me) and so you also have it in your test equipment for your QA (quality assurance)?

Just an update that I get the same behavior with Dave’s drm-fixes branch, which has Linux 3.14-rc1 included.

I tried to finally get a usable laptop by using FGLRX, but neither 13.12 nor 14.1~beta1.3-1 worked with my Debian installation. That means, GNU/Linux is unusable with this AMD based laptop and, jugdging from the time wasted to get GNU/Linux to work, I regret ever buying it. The disk with MS Windows 8.1 was put back in and somebody else is using it now. Judging from the current state I won’t be able to recommend to anyone to buy an AMD based laptop. Sorry.

Also I won’t be able to do any further tests.

I forgot to thank you for all your help and it makes me sad that I had to come to the conclusion.

I think / guess that I am having the same issues. I've got the same laptop, running Arch Linux. Mostly, I've been using the proprietary catalyst driver, since I never got the free driver working. The proprietary is working fine.

What is the issue here? You've been playing with timings for the physical link to the internal panel? Is it so frickly? What would you need to fix the issue? How can I help?

(In reply to Christian Aßfalg from comment #63)
> I think / guess that I am having the same issues. I've got the same laptop,
> running Arch Linux. Mostly, I've been using the proprietary catalyst driver,
> since I never got the free driver working. The proprietary is working fine.

Then you had more luck than I did. What FGLRX version do you use?

> What is the issue here? You've been playing with timings for the physical
> link to the internal panel? Is it so frickly? What would you need to fix the
> issue? How can I help?

I was just told to play with the timings, but I actually have no idea anymore, sorry. Also I do not use that laptop anymore, so I have no easy way to test that. Hopefully the developers will be able to help you.

What Linux kernel versions did you try?

(In reply to Christian Aßfalg from comment #63)
> I think / guess that I am having the same issues. I've got the same laptop,
> running Arch Linux. Mostly, I've been using the proprietary catalyst driver,
> since I never got the free driver working. The proprietary is working fine.
> 
> What is the issue here? You've been playing with timings for the physical
> link to the internal panel? Is it so frickly? What would you need to fix the
> issue? How can I help?

In reply to Christian Aßfalg from comment #63)
> I think / guess that I am having the same issues. I've got the same laptop,
> running Arch Linux. Mostly, I've been using the proprietary catalyst driver,
> since I never got the free driver working. The proprietary is working fine.
> 
> What is the issue here? You've been playing with timings for the physical
> link to the internal panel? Is it so frickly? What would you need to fix the
> issue? How can I help?

I suggested that it might be a timing issue, and as per comment 54.  However, link training is successful so that monitor accepts the parameters that the driver proposed, it just sometimes chooses not to light up.  I would suggest trying to tweak the link training timing as per comment 54, try disabling ss as per comment 6, and finally, try making some slight changes to the modeset sequence as per the attached patch.  The patch adds a delay before enabling the video stream and additionally calls the enable video stream code again in case the monitor didn't quite get the signal the first time.  E.g.,

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c
index a7f2ddf..256ed7d 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1687,8 +1687,12 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder *encoder, int mode)
                if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(encoder)) && connector) {
                        /* DP_SET_POWER_D0 is set in radeon_dp_link_train */
                        radeon_dp_link_train(encoder, connector);
-                       if (ASIC_IS_DCE4(rdev))
+                       if (ASIC_IS_DCE4(rdev)) {
+                               udelay(50);
                                atombios_dig_encoder_setup(encoder, ATOM_ENCODER_CMD_DP_VIDEO_ON, 0);
+                               udelay(50);
+                               atombios_dig_encoder_setup(encoder, ATOM_ENCODER_CMD_DP_VIDEO_ON, 0);
+                       }
                }
                if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT))
                        atombios_dig_transmitter_setup(encoder,

Or move the backlight enable before the link training:
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c
index a7f2ddf..3bfbfa4 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1682,6 +1682,9 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder *encoder, int mode)
                                radeon_dig_connector->edp_on = true;
                        }
                }
+               if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT))
+                       atombios_dig_transmitter_setup(encoder,
+                                                      ATOM_TRANSMITTER_ACTION_LCD_BLON, 0, 0);
                /* enable the transmitter */
                atombios_dig_transmitter_setup(encoder, ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
                if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(encoder)) && connector) {
@@ -1690,9 +1693,6 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder *encoder, int mode)
                        if (ASIC_IS_DCE4(rdev))
                                atombios_dig_encoder_setup(encoder, ATOM_ENCODER_CMD_DP_VIDEO_ON, 0);
                }
-               if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT))
-                       atombios_dig_transmitter_setup(encoder,
-                                                      ATOM_TRANSMITTER_ACTION_LCD_BLON, 0, 0);
                if (ext_encoder)
                        atombios_external_encoder_setup(encoder, ext_encoder, ATOM_ENABLE);
                break;

Or drop the backlight control altogether to see if that helps:
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c
index a7f2ddf..9713078 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1690,9 +1690,6 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder *encoder, int mode)
                        if (ASIC_IS_DCE4(rdev))
                                atombios_dig_encoder_setup(encoder, ATOM_ENCODER_CMD_DP_VIDEO_ON, 0);
                }
-               if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT))
-                       atombios_dig_transmitter_setup(encoder,
-                                                      ATOM_TRANSMITTER_ACTION_LCD_BLON, 0, 0);
                if (ext_encoder)
                        atombios_external_encoder_setup(encoder, ext_encoder, ATOM_ENABLE);
                break;
@@ -1705,10 +1702,6 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder *encoder, int mode)
                }
                if (ext_encoder)
                        atombios_external_encoder_setup(encoder, ext_encoder, ATOM_DISABLE);
-               if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT))
-                       atombios_dig_transmitter_setup(encoder,
-                                                      ATOM_TRANSMITTER_ACTION_LCD_BLOFF, 0, 0);
-
                if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(encoder)) &&
                    connector && !travis_quirk)
                        radeon_dp_set_rx_power_state(connector, DP_SET_POWER_D3);

Well, turns out that I may have said that too soon. ;) Gnome does not work anymore (gnome-session quits right after login), that may be an issue with gnome 3.14 and catalyst, not 100% sure. For some people it's working, for some it isn't. Now I'm using  KDE, which kinda  works, but I don't like it. It's ugly, it's different, and none of my typical workflows do what they did any more. But that's just ranting since I'm pissed at all those small issues with KDE. And at the 3 hours I thought my catalyst installation was broken when it was actually gnome which did not start. ;)

Right now I use 3.16, the tests I did with the radeon driver which led me here were with 3.16. I could test 3.14 (arch's lts kernel) with relative ease. If I get some pointers what info to provide, or what to try, I can do that. Right now, I am clueless in how to debug further, where relevant info is written to and so on.

@comment65 Thanks for those hints. Trying that will take a couple of days. I need to figure out how to compile kernel modules in arch first.

Is there a dev (you?) who lives in germany by any chance? Would it help / be possible that I mail the Laptop, so some dev can try it hands on?

I also had problem with this laptop.
I fixed it by enabling CSM in the BIOS.
Here is a horrible picture of the bios setting in question: imgur.com/4p6ziEo

I had the issue with mint 16/17
The screen was blank after grub until i successfully logged into an x session (usually less then 10 retry to get there). 

With debian wheezy (7.7 kernel 3.2) the issue manifest itself later on
It seems to me that it happens when the handover from frambuffer to the radeon driver (with modesetting enabled) is done.
I issue was also present with fglrx on debian.

Since the change to the bios it all works correctly.
Now grub and the framebuffer are limited to an ungly 1024x768 but it works.

I can provide logs if that could be of any help.

(In reply to Alex Deucher from comment #65)
> *snip*
> 
> In reply to Christian Aßfalg from comment #63)
> > I think / guess that I am having the same issues. I've got the same laptop,
> > running Arch Linux. Mostly, I've been using the proprietary catalyst driver,
> > since I never got the free driver working. The proprietary is working fine.
> > 
> > What is the issue here? You've been playing with timings for the physical
> > link to the internal panel? Is it so frickly? What would you need to fix the
> > issue? How can I help?
> 
> I suggested that it might be a timing issue, and as per comment 54. 
> However, link training is successful so that monitor accepts the parameters
> that the driver proposed, it just sometimes chooses not to light up.  I
> would suggest trying to tweak the link training timing as per comment 54,
> try disabling ss as per comment 6, and finally, try making some slight
> changes to the modeset sequence as per the attached patch.  The patch adds a
> delay before enabling the video stream and additionally calls the enable
> video stream code again in case the monitor didn't quite get the signal the
> first time.  E.g.,
> *snip*

I also have the same problem. (same notebook, so not surprising)

I tried everything you recommended (in comment #65), in order, nothing helps. Any more suggestions?

Btw, I'm using OpenSUSE, so Kernel 3.16.6.

Also xrandr output is much shorter than the ones posted here, is that normal when you use modeset=0?

xrandr -q --verbose
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 1920 x 1080, current 1920 x 1080, maximum 1920 x 1080
default connected primary 1920x1080+0+0 (0x180) normal (normal) 0mm x 0mm
        Identifier: 0x17f
        Timestamp:  7692
        Subpixel:   unknown
        Clones:    
        CRTC:       0
        CRTCs:      0
        Transform:  1.000000 0.000000 0.000000
                    0.000000 1.000000 0.000000
                    0.000000 0.000000 1.000000
                   filter: 
  1920x1080 (0x180) 159.667MHz *current
        h: width  1920 start    0 end    0 total 1920 skew    0 clock  83.16KHz
        v: height 1080 start    0 end    0 total 1080           clock  77.00Hz

(In reply to Nicolas Werner from comment #69)
> 
> I also have the same problem. (same notebook, so not surprising)
> 
> I tried everything you recommended (in comment #65), in order, nothing
> helps. Any more suggestions?

Does this patch help?
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c9498425453bb65ef339a57705c5ef59fe1541d

> 
> Btw, I'm using OpenSUSE, so Kernel 3.16.6.
> 
> Also xrandr output is much shorter than the ones posted here, is that normal
> when you use modeset=0?

Yes.  When you set modeset=0 you are effectively disabling the radeon driver so you end up with vesa or efifb or some other platform driver rather than the native driver.

Created attachment 109638 [details]
dmesg with drm/radeon: add locking around atombios scratch space usage

(In reply to Alex Deucher from comment #70)
> (In reply to Nicolas Werner from comment #69)
> > 
> > I also have the same problem. (same notebook, so not surprising)
> > 
> > I tried everything you recommended (in comment #65), in order, nothing
> > helps. Any more suggestions?
> 
> Does this patch help?
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> ?id=1c9498425453bb65ef339a57705c5ef59fe1541d
> 
Well, not enough, to get something other than a black screen or some flickering before between white and black before it decides to stay black. :/
dmesg with debug attached

> > 
> > Btw, I'm using OpenSUSE, so Kernel 3.16.6.
> > 
> > Also xrandr output is much shorter than the ones posted here, is that normal
> > when you use modeset=0?
> 
> Yes.  When you set modeset=0 you are effectively disabling the radeon driver
> so you end up with vesa or efifb or some other platform driver rather than
> the native driver.

Makes sense, thanks!

I'm having the same issue, but it seems to be getting worse with newer kernels. I was able to do the suspend/resume trick to get a working screen, but this seems to have stopped working with kernel 3.16 and 3.17. No amount of suspending/resuming seems to get the screen to appear now, so I've had to stick with 3.15 for the time being. I'm on Arch, so packages are fairly generic, but I can provide any information that would help.

(In reply to Benjamin from comment #72)
> I'm having the same issue, but it seems to be getting worse with newer
> kernels. I was able to do the suspend/resume trick to get a working screen,
> but this seems to have stopped working with kernel 3.16 and 3.17. No amount
> of suspending/resuming seems to get the screen to appear now, so I've had to
> stick with 3.15 for the time being. I'm on Arch, so packages are fairly
> generic, but I can provide any information that would help.

Can you bisect and see what commit made it worse?  That might help narrow down the problem.

(In reply to Alex Deucher from comment #73)
> (In reply to Benjamin from comment #72)
> > I'm having the same issue, but it seems to be getting worse with newer
> > kernels. I was able to do the suspend/resume trick to get a working screen,
> > but this seems to have stopped working with kernel 3.16 and 3.17. No amount
> > of suspending/resuming seems to get the screen to appear now, so I've had to
> > stick with 3.15 for the time being. I'm on Arch, so packages are fairly
> > generic, but I can provide any information that would help.
> 
> Can you bisect and see what commit made it worse?  That might help narrow
> down the problem.

Alex, I’ll soon have access to that device again. Unfortunately, doing a bisect for me does not work as there is no clear way to figure out if it worked or not.

Isn’t there some software, testing “all panel timings” and the user can say, which worked?

That Asus laptop is/was one of the few AMD laptops out there, so it’s sad that GNU/Linux doesn’t run properly on it.

Can anyone provide me with some devel tools to make research of this problem?

I've already tried to play with delays in linux-4.0.1, tried drm-next with no success.

At this point I have two variants - to look/disassemble fglrx and/or get track of driver kms-init to solve this problem.

Created attachment 115626 [details]
dmesg drm debug kernel 3.18

I am also interested in providing help to fix this bug.

I even tried to bisect it, but I somehow didn't quite unterstand, how to reproduce the working case, so it didn't give me any interesting results.

I'm attaching a log of my new setup using gentoo, before I switched to fglrx.
It's from kernel 3.18 (current stable in gentoo) and was produced after booting with nomodeset and unloading radeon, drm etc
then doing
modprobe -v drm debug=1
modprobe -v radeon modesetting=1

then printing dmesg to a file.

Greetings,
Nicolas

Created attachment 115629 [details]
Panel datasheet

At this time I managed to get working video-stream to panel, but the timings is obviously wrong. The main problem is Spread Spectrum somehow get disabled in reinit cycle, and not enabled, so I just removed SS management and got blinking noise on the screen.
Also I added some delays that necessary for this panel (maybe all another needs it too). Due to attached datasheet on page 15 we got sequence of power-on and power-off for this panel. Interesting this is Reset interval of 500ms which is mandatory between power-off panel and powering it back on.

Now I'm trying to figure initial PLL setings that BIOS set before OS starts, after that I'll try to fix this behaviour. I don't fully know vesa framebuffer initialization, but as I understand, it get values from VBIOS/default BIOS address space for VGA and trying to apply them. Moreover, when radeon KMS is off I got fully different values of Modeline comparing to EDID.

Please note that DP is not direct clocked.  The link runs at either 1.62 or 2.7 Ghz depending on the bandwidth requirements.

(In reply to Alex Deucher from comment #78)
> Please note that DP is not direct clocked.  The link runs at either 1.62 or
> 2.7 Ghz depending on the bandwidth requirements.

Yes, thanks, I figured it out from driver. One more thing that I've not already searched - the DP lanes init, actually we need 2 lanes for FHD 24-bit mode as mentioned in DP brochures (they mention it in comparison table with LVDS interface). I may be wrong at this point, just a suggestion. But flickering, that I saw is about quarter of screen on left top corner.

For long time digging radeon drivers I got it working perfectly.

As I mentioned above, the problem is in DP initialization. Somewhere in code DPCD get NULL'ed and function radeon_dp_get_dp_lane_number in atombios.c returns 1 lane which is not right (now I hardcoded return 2, cause dpcd[0x002] is '0').

It seems to be a general problem for FHD panels with DisplayPort and radeon GPU due to same BUGs commited in bugtracker.

I'll continue digging at this BUG and recheck with SpreadSpectrum enabled. After that provide patch.

I can confirm that hacking radeon_dp_get_dp_lane_number to return 2 does yield a working display (and acceleration), great find!

Yes, it seems this bug https://bugs.freedesktop.org/show_bug.cgi?id=90320 is connected with our BUG.

As for this moment, no changes in SS and DPMS_ON/DPMS_OFF needed to get working display. It is only a matter of DPCD elements was broken at some point. 

Digging further.

Created attachment 115699 [details] [review]
possible fix

Is the dpcd information always wrong or just sometimes?  If it's always wrong, the attached patch might help.  If it's only sometimes wrong, we probably need to figure out under what conditions it's wrong.

(In reply to Alex Deucher from comment #83)
> Created attachment 115699 [details] [review] [review]
> possible fix
> 
> Is the dpcd information always wrong or just sometimes?  If it's always
> wrong, the attached patch might help.  If it's only sometimes wrong, we
> probably need to figure out under what conditions it's wrong.

In my case it was always wrong at point of rate/link calculation, but DPCD itself read right, cause I see in dmesg:
[drm:radeon_dp_getdpcd] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00

According to this DPCD info we need 0x84 value masked with 0x1f which must return maximum of 4 lanes. But in function radeon_dp_get_dp_lane_number I got dpcd with all zeros instead. So I concluded that somewhere in flow it got NULL'ed.


I'll check your patch in two-three hours later, little busy at the moment. But is it wise to make additional copies of same data? Maybe I'm a little paranoid, but I always thought that this method is the last variant of solution due to memory consumption. We need to find, where it blows configuration data so in other configurations it'll work as suspected not only in this combination of eDP and LVDS encoder, please correct me if I'm wrong.

(In reply to N.Leiten from comment #84)
> (In reply to Alex Deucher from comment #83)
> > Created attachment 115699 [details] [review] [review] [review]
> > possible fix
> > 
> > Is the dpcd information always wrong or just sometimes?  If it's always
> > wrong, the attached patch might help.  If it's only sometimes wrong, we
> > probably need to figure out under what conditions it's wrong.
> 
> In my case it was always wrong at point of rate/link calculation, but DPCD
> itself read right, cause I see in dmesg:
> [drm:radeon_dp_getdpcd] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
> 
> According to this DPCD info we need 0x84 value masked with 0x1f which must
> return maximum of 4 lanes. But in function radeon_dp_get_dp_lane_number I
> got dpcd with all zeros instead. So I concluded that somewhere in flow it
> got NULL'ed.
> 

Ok, the patch shouldn't be necessary then.

> 
> I'll check your patch in two-three hours later, little busy at the moment.
> But is it wise to make additional copies of same data? Maybe I'm a little
> paranoid, but I always thought that this method is the last variant of
> solution due to memory consumption. We need to find, where it blows
> configuration data so in other configurations it'll work as suspected not
> only in this combination of eDP and LVDS encoder, please correct me if I'm
> wrong.

There's one copy that gets fetched when the displays are probed (radeon_dp_getdpcd gets called from radeon_connectors.c).  Then radeon_dp_set_link_config() which selects the number of names and link rate gets called form radeon_atom_mode_fixup() before the mode is set.

(In reply to Alex Deucher from comment #85)
> (In reply to N.Leiten from comment #84)
> > (In reply to Alex Deucher from comment #83)
> > > Created attachment 115699 [details] [review] [review] [review] [review]
> > > possible fix
> > > 
> > > Is the dpcd information always wrong or just sometimes?  If it's always
> > > wrong, the attached patch might help.  If it's only sometimes wrong, we
> > > probably need to figure out under what conditions it's wrong.
> > 
> > In my case it was always wrong at point of rate/link calculation, but DPCD
> > itself read right, cause I see in dmesg:
> > [drm:radeon_dp_getdpcd] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
> > 
> > According to this DPCD info we need 0x84 value masked with 0x1f which must
> > return maximum of 4 lanes. But in function radeon_dp_get_dp_lane_number I
> > got dpcd with all zeros instead. So I concluded that somewhere in flow it
> > got NULL'ed.
> > 
> 
> Ok, the patch shouldn't be necessary then.
> 
> > 
> > I'll check your patch in two-three hours later, little busy at the moment.
> > But is it wise to make additional copies of same data? Maybe I'm a little
> > paranoid, but I always thought that this method is the last variant of
> > solution due to memory consumption. We need to find, where it blows
> > configuration data so in other configurations it'll work as suspected not
> > only in this combination of eDP and LVDS encoder, please correct me if I'm
> > wrong.
> 
> There's one copy that gets fetched when the displays are probed
> (radeon_dp_getdpcd gets called from radeon_connectors.c).  Then
> radeon_dp_set_link_config() which selects the number of names and link rate
> gets called form radeon_atom_mode_fixup() before the mode is set.

Thanks for points of start :) I'll workout this ASAP.

Well, forcing radeon_dp_get_dp_lane_number to return 2 did not help in my case (https://bugs.freedesktop.org/show_bug.cgi?id=90320) which means the bugs aren't necessarily related :| My (unpatched) dmesg shows this DPCD, which seems normal:

[drm:radeon_dp_getdpcd] DPCD: 11 0a 02 41 00 00 01 c0 02 00 00 00 00 09 00

(In reply to N.Leiten from comment #77)
Can you please provide a sample patch on how did you remove SS management and where did you inserted the delays?

My panel may have slightly different spec than U38N, but I have a feeling the problem may be the timings. Still trying to get my hands on the panel data, only could find it @ panelook.com, but don't have 'p-coins' to get the PDF. Does anyone have access to panelook.com?

Created attachment 115774 [details] [review]
add some debugging output

Can you attach your dmesg output with this patch attached?  It should help narrow down where the dpcd info is getting corrupted.

(In reply to Alex Deucher from comment #88)
> Created attachment 115774 [details] [review] [review]
> add some debugging output
> 
> Can you attach your dmesg output with this patch attached?  It should help
> narrow down where the dpcd info is getting corrupted.

Here it is (only the relevant section):
[    5.534907] [drm] radeon_dp_getdpcd
[    5.534913] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    5.565816] [drm] fb mappable at 0xD047B000
[    5.565823] [drm] vram apper at 0xD0000000
[    5.565825] [drm] size 8294400
[    5.565828] [drm] fb depth is 24
[    5.565830] [drm]    pitch is 7680
[    5.566022] fbcon: radeondrmfb (fb0) is primary device
[    5.566093] [drm] radeon_dp_set_link_config, 270000, 2
[    5.566095] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    6.706063] [drm] radeon_dp_set_rx_power_state, 0
[    6.706065] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    7.843201] [drm] radeon_dp_link_train
[    7.843203] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    7.843204] [drm] dp_info dpcd: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    7.843206] [drm] radeon_dp_set_rx_power_state, 0
[    7.843206] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

(In reply to Nicolas Werner from comment #89)
> (In reply to Alex Deucher from comment #88)
> > Created attachment 115774 [details] [review] [review] [review]
> > add some debugging output
> > 
> > Can you attach your dmesg output with this patch attached?  It should help
> > narrow down where the dpcd info is getting corrupted.
> 
> Here it is (only the relevant section):
> [    5.534907] [drm] radeon_dp_getdpcd
> [    5.534913] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
> [    5.565816] [drm] fb mappable at 0xD047B000
> [    5.565823] [drm] vram apper at 0xD0000000
> [    5.565825] [drm] size 8294400
> [    5.565828] [drm] fb depth is 24
> [    5.565830] [drm]    pitch is 7680
> [    5.566022] fbcon: radeondrmfb (fb0) is primary device
> [    5.566093] [drm] radeon_dp_set_link_config, 270000, 2
> [    5.566095] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Are you still hardcoding the lanes here?


> [    6.706063] [drm] radeon_dp_set_rx_power_state, 0
> [    6.706065] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [    7.843201] [drm] radeon_dp_link_train
> [    7.843203] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [    7.843204] [drm] dp_info dpcd: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00
> [    7.843206] [drm] radeon_dp_set_rx_power_state, 0
> [    7.843206] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

(In reply to Alex Deucher from comment #90)
> (In reply to Nicolas Werner from comment #89)
> > (In reply to Alex Deucher from comment #88)
> > > Created attachment 115774 [details] [review] [review] [review] [review]
> > > add some debugging output
> > > 
> > > Can you attach your dmesg output with this patch attached?  It should help
> > > narrow down where the dpcd info is getting corrupted.
> > 
> > Here it is (only the relevant section):
> > [    5.534907] [drm] radeon_dp_getdpcd
> > [    5.534913] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
> > [    5.565816] [drm] fb mappable at 0xD047B000
> > [    5.565823] [drm] vram apper at 0xD0000000
> > [    5.565825] [drm] size 8294400
> > [    5.565828] [drm] fb depth is 24
> > [    5.565830] [drm]    pitch is 7680
> > [    5.566022] fbcon: radeondrmfb (fb0) is primary device
> > [    5.566093] [drm] radeon_dp_set_link_config, 270000, 2
> > [    5.566095] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 
> Are you still hardcoding the lanes here?
> 
> 
> > [    6.706063] [drm] radeon_dp_set_rx_power_state, 0
> > [    6.706065] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > [    7.843201] [drm] radeon_dp_link_train
> > [    7.843203] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > [    7.843204] [drm] dp_info dpcd: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 00
> > [    7.843206] [drm] radeon_dp_set_rx_power_state, 0
> > [    7.843206] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Yes, I wouldn't get a working display otherwise, should I try without it?

I accidently truncated the dmesg output, here's everything containing drm:
[    2.430644] [drm] Initialized drm 1.1.0 20060810
[    2.461050] [drm] radeon kernel modesetting enabled.
[    2.467555] fb: switching to radeondrmfb from simple
[    2.470628] [drm] initializing kernel modesetting (ARUBA 0x1002:0x9908 0x1043:0x1557).
[    2.470651] [drm] register mmio base: 0xFEB00000
[    2.470695] [drm] register mmio size: 262144
[    2.470704] [drm] ACPI VFCT contains a BIOS for 00:01.0 1002:9908, size 19968
[    2.470848] [drm] Detected VRAM RAM=768M, BAR=256M
[    2.470851] [drm] RAM width 64bits DDR
[    2.486341] [drm] radeon: 768M of VRAM memory ready
[    2.486345] [drm] radeon: 1024M of GTT memory ready.
[    2.486411] [drm] Loading ARUBA Microcode
[    2.492679] [drm] Internal thermal controller without fan control
[    2.493274] [drm] radeon: dpm initialized
[    2.494685] [drm] GART: num cpu pages 262144, num gpu pages 262144
[    2.606096] [drm] PCIE GART of 1024M enabled (table at 0x0000000000277000).
[    2.619553] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    2.619555] [drm] Driver supports precise vblank timestamp query.
[    2.619902] [drm] radeon: irq initialized.
[    2.709613] [drm] ring test on 0 succeeded in 2 usecs
[    2.709627] [drm] ring test on 3 succeeded in 3 usecs
[    2.709636] [drm] ring test on 4 succeeded in 3 usecs
[    2.978514] [drm] ring test on 5 succeeded in 1 usecs
[    3.006343] [drm] UVD initialized successfully.
[    3.016637] [drm] ib test on ring 0 succeeded in 0 usecs
[    3.017179] [drm] ib test on ring 3 succeeded in 0 usecs
[    3.017722] [drm] ib test on ring 4 succeeded in 0 usecs
[    3.039679] [drm] ib test on ring 5 succeeded
[    3.089055] [drm] radeon atom DIG backlight initialized
[    3.089064] [drm] Radeon Display Connectors
[    3.089066] [drm] Connector 0:
[    3.089069] [drm]   eDP-1
[    3.089071] [drm]   HPD1
[    3.089075] [drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c
[    3.089076] [drm]   Encoders:
[    3.089079] [drm]     LCD1: INTERNAL_UNIPHY2
[    3.089080] [drm] Connector 1:
[    3.089082] [drm]   VGA-1
[    3.089084] [drm]   HPD2
[    3.089086] [drm]   DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 0x654c
[    3.089087] [drm]   Encoders:
[    3.089089] [drm]     CRT1: INTERNAL_UNIPHY2
[    3.089091] [drm]     CRT1: NUTMEG
[    3.089092] [drm] Connector 2:
[    3.089094] [drm]   HDMI-A-1
[    3.089095] [drm]   HPD3
[    3.089097] [drm]   DDC: 0x6550 0x6550 0x6554 0x6554 0x6558 0x6558 0x655c 0x655c
[    3.089099] [drm]   Encoders:
[    3.089100] [drm]     DFP1: INTERNAL_UNIPHY
[    5.243213] [drm] radeon_dp_getdpcd
[    5.243219] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    5.274840] [drm] fb mappable at 0xD047B000
[    5.274847] [drm] vram apper at 0xD0000000
[    5.274855] [drm] size 8294400
[    5.274859] [drm] fb depth is 24
[    5.274861] [drm]    pitch is 7680
[    5.275084] fbcon: radeondrmfb (fb0) is primary device
[    5.275155] [drm] radeon_dp_set_link_config, 270000, 2
[    5.275156] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    6.415109] [drm] radeon_dp_set_rx_power_state, 0
[    6.415111] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    7.551762] [drm] radeon_dp_link_train
[    7.551764] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    7.551765] [drm] dp_info dpcd: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    7.551767] [drm] radeon_dp_set_rx_power_state, 0
[    7.551768] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    7.962006] radeon 0000:00:01.0: fb0: radeondrmfb frame buffer device
[    8.186573] [drm] Initialized radeon 2.40.0 20080528 for 0000:00:01.0 on minor 0
[   11.153606] [drm] radeon_dp_getdpcd
[   11.153612] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   11.183328] [drm] radeon_dp_getdpcd
[   11.183337] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   11.245364] [drm] radeon_dp_getdpcd
[   11.245371] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   11.277369] [drm] radeon_dp_getdpcd
[   11.277378] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   20.940212] [drm] radeon_dp_getdpcd
[   20.940218] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   20.968521] [drm] radeon_dp_getdpcd
[   20.968531] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   23.727223] [drm] radeon_dp_getdpcd
[   23.727231] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   23.754387] [drm] radeon_dp_getdpcd
[   23.754396] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00

Created attachment 115778 [details] [review]
debuging patch

Your dpcd is indeed getting corrupted somehow.  I can't see how though.  The attached patch (please drop your hardcode to 2 patch when you apply this one) should workaround the issue by re-fetching the dpcd when required, but doesn't fix the root cause.  Please attach the dmesg output with this patch applied as well.  I'd like to see how often it's getting corrupted.

(In reply to Alex Deucher from comment #93)
> Created attachment 115778 [details] [review] [review]
> debuging patch
> 
> Your dpcd is indeed getting corrupted somehow.  I can't see how though.  The
> attached patch (please drop your hardcode to 2 patch when you apply this
> one) should workaround the issue by re-fetching the dpcd when required, but
> doesn't fix the root cause.  Please attach the dmesg output with this patch
> applied as well.  I'd like to see how often it's getting corrupted.

Interestingly this doesn't work, I get the same blackscreen as usually:

[    5.946595] [drm] radeon_dp_getdpcd
[    5.946601] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    5.978557] [drm] fb mappable at 0xD047B000
[    5.978563] [drm] vram apper at 0xD0000000
[    5.978565] [drm] size 8294400
[    5.978567] [drm] fb depth is 24
[    5.978569] [drm]    pitch is 7680
[    5.978789] fbcon: radeondrmfb (fb0) is primary device
[    5.978881] [drm:radeon_dp_set_link_config] *ERROR* corrupt dpcd, updating
[    5.979556] [drm] radeon_dp_set_link_config, 540000, 1
[    5.979558] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    7.118887] [drm] radeon_dp_set_rx_power_state, 0
[    7.118889] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    7.118891] [drm:radeon_dp_set_rx_power_state] *ERROR* corrupt dpcd, updating
[    8.254349] [drm:radeon_dp_link_train] *ERROR* corrupt dpcd, updating
[    8.255018] [drm] radeon_dp_link_train
[    8.255019] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    8.255020] [drm] dp_info dpcd: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    8.255022] [drm] radeon_dp_set_rx_power_state, 0
[    8.255023] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    8.255024] [drm:radeon_dp_set_rx_power_state] *ERROR* corrupt dpcd, updating
[    8.255326] [drm] radeon_dp_getdpcd
[    8.255326] [drm] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00
[    8.263438] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery tried 5 times
[    8.263440] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed
[    8.662772] radeon 0000:00:01.0: fb0: radeondrmfb frame buffer device
[    8.691450] [drm] Initialized radeon 2.40.0 20080528 for 0000:00:01.0 on minor 0
[   11.436860] [drm] radeon_dp_getdpcd
[   11.436866] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   11.467143] [drm] radeon_dp_getdpcd
[   11.467151] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   11.530015] [drm] radeon_dp_getdpcd
[   11.530021] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   11.558174] [drm] radeon_dp_getdpcd
[   11.558182] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00

Created attachment 115780 [details] [review]
add some debugging output

Can you attach the dmesg output with the attached patch?

(In reply to Alex Deucher from comment #95)
> Created attachment 115780 [details] [review] [review]
> add some debugging output
> 
> Can you attach the dmesg output with the attached patch?

Seems like we're getting somewhere, looks like a bad pointer?

[    5.645981] [drm] radeon_dp_getdpcd
[    5.645988] [drm] dig_connector ffff8802a21c42c0
[    5.645991] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    5.677325] [drm] fb mappable at 0xD047B000
[    5.677330] [drm] vram apper at 0xD0000000
[    5.677332] [drm] size 8294400
[    5.677335] [drm] fb depth is 24
[    5.677337] [drm]    pitch is 7680
[    5.677542] fbcon: radeondrmfb (fb0) is primary device
[    5.677635] [drm:radeon_dp_set_link_config] *ERROR* corrupt dpcd, updating
[    5.678223] [drm] radeon_dp_set_link_config, 540000, 1
[    5.678224] [drm] dig_connector ffff8802a21c42a0
[    5.678225] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    6.818832] [drm:radeon_dp_set_rx_power_state] *ERROR* corrupt dpcd, updating
[    6.819418] [drm] radeon_dp_set_rx_power_state, 0
[    6.819420] [drm] dig_connector ffff8802a21c42a0
[    6.819421] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    7.953814] [drm:radeon_dp_link_train] *ERROR* corrupt dpcd, updating
[    7.954642] [drm] radeon_dp_link_train
[    7.954644] [drm] dig_connector ffff8802a21c42a0
[    7.954645] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    7.954646] [drm] dp_info dpcd: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    7.954647] [drm:radeon_dp_set_rx_power_state] *ERROR* corrupt dpcd, updating
[    7.954950] [drm] radeon_dp_getdpcd
[    7.954951] [drm] dig_connector ffff8802a21c42a0
[    7.954952] [drm] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00
[    7.954954] [drm] radeon_dp_set_rx_power_state, 17
[    7.954955] [drm] dig_connector ffff8802a21c42a0
[    7.954956] [drm] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00
[    7.962990] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery tried 5 times
[    7.962991] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed
[    8.361691] radeon 0000:00:01.0: fb0: radeondrmfb frame buffer device
[    8.390386] [drm] Initialized radeon 2.40.0 20080528 for 0000:00:01.0 on minor 0
[   10.548765] [drm] radeon_dp_getdpcd
[   10.548773] [drm] dig_connector ffff8802a21c42c0
[   10.548777] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   10.579288] [drm] radeon_dp_getdpcd
[   10.579297] [drm] dig_connector ffff8802a21c42c0
[   10.579300] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   10.638418] [drm] radeon_dp_getdpcd
[   10.638425] [drm] dig_connector ffff8802a21c42c0
[   10.638428] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   10.667255] [drm] radeon_dp_getdpcd
[   10.667263] [drm] dig_connector ffff8802a21c42c0
[   10.667267] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00

Created attachment 115782 [details] [review]
more debugging

Can you attach your dmesg output with the attached patch?  Please include all the radeon related output.

(In reply to Alex Deucher from comment #97)
> Created attachment 115782 [details] [review] [review]
> more debugging
> 
> Can you attach your dmesg output with the attached patch?  Please include
> all the radeon related output.

Is this enough?

[    2.532444] [drm] Initialized drm 1.1.0 20060810
[    2.562855] [drm] radeon kernel modesetting enabled.
[    2.562913] checking generic (d0000000 7e9000) vs hw (d0000000 10000000)
[    2.562917] fb: switching to radeondrmfb from simple
[    2.562965] Console: switching to colour dummy device 80x25
[    2.567745] [drm] initializing kernel modesetting (ARUBA 0x1002:0x9908 0x1043:0x1557).
[    2.567772] [drm] register mmio base: 0xFEB00000
[    2.567775] [drm] register mmio size: 262144
[    2.567784] [drm] ACPI VFCT contains a BIOS for 00:01.0 1002:9908, size 19968
[    2.567802] ATOM BIOS: 113
[    2.568799] radeon 0000:00:01.0: VRAM: 768M 0x0000000000000000 - 0x000000002FFFFFFF (768M used)
[    2.568806] radeon 0000:00:01.0: GTT: 1024M 0x0000000030000000 - 0x000000006FFFFFFF
[    2.568810] [drm] Detected VRAM RAM=768M, BAR=256M
[    2.568812] [drm] RAM width 64bits DDR
[    2.579994] Switched to clocksource tsc
[    2.585466] [TTM] Zone  kernel: Available graphics memory: 4705338 kiB
[    2.585472] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[    2.585476] [TTM] Initializing pool allocator
[    2.585488] [TTM] Initializing DMA pool allocator
[    2.585533] [drm] radeon: 768M of VRAM memory ready
[    2.585536] [drm] radeon: 1024M of GTT memory ready.
[    2.585582] [drm] Loading ARUBA Microcode
[    2.590637] [drm] Internal thermal controller without fan control
[    2.590894] [drm] radeon: dpm initialized
[    2.592447] [drm] GART: num cpu pages 262144, num gpu pages 262144
[    2.645584] [drm] PCIE GART of 1024M enabled (table at 0x0000000000277000).
[    2.645765] radeon 0000:00:01.0: WB enabled
[    2.645772] radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000030000c00 and cpu addr 0xffff88029f884c00
[    2.646514] radeon 0000:00:01.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 and cpu addr 0xffffc900128b5a18
[    2.646521] radeon 0000:00:01.0: fence driver on ring 1 use gpu addr 0x0000000030000c04 and cpu addr 0xffff88029f884c04
[    2.646525] radeon 0000:00:01.0: fence driver on ring 2 use gpu addr 0x0000000030000c08 and cpu addr 0xffff88029f884c08
[    2.646530] radeon 0000:00:01.0: fence driver on ring 3 use gpu addr 0x0000000030000c0c and cpu addr 0xffff88029f884c0c
[    2.646535] radeon 0000:00:01.0: fence driver on ring 4 use gpu addr 0x0000000030000c10 and cpu addr 0xffff88029f884c10
[    2.674649] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    2.674655] [drm] Driver supports precise vblank timestamp query.
[    2.674663] radeon 0000:00:01.0: radeon: MSI limited to 32-bit
[    2.674695] radeon 0000:00:01.0: irq 36 for MSI/MSI-X
[    2.674717] radeon 0000:00:01.0: radeon: using MSI.
[    2.675019] [drm] radeon: irq initialized.
[    2.902862] [drm] ring test on 0 succeeded in 2 usecs
[    2.902875] [drm] ring test on 3 succeeded in 3 usecs
[    2.902884] [drm] ring test on 4 succeeded in 3 usecs
[    2.993926] [drm] ring test on 5 succeeded in 1 usecs
[    3.096637] [drm] UVD initialized successfully.
[    3.157693] [drm] ib test on ring 0 succeeded in 0 usecs
[    3.158239] [drm] ib test on ring 3 succeeded in 0 usecs
[    3.158774] [drm] ib test on ring 4 succeeded in 0 usecs
[    3.217327] [drm] ib test on ring 5 succeeded
[    3.268198] [drm] radeon atom DIG backlight initialized
[    3.268207] [drm] Radeon Display Connectors
[    3.268212] [drm] Connector 0 ffff8802a1878c00 0x00000002:
[    3.268216] [drm]   eDP-1
[    3.268219] [drm]   HPD1
[    3.268224] [drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c
[    3.268227] [drm]   Encoders:
[    3.268231] [drm]   encoder: ffff8802a0a91a00, 0x00000002
[    3.268233] [drm]     LCD1: INTERNAL_UNIPHY2
[    3.268235] [drm]   encoder: ffff8802a0a90600, 0x00000001
[    3.268238] [drm]   encoder: ffff8802a0a90200, 0x00000001
[    3.268245] [drm]   encoder: ffff8802a0a90800, 0x00000008
[    3.268248] [drm] Connector 1 ffff8802a1879c00 0x00000001:
[    3.268250] [drm]   VGA-1
[    3.268252] [drm]   HPD2
[    3.268255] [drm]   DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 0x654c
[    3.268258] [drm]   Encoders:
[    3.268261] [drm]   encoder: ffff8802a0a91a00, 0x00000002
[    3.268264] [drm]   encoder: ffff8802a0a90600, 0x00000001
[    3.268266] [drm]     CRT1: INTERNAL_UNIPHY2
[    3.268268] [drm]   encoder: ffff8802a0a90200, 0x00000001
[    3.268270] [drm]     CRT1: NUTMEG
[    3.268276] [drm]   encoder: ffff8802a0a90800, 0x00000008
[    3.268279] [drm] Connector 2 ffff8802a187b800 0x00000008:
[    3.268281] [drm]   HDMI-A-1
[    3.268283] [drm]   HPD3
[    3.268286] [drm]   DDC: 0x6550 0x6550 0x6554 0x6554 0x6558 0x6558 0x655c 0x655c
[    3.268289] [drm]   Encoders:
[    3.268291] [drm]   encoder: ffff8802a0a91a00, 0x00000002
[    3.268293] [drm]   encoder: ffff8802a0a90600, 0x00000001
[    3.268295] [drm]   encoder: ffff8802a0a90200, 0x00000001
[    3.268296] [drm]   encoder: ffff8802a0a90800, 0x00000008
[    3.268298] [drm]     DFP1: INTERNAL_UNIPHY
[    5.689859] [drm] radeon_dp_getdpcd ffff8802a1879c00
[    5.689864] [drm] dig_connector ffff8802a335fd80
[    5.689867] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    5.721938] [drm] fb mappable at 0xD047B000
[    5.721944] [drm] vram apper at 0xD0000000
[    5.721947] [drm] size 8294400
[    5.721950] [drm] fb depth is 24
[    5.721952] [drm]    pitch is 7680
[    5.722277] fbcon: radeondrmfb (fb0) is primary device
[    5.722365] [drm:radeon_dp_set_link_config] *ERROR* corrupt dpcd, updating
[    5.722952] [drm] radeon_dp_set_link_config, ffff8802a1878c00, 540000, 1
[    5.722953] [drm] dig_connector ffff8802a335fd60
[    5.722954] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    6.865341] [drm:radeon_dp_set_rx_power_state] *ERROR* corrupt dpcd, updating
[    6.865932] [drm] radeon_dp_set_rx_power_state, ffff8802a1878c00, 0
[    6.865933] [drm] dig_connector ffff8802a335fd60
[    6.865934] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    8.001613] [drm:radeon_dp_link_train] *ERROR* corrupt dpcd, updating
[    8.002284] [drm] radeon_dp_link_train, ffff8802a1878c00
[    8.002285] [drm] dig_connector ffff8802a335fd60
[    8.002287] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    8.002287] [drm] dp_info dpcd: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    8.002289] [drm:radeon_dp_set_rx_power_state] *ERROR* corrupt dpcd, updating
[    8.002594] [drm] radeon_dp_getdpcd ffff8802a1878c00
[    8.002595] [drm] dig_connector ffff8802a335fd60
[    8.002595] [drm] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00
[    8.002597] [drm] radeon_dp_set_rx_power_state, ffff8802a1878c00, 17
[    8.002598] [drm] dig_connector ffff8802a335fd60
[    8.002599] [drm] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00
[    8.010706] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery tried 5 times
[    8.010707] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed
[    8.410554] Console: switching to colour frame buffer device 240x67
[    8.419076] radeon 0000:00:01.0: fb0: radeondrmfb frame buffer device
[    8.419080] radeon 0000:00:01.0: registered panic notifier
[    8.447905] [drm] Initialized radeon 2.40.0 20080528 for 0000:00:01.0 on minor 0
[   11.172631] [drm] radeon_dp_getdpcd ffff8802a1879c00
[   11.172638] [drm] dig_connector ffff8802a335fd80
[   11.172642] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   11.201610] [drm] radeon_dp_getdpcd ffff8802a1879c00
[   11.201617] [drm] dig_connector ffff8802a335fd80
[   11.201621] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   11.261417] [drm] radeon_dp_getdpcd ffff8802a1879c00
[   11.261423] [drm] dig_connector ffff8802a335fd80
[   11.261427] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[   11.289599] [drm] radeon_dp_getdpcd ffff8802a1879c00
[   11.289611] [drm] dig_connector ffff8802a335fd80
[   11.289616] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00

Created attachment 115786 [details] [review]
more debugging

Does this patch help?  Please include all the radeon related output.  The pointers are fine.  The problem seems to be that the panel returns all 0s for the dpcd unless the panel is in D0 state.

(In reply to Alex Deucher from comment #99)
> Created attachment 115786 [details] [review] [review]
> more debugging
> 
> Does this patch help?  Please include all the radeon related output.  The
> pointers are fine.  The problem seems to be that the panel returns all 0s
> for the dpcd unless the panel is in D0 state.

Same black screen as always:

[    2.416663] [drm] Initialized drm 1.1.0 20060810
[    2.445991] [drm] radeon kernel modesetting enabled.
[    2.446059] checking generic (d0000000 7e9000) vs hw (d0000000 10000000)
[    2.446063] fb: switching to radeondrmfb from simple
[    2.446114] Console: switching to colour dummy device 80x25
[    2.447424] [drm] initializing kernel modesetting (ARUBA 0x1002:0x9908 0x1043:0x1557).
[    2.447455] [drm] register mmio base: 0xFEB00000
[    2.447457] [drm] register mmio size: 262144
[    2.447466] [drm] ACPI VFCT contains a BIOS for 00:01.0 1002:9908, size 19968
[    2.447484] ATOM BIOS: 113
[    2.447562] radeon 0000:00:01.0: VRAM: 768M 0x0000000000000000 - 0x000000002FFFFFFF (768M used)
[    2.447567] radeon 0000:00:01.0: GTT: 1024M 0x0000000030000000 - 0x000000006FFFFFFF
[    2.447570] [drm] Detected VRAM RAM=768M, BAR=256M
[    2.447573] [drm] RAM width 64bits DDR
[    2.459264] [TTM] Zone  kernel: Available graphics memory: 4705032 kiB
[    2.459270] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[    2.459273] [TTM] Initializing pool allocator
[    2.459286] [TTM] Initializing DMA pool allocator
[    2.459329] [drm] radeon: 768M of VRAM memory ready
[    2.459332] [drm] radeon: 1024M of GTT memory ready.
[    2.459403] [drm] Loading ARUBA Microcode
[    2.466436] [drm] Internal thermal controller without fan control
[    2.466803] [drm] radeon: dpm initialized
[    2.469003] [drm] GART: num cpu pages 262144, num gpu pages 262144
[    2.525191] [drm] PCIE GART of 1024M enabled (table at 0x0000000000277000).
[    2.568824] radeon 0000:00:01.0: WB enabled
[    2.568836] radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000030000c00 and cpu addr 0xffff88009cbe9c00
[    2.569585] radeon 0000:00:01.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 and cpu addr 0xffffc90002c35a18
[    2.569591] radeon 0000:00:01.0: fence driver on ring 1 use gpu addr 0x0000000030000c04 and cpu addr 0xffff88009cbe9c04
[    2.569596] radeon 0000:00:01.0: fence driver on ring 2 use gpu addr 0x0000000030000c08 and cpu addr 0xffff88009cbe9c08
[    2.569601] radeon 0000:00:01.0: fence driver on ring 3 use gpu addr 0x0000000030000c0c and cpu addr 0xffff88009cbe9c0c
[    2.569605] radeon 0000:00:01.0: fence driver on ring 4 use gpu addr 0x0000000030000c10 and cpu addr 0xffff88009cbe9c10
[    2.569610] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    2.569612] [drm] Driver supports precise vblank timestamp query.
[    2.569616] radeon 0000:00:01.0: radeon: MSI limited to 32-bit
[    2.569735] radeon 0000:00:01.0: radeon: using MSI.
[    2.570051] [drm] radeon: irq initialized.
[    2.595233] Switched to clocksource tsc
[    2.767602] [drm] ring test on 0 succeeded in 1 usecs
[    2.767615] [drm] ring test on 3 succeeded in 3 usecs
[    2.767623] [drm] ring test on 4 succeeded in 3 usecs
[    3.146504] [drm] ring test on 5 succeeded in 1 usecs
[    3.235365] [drm] UVD initialized successfully.
[    3.311403] [drm] ib test on ring 0 succeeded in 0 usecs
[    3.311971] [drm] ib test on ring 3 succeeded in 0 usecs
[    3.312510] [drm] ib test on ring 4 succeeded in 0 usecs
[    3.418476] [drm] ib test on ring 5 succeeded
[    3.453894] [drm] radeon atom DIG backlight initialized
[    3.453901] [drm] Radeon Display Connectors
[    3.453906] [drm] Connector 0 ffff88009c82f000 0x00000002:
[    3.453911] [drm]   eDP-1
[    3.453914] [drm]   HPD1
[    3.453921] [drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c
[    3.453923] [drm]   Encoders:
[    3.453926] [drm]   encoder: ffff8802a1d28400, 0x00000002
[    3.453928] [drm]     LCD1: INTERNAL_UNIPHY2
[    3.453931] [drm]   encoder: ffff8802a1d29400, 0x00000001
[    3.453934] [drm]   encoder: ffff8802a1d28600, 0x00000001
[    3.453936] [drm]   encoder: ffff8802a1d29c00, 0x00000008
[    3.453940] [drm] Connector 1 ffff88009c82a000 0x00000001:
[    3.453943] [drm]   VGA-1
[    3.453947] [drm]   HPD2
[    3.453951] [drm]   DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 0x654c
[    3.453952] [drm]   Encoders:
[    3.453954] [drm]   encoder: ffff8802a1d28400, 0x00000002
[    3.453958] [drm]   encoder: ffff8802a1d29400, 0x00000001
[    3.453961] [drm]     CRT1: INTERNAL_UNIPHY2
[    3.453964] [drm]   encoder: ffff8802a1d28600, 0x00000001
[    3.453968] [drm]     CRT1: NUTMEG
[    3.453973] [drm]   encoder: ffff8802a1d29c00, 0x00000008
[    3.453975] [drm] Connector 2 ffff88009c82d000 0x00000008:
[    3.453977] [drm]   HDMI-A-1
[    3.453979] [drm]   HPD3
[    3.453982] [drm]   DDC: 0x6550 0x6550 0x6554 0x6554 0x6558 0x6558 0x655c 0x655c
[    3.453985] [drm]   Encoders:
[    3.453988] [drm]   encoder: ffff8802a1d28400, 0x00000002
[    3.453992] [drm]   encoder: ffff8802a1d29400, 0x00000001
[    3.453996] [drm]   encoder: ffff8802a1d28600, 0x00000001
[    3.454000] [drm]   encoder: ffff8802a1d29c00, 0x00000008
[    3.454003] [drm]     DFP1: INTERNAL_UNIPHY
[    3.501015] [drm] radeon_dp_set_rx_power_state, ffff88009c82f000, 0
[    3.501021] [drm] dig_connector ffff8802a21885e0
[    3.501024] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    3.501027] [drm] check edp dpcd ffff88009c82f000
[    3.501030] [drm] radeon_dp_set_rx_power_state, ffff88009c82f000, 0
[    3.501032] [drm] dig_connector ffff8802a21885e0
[    3.501034] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    3.501727] [drm] radeon_dp_set_rx_power_state, ffff88009c82f000, 0
[    3.501734] [drm] dig_connector ffff8802a21885e0
[    3.501737] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    4.633890] [drm] radeon_dp_set_rx_power_state, ffff88009c82f000, 0
[    4.633896] [drm] dig_connector ffff8802a21885e0
[    4.633899] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    4.634106] [drm] radeon_dp_set_rx_power_state, ffff88009c82f000, 0
[    4.634113] [drm] dig_connector ffff8802a21885e0
[    4.634116] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    4.634155] [drm] radeon_dp_set_rx_power_state, ffff88009c82a000, 0
[    4.634158] [drm] dig_connector ffff8802a2188600
[    4.634160] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    4.634695] [drm] radeon_dp_getdpcd ffff88009c82a000
[    4.634700] [drm] dig_connector ffff8802a2188600
[    4.634703] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    4.673145] [drm] fb mappable at 0xD047B000
[    4.673151] [drm] vram apper at 0xD0000000
[    4.673154] [drm] size 8294400
[    4.673157] [drm] fb depth is 24
[    4.673160] [drm]    pitch is 7680
[    4.673341] fbcon: radeondrmfb (fb0) is primary device
[    4.673476] [drm] radeon_dp_set_link_config, ffff88009c82f000, 540000, 1
[    4.673478] [drm] dig_connector ffff8802a21885e0
[    4.673479] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    5.769542] [drm] radeon_dp_set_rx_power_state, ffff88009c82f000, 0
[    5.769544] [drm] dig_connector ffff8802a21885e0
[    5.769545] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    5.784267] [drm] radeon_dp_set_rx_power_state, ffff88009c82f000, 0
[    5.784269] [drm] dig_connector ffff8802a21885e0
[    5.784270] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    5.784278] [drm] radeon_dp_set_rx_power_state, ffff88009c82f000, 0
[    5.784279] [drm] dig_connector ffff8802a21885e0
[    5.784280] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    6.917194] [drm] radeon_dp_set_rx_power_state, ffff88009c82f000, 0
[    6.917195] [drm] dig_connector ffff8802a21885e0
[    6.917195] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    6.918893] [drm] radeon_dp_link_train, ffff88009c82f000
[    6.918895] [drm] dig_connector ffff8802a21885e0
[    6.918896] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    6.918897] [drm] dp_info dpcd: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    6.918899] [drm] radeon_dp_set_rx_power_state, ffff88009c82f000, 0
[    6.918900] [drm] dig_connector ffff8802a21885e0
[    6.918901] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    6.925016] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery tried 5 times
[    6.925057] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
[    7.030213] Console: switching to colour frame buffer device 240x67
[    7.038704] radeon 0000:00:01.0: fb0: radeondrmfb frame buffer device
[    7.038708] radeon 0000:00:01.0: registered panic notifier
[    7.044578] [drm] Initialized radeon 2.42.0 20080528 for 0000:00:01.0 on minor 0
[    9.554826] [drm] check edp dpcd ffff88009c82f000
[    9.554833] [drm] radeon_dp_set_rx_power_state, ffff88009c82f000, 0
[    9.554836] [drm] dig_connector ffff8802a21885e0
[    9.554839] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    9.562857] [drm] radeon_dp_set_rx_power_state, ffff88009c82a000, 17
[    9.562865] [drm] dig_connector ffff8802a2188600
[    9.562871] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    9.565030] [drm] radeon_dp_getdpcd ffff88009c82a000
[    9.565037] [drm] dig_connector ffff8802a2188600
[    9.565041] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    9.597408] [drm] radeon_dp_set_rx_power_state, ffff88009c82a000, 17
[    9.597416] [drm] dig_connector ffff8802a2188600
[    9.597421] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    9.600040] [drm] radeon_dp_getdpcd ffff88009c82a000
[    9.600048] [drm] dig_connector ffff8802a2188600
[    9.600051] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    9.636116] [drm] check edp dpcd ffff88009c82f000
[    9.636125] [drm] radeon_dp_set_rx_power_state, ffff88009c82f000, 0
[    9.636129] [drm] dig_connector ffff8802a21885e0
[    9.636133] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    9.645244] [drm] radeon_dp_set_rx_power_state, ffff88009c82a000, 17
[    9.645252] [drm] dig_connector ffff8802a2188600
[    9.645256] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    9.648055] [drm] radeon_dp_getdpcd ffff88009c82a000
[    9.648062] [drm] dig_connector ffff8802a2188600
[    9.648065] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    9.681512] [drm] radeon_dp_set_rx_power_state, ffff88009c82a000, 17
[    9.681520] [drm] dig_connector ffff8802a2188600
[    9.681525] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    9.683934] [drm] radeon_dp_getdpcd ffff88009c82a000
[    9.683941] [drm] dig_connector ffff8802a2188600
[    9.683945] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00

Created attachment 115801 [details] [review]
leave panel power on all th time

(In reply to Nicolas Werner from comment #98)
> [    5.722365] [drm:radeon_dp_set_link_config] *ERROR* corrupt dpcd, updating
> [    5.722952] [drm] radeon_dp_set_link_config, ffff8802a1878c00, 540000, 1
> [    5.722953] [drm] dig_connector ffff8802a335fd60
> [    5.722954] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [    6.865341] [drm:radeon_dp_set_rx_power_state] *ERROR* corrupt dpcd,
> updating
> [    6.865932] [drm] radeon_dp_set_rx_power_state, ffff8802a1878c00, 0
> [    6.865933] [drm] dig_connector ffff8802a335fd60
> [    6.865934] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [    8.001613] [drm:radeon_dp_link_train] *ERROR* corrupt dpcd, updating
> [    8.002284] [drm] radeon_dp_link_train, ffff8802a1878c00
> [    8.002285] [drm] dig_connector ffff8802a335fd60
> [    8.002287] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [    8.002287] [drm] dp_info dpcd: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00

For some reason the DPCD reads back unreliably.  It's all zeros the first few times.


> [    8.002289] [drm:radeon_dp_set_rx_power_state] *ERROR* corrupt dpcd,
> updating
> [    8.002594] [drm] radeon_dp_getdpcd ffff8802a1878c00
> [    8.002595] [drm] dig_connector ffff8802a335fd60
> [    8.002595] [drm] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00

Finally it reads back correctly, but at this point it's too late.


> [    8.002597] [drm] radeon_dp_set_rx_power_state, ffff8802a1878c00, 17
> [    8.002598] [drm] dig_connector ffff8802a335fd60
> [    8.002599] [drm] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00
> [    8.010706] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery tried 5
> times
> [    8.010707] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed

Does this patch help the reliability any?

Created attachment 115802 [details] [review]
retry dpcd fetch

Does this patch help?

(In reply to Alex Deucher from comment #101)
> Created attachment 115801 [details] [review] [review]
> leave panel power on all th time
> 
> (In reply to Nicolas Werner from comment #98)

> Does this patch help the reliability any?

Nope, doesn't seem to help:

[    2.417913] [drm] Initialized drm 1.1.0 20060810
[    2.452619] [drm] radeon kernel modesetting enabled.
[    2.452686] checking generic (d0000000 7e9000) vs hw (d0000000 10000000)
[    2.452690] fb: switching to radeondrmfb from simple
[    2.452741] Console: switching to colour dummy device 80x25
[    2.454825] [drm] initializing kernel modesetting (ARUBA 0x1002:0x9908 0x1043:0x1557).
[    2.454870] [drm] register mmio base: 0xFEB00000
[    2.454876] [drm] register mmio size: 262144
[    2.454890] [drm] ACPI VFCT contains a BIOS for 00:01.0 1002:9908, size 19968
[    2.454917] ATOM BIOS: 113
[    2.455014] radeon 0000:00:01.0: VRAM: 768M 0x0000000000000000 - 0x000000002FFFFFFF (768M used)
[    2.455024] radeon 0000:00:01.0: GTT: 1024M 0x0000000030000000 - 0x000000006FFFFFFF
[    2.455029] [drm] Detected VRAM RAM=768M, BAR=256M
[    2.455035] [drm] RAM width 64bits DDR
[    2.465783] [TTM] Zone  kernel: Available graphics memory: 4705032 kiB
[    2.465789] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[    2.465792] [TTM] Initializing pool allocator
[    2.465803] [TTM] Initializing DMA pool allocator
[    2.465844] [drm] radeon: 768M of VRAM memory ready
[    2.465846] [drm] radeon: 1024M of GTT memory ready.
[    2.465872] [drm] Loading ARUBA Microcode
[    2.470982] [drm] Internal thermal controller without fan control
[    2.471276] [drm] radeon: dpm initialized
[    2.472681] [drm] GART: num cpu pages 262144, num gpu pages 262144
[    2.547652] [drm] PCIE GART of 1024M enabled (table at 0x0000000000277000).
[    2.547837] radeon 0000:00:01.0: WB enabled
[    2.547844] radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000030000c00 and cpu addr 0xffff88029febbc00
[    2.548657] radeon 0000:00:01.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 and cpu addr 0xffffc90002c35a18
[    2.548663] radeon 0000:00:01.0: fence driver on ring 1 use gpu addr 0x0000000030000c04 and cpu addr 0xffff88029febbc04
[    2.548668] radeon 0000:00:01.0: fence driver on ring 2 use gpu addr 0x0000000030000c08 and cpu addr 0xffff88029febbc08
[    2.548673] radeon 0000:00:01.0: fence driver on ring 3 use gpu addr 0x0000000030000c0c and cpu addr 0xffff88029febbc0c
[    2.548678] radeon 0000:00:01.0: fence driver on ring 4 use gpu addr 0x0000000030000c10 and cpu addr 0xffff88029febbc10
[    2.562343] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    2.562349] [drm] Driver supports precise vblank timestamp query.
[    2.562358] radeon 0000:00:01.0: radeon: MSI limited to 32-bit
[    2.562408] radeon 0000:00:01.0: radeon: using MSI.
[    2.562722] [drm] radeon: irq initialized.
[    2.582824] Switched to clocksource tsc
[    2.783234] [drm] ring test on 0 succeeded in 2 usecs
[    2.783248] [drm] ring test on 3 succeeded in 3 usecs
[    2.783257] [drm] ring test on 4 succeeded in 3 usecs
[    3.099491] [drm] ring test on 5 succeeded in 1 usecs
[    3.150022] [drm] UVD initialized successfully.
[    3.212760] [drm] ib test on ring 0 succeeded in 0 usecs
[    3.213313] [drm] ib test on ring 3 succeeded in 0 usecs
[    3.213866] [drm] ib test on ring 4 succeeded in 0 usecs
[    3.333633] [drm] ib test on ring 5 succeeded
[    3.361224] [drm] radeon atom DIG backlight initialized
[    3.361230] [drm] Radeon Display Connectors
[    3.361234] [drm] Connector 0 ffff8802a2b9b000 0x00000002:
[    3.361236] [drm]   eDP-1
[    3.361239] [drm]   HPD1
[    3.361242] [drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c
[    3.361244] [drm]   Encoders:
[    3.361246] [drm]   encoder: ffff88009d373c00, 0x00000002
[    3.361248] [drm]     LCD1: INTERNAL_UNIPHY2
[    3.361250] [drm]   encoder: ffff88009d373400, 0x00000001
[    3.361252] [drm]   encoder: ffff88009d373000, 0x00000001
[    3.361254] [drm]   encoder: ffff88009d372a00, 0x00000008
[    3.361256] [drm] Connector 1 ffff8802a2b9a000 0x00000001:
[    3.361258] [drm]   VGA-1
[    3.361259] [drm]   HPD2
[    3.361261] [drm]   DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 0x654c
[    3.361263] [drm]   Encoders:
[    3.361265] [drm]   encoder: ffff88009d373c00, 0x00000002
[    3.361266] [drm]   encoder: ffff88009d373400, 0x00000001
[    3.361268] [drm]     CRT1: INTERNAL_UNIPHY2
[    3.361270] [drm]   encoder: ffff88009d373000, 0x00000001
[    3.361271] [drm]     CRT1: NUTMEG
[    3.361273] [drm]   encoder: ffff88009d372a00, 0x00000008
[    3.361275] [drm] Connector 2 ffff8802a2b98000 0x00000008:
[    3.361276] [drm]   HDMI-A-1
[    3.361278] [drm]   HPD3
[    3.361280] [drm]   DDC: 0x6550 0x6550 0x6554 0x6554 0x6558 0x6558 0x655c 0x655c
[    3.361282] [drm]   Encoders:
[    3.361283] [drm]   encoder: ffff88009d373c00, 0x00000002
[    3.361285] [drm]   encoder: ffff88009d373400, 0x00000001
[    3.361287] [drm]   encoder: ffff88009d373000, 0x00000001
[    3.361289] [drm]   encoder: ffff88009d372a00, 0x00000008
[    3.361290] [drm]     DFP1: INTERNAL_UNIPHY
[    3.409302] [drm] check edp dpcd ffff8802a2b9b000
[    3.409309] [drm] radeon_dp_set_rx_power_state, ffff8802a2b9b000, 0
[    3.409313] [drm] dig_connector ffff8802a32e3d80
[    3.409316] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    3.417441] [drm] radeon_dp_set_rx_power_state, ffff8802a2b9a000, 0
[    3.417447] [drm] dig_connector ffff8802a32e3da0
[    3.417449] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    3.417881] [drm] radeon_dp_getdpcd ffff8802a2b9a000
[    3.417884] [drm] dig_connector ffff8802a32e3da0
[    3.417886] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    3.454360] [drm] fb mappable at 0xD047B000
[    3.454369] [drm] vram apper at 0xD0000000
[    3.454374] [drm] size 8294400
[    3.454376] [drm] fb depth is 24
[    3.454382] [drm]    pitch is 7680
[    3.454540] fbcon: radeondrmfb (fb0) is primary device
[    3.454664] [drm] radeon_dp_set_link_config, ffff8802a2b9b000, 540000, 1
[    3.454665] [drm] dig_connector ffff8802a32e3d80
[    3.454666] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    3.469463] [drm] radeon_dp_set_rx_power_state, ffff8802a2b9b000, 0
[    3.469465] [drm] dig_connector ffff8802a32e3d80
[    3.469467] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    3.488610] [drm] radeon_dp_link_train, ffff8802a2b9b000
[    3.488612] [drm] dig_connector ffff8802a32e3d80
[    3.488613] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    3.488614] [drm] dp_info dpcd: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    3.488616] [drm] radeon_dp_set_rx_power_state, ffff8802a2b9b000, 0
[    3.488617] [drm] dig_connector ffff8802a32e3d80
[    3.488618] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    3.494579] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery tried 5 times
[    3.494620] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
[    3.600279] Console: switching to colour frame buffer device 240x67
[    3.608796] radeon 0000:00:01.0: fb0: radeondrmfb frame buffer device
[    3.608800] radeon 0000:00:01.0: registered panic notifier
[    3.614400] [drm] Initialized radeon 2.42.0 20080528 for 0000:00:01.0 on minor 0
[    6.016650] [drm] check edp dpcd ffff8802a2b9b000
[    6.016658] [drm] radeon_dp_set_rx_power_state, ffff8802a2b9b000, 0
[    6.016661] [drm] dig_connector ffff8802a32e3d80
[    6.016664] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    6.025160] [drm] radeon_dp_set_rx_power_state, ffff8802a2b9a000, 17
[    6.025167] [drm] dig_connector ffff8802a32e3da0
[    6.025170] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    6.027840] [drm] radeon_dp_getdpcd ffff8802a2b9a000
[    6.027848] [drm] dig_connector ffff8802a32e3da0
[    6.027853] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    6.059605] [drm] radeon_dp_set_rx_power_state, ffff8802a2b9a000, 17
[    6.059613] [drm] dig_connector ffff8802a32e3da0
[    6.059616] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    6.061971] [drm] radeon_dp_getdpcd ffff8802a2b9a000
[    6.061982] [drm] dig_connector ffff8802a32e3da0
[    6.061991] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    6.103173] [drm] check edp dpcd ffff8802a2b9b000
[    6.103183] [drm] radeon_dp_set_rx_power_state, ffff8802a2b9b000, 0
[    6.103187] [drm] dig_connector ffff8802a32e3d80
[    6.103191] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    6.112207] [drm] radeon_dp_set_rx_power_state, ffff8802a2b9a000, 17
[    6.112213] [drm] dig_connector ffff8802a32e3da0
[    6.112217] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    6.114811] [drm] radeon_dp_getdpcd ffff8802a2b9a000
[    6.114818] [drm] dig_connector ffff8802a32e3da0
[    6.114821] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    6.147536] [drm] radeon_dp_set_rx_power_state, ffff8802a2b9a000, 17
[    6.147544] [drm] dig_connector ffff8802a32e3da0
[    6.147548] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
[    6.149883] [drm] radeon_dp_getdpcd ffff8802a2b9a000
[    6.149889] [drm] dig_connector ffff8802a32e3da0
[    6.149892] [drm] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00

(In reply to Alex Deucher from comment #102)
> Created attachment 115802 [details] [review] [review]
> retry dpcd fetch
> 
> Does this patch help?

Yep, this one works!

[    2.869482] [drm] Initialized drm 1.1.0 20060810
[    2.905939] [drm] radeon kernel modesetting enabled.
[    2.906034] checking generic (d0000000 7e9000) vs hw (d0000000 10000000)
[    2.906040] fb: switching to radeondrmfb from simple
[    2.906110] Console: switching to colour dummy device 80x25
[    2.906893] [drm] initializing kernel modesetting (ARUBA 0x1002:0x9908 0x1043:0x1557).
[    2.906919] [drm] register mmio base: 0xFEB00000
[    2.906922] [drm] register mmio size: 262144
[    2.906930] [drm] ACPI VFCT contains a BIOS for 00:01.0 1002:9908, size 19968
[    2.906948] ATOM BIOS: 113
[    2.907058] radeon 0000:00:01.0: VRAM: 768M 0x0000000000000000 - 0x000000002FFFFFFF (768M used)
[    2.907063] radeon 0000:00:01.0: GTT: 1024M 0x0000000030000000 - 0x000000006FFFFFFF
[    2.907066] [drm] Detected VRAM RAM=768M, BAR=256M
[    2.907069] [drm] RAM width 64bits DDR
[    2.915861] [TTM] Zone  kernel: Available graphics memory: 4705032 kiB
[    2.915866] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[    2.915869] [TTM] Initializing pool allocator
[    2.915880] [TTM] Initializing DMA pool allocator
[    2.915923] [drm] radeon: 768M of VRAM memory ready
[    2.915926] [drm] radeon: 1024M of GTT memory ready.
[    2.915953] [drm] Loading ARUBA Microcode
[    2.920123] [drm] Internal thermal controller without fan control
[    2.920478] [drm] radeon: dpm initialized
[    2.921876] [drm] GART: num cpu pages 262144, num gpu pages 262144
[    3.016174] [drm] PCIE GART of 1024M enabled (table at 0x0000000000277000).
[    3.016352] radeon 0000:00:01.0: WB enabled
[    3.016359] radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000030000c00 and cpu addr 0xffff88029f86dc00
[    3.017100] radeon 0000:00:01.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 and cpu addr 0xffffc90002c35a18
[    3.017106] radeon 0000:00:01.0: fence driver on ring 1 use gpu addr 0x0000000030000c04 and cpu addr 0xffff88029f86dc04
[    3.017111] radeon 0000:00:01.0: fence driver on ring 2 use gpu addr 0x0000000030000c08 and cpu addr 0xffff88029f86dc08
[    3.017115] radeon 0000:00:01.0: fence driver on ring 3 use gpu addr 0x0000000030000c0c and cpu addr 0xffff88029f86dc0c
[    3.017120] radeon 0000:00:01.0: fence driver on ring 4 use gpu addr 0x0000000030000c10 and cpu addr 0xffff88029f86dc10
[    3.050531] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    3.050538] [drm] Driver supports precise vblank timestamp query.
[    3.050547] radeon 0000:00:01.0: radeon: MSI limited to 32-bit
[    3.050601] radeon 0000:00:01.0: radeon: using MSI.
[    3.050885] [drm] radeon: irq initialized.
[    3.250486] [drm] ring test on 0 succeeded in 2 usecs
[    3.250499] [drm] ring test on 3 succeeded in 3 usecs
[    3.250508] [drm] ring test on 4 succeeded in 3 usecs
[    3.666123] [drm] ring test on 5 succeeded in 1 usecs
[    3.724948] [drm] UVD initialized successfully.
[    3.761377] [drm] ib test on ring 0 succeeded in 0 usecs
[    3.761920] [drm] ib test on ring 3 succeeded in 0 usecs
[    3.762479] [drm] ib test on ring 4 succeeded in 0 usecs
[    3.788319] [drm] ib test on ring 5 succeeded
[    3.813353] [drm] radeon atom DIG backlight initialized
[    3.813359] [drm] Radeon Display Connectors
[    3.813362] [drm] Connector 0:
[    3.813364] [drm]   eDP-1
[    3.813367] [drm]   HPD1
[    3.813370] [drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c
[    3.813372] [drm]   Encoders:
[    3.813374] [drm]     LCD1: INTERNAL_UNIPHY2
[    3.813376] [drm] Connector 1:
[    3.813378] [drm]   VGA-1
[    3.813379] [drm]   HPD2
[    3.813382] [drm]   DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 0x654c
[    3.813383] [drm]   Encoders:
[    3.813385] [drm]     CRT1: INTERNAL_UNIPHY2
[    3.813386] [drm]     CRT1: NUTMEG
[    3.813388] [drm] Connector 2:
[    3.813389] [drm]   HDMI-A-1
[    3.813391] [drm]   HPD3
[    3.813393] [drm]   DDC: 0x6550 0x6550 0x6554 0x6554 0x6558 0x6558 0x655c 0x655c
[    3.813394] [drm]   Encoders:
[    3.813396] [drm]     DFP1: INTERNAL_UNIPHY
[    5.032372] [drm] fb mappable at 0xD047B000
[    5.032378] [drm] vram apper at 0xD0000000
[    5.032382] [drm] size 8294400
[    5.032385] [drm] fb depth is 24
[    5.032387] [drm]    pitch is 7680
[    5.032677] fbcon: radeondrmfb (fb0) is primary device
[    7.394835] Console: switching to colour frame buffer device 240x67
[    7.403334] radeon 0000:00:01.0: fb0: radeondrmfb frame buffer device
[    7.403338] radeon 0000:00:01.0: registered panic notifier
[    7.409476] [drm] Initialized radeon 2.42.0 20080528 for 0000:00:01.0 on minor 0

Created attachment 115837 [details]
dmesg with debug patches from comments 88, 93, 95 & 97 applied

(In reply to Alex Deucher from comment #97)
> Created attachment 115782 [details] [review] [review]
> more debugging
> 
> Can you attach your dmesg output with the attached patch?  Please include
> all the radeon related output.

Here is dmesg with 88, 93, 95 & 97 applied, it looks strange as non-zero DPCD values are reported from beginning and they never change. Note that EFI firmware does 'train' this eDP panel properly, as native resolution is set from early boot, EFIfb console keeps the same resolution. I can even tell X to force using fbdev driver, the resolution stays the same, resulting in zero flicker and working display all the way from early boot to GUI login.

Created attachment 115838 [details]
dmesg with debug patches from comments 88, 93, 95, 97 & 99 applied, without set_rx_power_state

(In reply to Alex Deucher from comment #99)
> Created attachment 115786 [details] [review] [review]
> more debugging
> 
> Does this patch help?  Please include all the radeon related output.  The
> pointers are fine.  The problem seems to be that the panel returns all 0s
> for the dpcd unless the panel is in D0 state.

When I tried applying this patch, my laptop freeze (network gets unresponsive). It worked only when *radeon_dp_set_rx_power_state(&radeon_connector->base, DP_SET_POWER_D0);* was commented out in radeon_dp_getdpcd().

Patches from #101 & #102 also didnt help.

(In reply to Samir Ibradžić from comment #105)
> Here is dmesg with 88, 93, 95 & 97 applied, it looks strange as non-zero
> DPCD values are reported from beginning and they never change. 

I don't think you are experiencing the same issue.  Let's continue debugging your issue on bug 90320.

(In reply to Alex Deucher from comment #102)
> Created attachment 115802 [details] [review] [review]
> retry dpcd fetch
> 
> Does this patch help?

It didn't work for me, trying some other changes for now.

(In reply to N.Leiten from comment #108)
> (In reply to Alex Deucher from comment #102)
> > Created attachment 115802 [details] [review] [review] [review]
> > retry dpcd fetch
> > 
> > Does this patch help?
> 
> It didn't work for me, trying some other changes for now.

Please attach your dmesg output with attachment 115782 [details] [review] and attachment 115778 [details] [review] applied.

Created attachment 117134 [details]
more debug output with successful and unsuccessful link training

I applied both debug output patches. (the second one doesn’t apply cleanly anymore)
An external monitor is connected via the mini vga port so i can still do something. 
Directly after startup i have a blackscreen on the internal display but the external display shows the tty. 
After login i start X with gnome. Within gnome I switch between display modes (mirror, switch which is primary display) and it eventually works.

At this point I see that problem was fixed with linux kernel 4.2.0-rc4.

(In reply to N.Leiten from comment #111)
> At this point I see that problem was fixed with linux kernel 4.2.0-rc4.

Thank you for checking this!

Could somebody please reference the corresponding commits, so it can be checked, if they are marked to go into the stable Linux kernels?

(In reply to Paul Menzel from comment #112)
> Could somebody please reference the corresponding commits, so it can be
> checked, if they are marked to go into the stable Linux kernels?

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0f28d1281b6c54cc98746ae61e44e7f540758ed4

Actually, for me on Arch it works with 4.1.4, too. I tried 4.2 RC5 as well and that works too. That's great!

(In reply to Christian Aßfalg from comment #114)
> Actually, for me on Arch it works with 4.1.4, too. I tried 4.2 RC5 as well
> and that works too. That's great!

Yeah, I’m really happy I can finally work with the open source driver too. 

(In reply to Alex Deucher from comment #113)
> (In reply to Paul Menzel from comment #112)
> > Could somebody please reference the corresponding commits, so it can be
> > checked, if they are marked to go into the stable Linux kernels?
> 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> ?id=0f28d1281b6c54cc98746ae61e44e7f540758ed4

I don’t think that’s it because I tried that with earlier kernel versions (I also hardcoded the dpcd in several places and that didn’t work). 
I suspected it had to do with the ›dp_aux_ch timeout‹ and interrupts occurring around the time of link training. 

As I took a significant amount of time digging through the code I would like to get convinced about which commit fixed this.

(In reply to Norbert Pfeiler from comment #115)
> I don’t think that’s it because I tried that with earlier kernel versions (I
> also hardcoded the dpcd in several places and that didn’t work). 
> I suspected it had to do with the ›dp_aux_ch timeout‹ and interrupts
> occurring around the time of link training. 
> 
> As I took a significant amount of time digging through the code I would like
> to get convinced about which commit fixed this.

You can use git to bisect what fixed it (just reverse the good/bad flagging).