Bug 73530 - Asus U38N: Black screen with Radeon driver in Linux
Summary: Asus U38N: Black screen with Radeon driver in Linux
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg git
Hardware: Other All
: medium major
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
: 73529 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-01-13 00:01 UTC by Paul Menzel
Modified: 2015-08-12 13:17 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Linux kernel ring buffer (`dmesg`) (55.13 KB, text/plain)
2014-01-13 00:08 UTC, Paul Menzel
no flags Details
X server log file (43.57 KB, text/plain)
2014-01-13 00:09 UTC, Paul Menzel
no flags Details
disable ss (787 bytes, patch)
2014-01-14 15:12 UTC, Alex Deucher
no flags Details | Splinter Review
debugging output (579 bytes, patch)
2014-01-14 15:19 UTC, Alex Deucher
no flags Details | Splinter Review
Linux kernel 3.13-rc8+-disable-ss ring buffer (`dmesg`) (190.19 KB, text/plain)
2014-01-15 09:28 UTC, Paul Menzel
no flags Details
X server log file with Linux 3.13-rc8-disable-ss (44.69 KB, text/plain)
2014-01-15 09:31 UTC, Paul Menzel
no flags Details
patch 1/2 (3.82 KB, patch)
2014-01-15 19:05 UTC, Alex Deucher
no flags Details | Splinter Review
patch 2/2 (3.00 KB, patch)
2014-01-15 19:06 UTC, Alex Deucher
no flags Details | Splinter Review
possible fix (1.10 KB, patch)
2014-01-16 15:01 UTC, Alex Deucher
no flags Details | Splinter Review
Picture of a wrong timing(?) (1.59 MB, image/jpeg)
2014-01-17 08:35 UTC, Paul Menzel
no flags Details
Picture of another wrong timing(?) (1.95 MB, image/jpeg)
2014-01-17 08:38 UTC, Paul Menzel
no flags Details
`/var/log/kern.log` from 3.13 with debug and delay patch (2.23 MB, text/plain)
2014-01-30 08:54 UTC, Paul Menzel
no flags Details
Linux kernel log 3.13 with patch from previous comment (200 μs) (50.00 KB, text/plain)
2014-02-01 12:00 UTC, Paul Menzel
no flags Details
Linux kernel log 3.13 with patch from previous comment (200 μs) after xrandr --off/--auto cycle (26.17 KB, text/plain)
2014-02-01 12:02 UTC, Paul Menzel
no flags Details
dmesg with drm/radeon: add locking around atombios scratch space usage (4.43 KB, text/plain)
2014-11-17 19:03 UTC, Nicolas Werner
no flags Details
dmesg drm debug kernel 3.18 (228.05 KB, text/plain)
2015-05-08 00:01 UTC, Nicolas Werner
no flags Details
Panel datasheet (1.29 MB, application/pdf)
2015-05-08 07:36 UTC, N.Leiten
no flags Details
possible fix (5.79 KB, patch)
2015-05-11 17:29 UTC, Alex Deucher
no flags Details | Splinter Review
add some debugging output (2.56 KB, patch)
2015-05-14 13:33 UTC, Alex Deucher
no flags Details | Splinter Review
debuging patch (1.49 KB, patch)
2015-05-14 17:36 UTC, Alex Deucher
no flags Details | Splinter Review
add some debugging output (2.61 KB, patch)
2015-05-14 19:10 UTC, Alex Deucher
no flags Details | Splinter Review
more debugging (3.93 KB, patch)
2015-05-14 20:01 UTC, Alex Deucher
no flags Details | Splinter Review
more debugging (6.07 KB, patch)
2015-05-14 23:50 UTC, Alex Deucher
no flags Details | Splinter Review
leave panel power on all th time (1.33 KB, patch)
2015-05-15 14:16 UTC, Alex Deucher
no flags Details | Splinter Review
retry dpcd fetch (1.16 KB, patch)
2015-05-15 14:28 UTC, Alex Deucher
no flags Details | Splinter Review
dmesg with debug patches from comments 88, 93, 95 & 97 applied (14.28 KB, text/plain)
2015-05-16 15:40 UTC, Samir Ibradžić
no flags Details
dmesg with debug patches from comments 88, 93, 95, 97 & 99 applied, without set_rx_power_state (32.24 KB, text/plain)
2015-05-16 15:48 UTC, Samir Ibradžić
no flags Details
more debug output with successful and unsuccessful link training (2.55 MB, text/plain)
2015-07-15 08:02 UTC, Norbert Pfeiler
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Menzel 2014-01-13 00:01:26 UTC
Copying my message to list dri-devel [1].

As reported in the channel #radeon on <irc.freenode.net>, with the
laptop Asus U38N-C4010H with an AMD Radeon HD 7600G
(Trinity A8-4555M) I am unable to get something displayed on the screen
with modesetting enabled. The backlight of the screen is on, but nothing
is shown on the screen. Booting with `radeon.modeset=0` on the Linux
kernel command line works. I was able to reproduce this problem with
Grml with Linux 3.10 and 3.11 and Debian Sid/unstable with Linux 3.12.6.

Attaching a VGA monitor to the mini VGA connector using an adapter,
nothing was shown on the monitor either.

The following is the output I get when starting with `radeon.modeset=0`
and then doing `sudo modprobe -r radeon` and `sudo modprobe radeon
modeset=1`.

        Jan 11 06:42:24 myhostname kernel: [ 1060.871165] [drm] radeon kernel modesetting enabled.
        Jan 11 06:42:24 myhostname kernel: [ 1060.871244] checking generic (d0000000 1f0000) vs hw (d0000000 10000000)
        Jan 11 06:42:24 myhostname kernel: [ 1060.871247] fb: conflicting fb hw usage radeondrmfb vs EFI VGA - removing generic driver
        Jan 11 06:42:24 myhostname kernel: [ 1060.871322] Console: switching to colour dummy device 80x25
        Jan 11 06:42:24 myhostname kernel: [ 1060.871836] [drm] initializing kernel modesetting (ARUBA 0x1002:0x9908 0x1043:0x1557).
        Jan 11 06:42:24 myhostname kernel: [ 1060.871882] [drm] register mmio base: 0xFEB00000
        Jan 11 06:42:24 myhostname kernel: [ 1060.871884] [drm] register mmio size: 262144
        Jan 11 06:42:24 myhostname kernel: [ 1060.871913] [drm] ACPI VFCT contains a BIOS for 00:01.0 1002:9908, size 19968
        Jan 11 06:42:24 myhostname kernel: [ 1060.871925] ATOM BIOS: 113
        Jan 11 06:42:24 myhostname kernel: [ 1060.871997] radeon 0000:00:01.0: VRAM: 768M 0x0000000000000000 - 0x000000002FFFFFFF (768M used)
        Jan 11 06:42:24 myhostname kernel: [ 1060.872000] radeon 0000:00:01.0: GTT: 1024M 0x0000000030000000 - 0x000000006FFFFFFF
        Jan 11 06:42:24 myhostname kernel: [ 1060.872003] [drm] Detected VRAM RAM=768M, BAR=256M
        Jan 11 06:42:24 myhostname kernel: [ 1060.872005] [drm] RAM width 64bits DDR
        Jan 11 06:42:24 myhostname kernel: [ 1060.872088] [TTM] Zone  kernel: Available graphics memory: 1581256 kiB
        Jan 11 06:42:24 myhostname kernel: [ 1060.872091] [TTM] Initializing pool allocator
        Jan 11 06:42:24 myhostname kernel: [ 1060.872101] [TTM] Initializing DMA pool allocator
        Jan 11 06:42:24 myhostname kernel: [ 1060.872129] [drm] radeon: 768M of VRAM memory ready
        Jan 11 06:42:24 myhostname kernel: [ 1060.872133] [drm] radeon: 1024M of GTT memory ready.
        Jan 11 06:42:24 myhostname kernel: [ 1060.874660] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/TAHITI_uvd.bin
        Jan 11 06:42:24 myhostname kernel: [ 1060.874989] [drm] GART: num cpu pages 262144, num gpu pages 262144
        Jan 11 06:42:24 myhostname kernel: [ 1060.882325] [drm] Loading ARUBA Microcode
        Jan 11 06:42:24 myhostname kernel: [ 1060.882749] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/ARUBA_pfp.bin
        Jan 11 06:42:24 myhostname kernel: [ 1060.883100] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/ARUBA_me.bin
        Jan 11 06:42:24 myhostname kernel: [ 1060.883456] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/ARUBA_rlc.bin
        Jan 11 06:42:24 myhostname kernel: [ 1060.884967] [drm] PCIE GART of 1024M enabled (table at 0x0000000000276000).
        Jan 11 06:42:24 myhostname kernel: [ 1060.885159] radeon 0000:00:01.0: WB enabled
        Jan 11 06:42:24 myhostname kernel: [ 1060.885166] radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000030000c00 and cpu addr 0xffff880129f11c00
        Jan 11 06:42:24 myhostname kernel: [ 1060.885905] radeon 0000:00:01.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 and cpu addr 0xffffc90011db5a18
        Jan 11 06:42:24 myhostname kernel: [ 1060.885910] radeon 0000:00:01.0: fence driver on ring 1 use gpu addr 0x0000000030000c04 and cpu addr 0xffff880129f11c04
        Jan 11 06:42:24 myhostname kernel: [ 1060.885914] radeon 0000:00:01.0: fence driver on ring 2 use gpu addr 0x0000000030000c08 and cpu addr 0xffff880129f11c08
        Jan 11 06:42:24 myhostname kernel: [ 1060.885918] radeon 0000:00:01.0: fence driver on ring 3 use gpu addr 0x0000000030000c0c and cpu addr 0xffff880129f11c0c
        Jan 11 06:42:24 myhostname kernel: [ 1060.885922] radeon 0000:00:01.0: fence driver on ring 4 use gpu addr 0x0000000030000c10 and cpu addr 0xffff880129f11c10
        Jan 11 06:42:24 myhostname kernel: [ 1060.885929] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
        Jan 11 06:42:24 myhostname kernel: [ 1060.885931] [drm] Driver supports precise vblank timestamp query.
        Jan 11 06:42:24 myhostname kernel: [ 1060.885958] radeon 0000:00:01.0: irq 52 for MSI/MSI-X
        Jan 11 06:42:24 myhostname kernel: [ 1060.885982] radeon 0000:00:01.0: radeon: using MSI.
        Jan 11 06:42:24 myhostname kernel: [ 1060.886266] [drm] radeon: irq initialized.
        Jan 11 06:42:24 myhostname kernel: [ 1060.905813] [drm] ring test on 0 succeeded in 2 usecs
        Jan 11 06:42:24 myhostname kernel: [ 1060.905876] [drm] ring test on 3 succeeded in 2 usecs
        Jan 11 06:42:24 myhostname kernel: [ 1060.905885] [drm] ring test on 4 succeeded in 1 usecs
        Jan 11 06:42:24 myhostname kernel: [ 1060.961514] [drm] ring test on 5 succeeded in 1 usecs
        Jan 11 06:42:24 myhostname kernel: [ 1060.981502] [drm] UVD initialized successfully.
        Jan 11 06:42:24 myhostname kernel: [ 1060.985538] [drm] Enabling audio 0 support
        Jan 11 06:42:24 myhostname kernel: [ 1060.985544] [drm] Enabling audio 1 support
        Jan 11 06:42:24 myhostname kernel: [ 1060.985549] [drm] Enabling audio 2 support
        Jan 11 06:42:24 myhostname kernel: [ 1060.985553] [drm] Enabling audio 3 support
        Jan 11 06:42:24 myhostname kernel: [ 1060.985557] [drm] Enabling audio 4 support
        Jan 11 06:42:24 myhostname kernel: [ 1060.985560] [drm] Enabling audio 5 support
        Jan 11 06:42:24 myhostname kernel: [ 1060.986106] [drm] ib test on ring 0 succeeded in 0 usecs
        Jan 11 06:42:24 myhostname kernel: [ 1060.986644] [drm] ib test on ring 3 succeeded in 0 usecs
        Jan 11 06:42:24 myhostname kernel: [ 1060.987175] [drm] ib test on ring 4 succeeded in 1 usecs
        Jan 11 06:42:24 myhostname kernel: [ 1061.007977] [drm] ib test on ring 5 succeeded
        Jan 11 06:42:24 myhostname kernel: [ 1061.032890] [drm] radeon atom DIG backlight initialized
        Jan 11 06:42:24 myhostname kernel: [ 1061.032894] [drm] Radeon Display Connectors
        Jan 11 06:42:24 myhostname kernel: [ 1061.032897] [drm] Connector 0:
        Jan 11 06:42:24 myhostname kernel: [ 1061.032899] [drm]   eDP-1
        Jan 11 06:42:24 myhostname kernel: [ 1061.032901] [drm]   HPD1
        Jan 11 06:42:24 myhostname kernel: [ 1061.032904] [drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c
        Jan 11 06:42:24 myhostname kernel: [ 1061.032906] [drm]   Encoders:
        Jan 11 06:42:24 myhostname kernel: [ 1061.032908] [drm]     LCD1: INTERNAL_UNIPHY2
        Jan 11 06:42:24 myhostname kernel: [ 1061.032909] [drm] Connector 1:
        Jan 11 06:42:24 myhostname kernel: [ 1061.032911] [drm]   VGA-1
        Jan 11 06:42:24 myhostname kernel: [ 1061.032912] [drm]   HPD2
        Jan 11 06:42:24 myhostname kernel: [ 1061.032915] [drm]   DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 0x654c
        Jan 11 06:42:24 myhostname kernel: [ 1061.032916] [drm]   Encoders:
        Jan 11 06:42:24 myhostname kernel: [ 1061.032917] [drm]     CRT1: INTERNAL_UNIPHY2
        Jan 11 06:42:24 myhostname kernel: [ 1061.032919] [drm]     CRT1: NUTMEG
        Jan 11 06:42:24 myhostname kernel: [ 1061.032920] [drm] Connector 2:
        Jan 11 06:42:24 myhostname kernel: [ 1061.032922] [drm]   HDMI-A-1
        Jan 11 06:42:24 myhostname kernel: [ 1061.032923] [drm]   HPD3
        Jan 11 06:42:24 myhostname kernel: [ 1061.032925] [drm]   DDC: 0x6550 0x6550 0x6554 0x6554 0x6558 0x6558 0x655c 0x655c
        Jan 11 06:42:24 myhostname kernel: [ 1061.032926] [drm]   Encoders:
        Jan 11 06:42:24 myhostname kernel: [ 1061.032928] [drm]     DFP1: INTERNAL_UNIPHY
        Jan 11 06:42:25 myhostname kernel: [ 1061.082355] [drm] Internal thermal controller without fan control
        Jan 11 06:42:25 myhostname kernel: [ 1061.082493] [drm] radeon: power management initialized
        Jan 11 06:42:26 myhostname kernel: [ 1062.360915] [drm] fb mappable at 0xD1488000
        Jan 11 06:42:26 myhostname kernel: [ 1062.360922] [drm] vram apper at 0xD0000000
        Jan 11 06:42:26 myhostname kernel: [ 1062.360926] [drm] size 8294400
        Jan 11 06:42:26 myhostname kernel: [ 1062.360928] [drm] fb depth is 24
        Jan 11 06:42:26 myhostname kernel: [ 1062.360931] [drm]    pitch is 7680
        Jan 11 06:42:26 myhostname kernel: [ 1062.361231] fbcon: radeondrmfb (fb0) is primary device
        Jan 11 06:42:28 myhostname kernel: [ 1064.675993] Console: switching to colour frame buffer device 240x67
        Jan 11 06:42:28 myhostname kernel: [ 1064.681973] radeon 0000:00:01.0: fb0: radeondrmfb frame buffer device
        Jan 11 06:42:28 myhostname kernel: [ 1064.681976] radeon 0000:00:01.0: registered panic notifier
        Jan 11 06:42:28 myhostname kernel: [ 1064.682222] [drm] Initialized radeon 2.34.0 20080528 for 0000:00:01.0 on minor 0

The screen turns off shortly (backlight too) and then only the backlight
comes back up.

As requested by Alex [2] I am going to attach the two files.

[1] http://lists.freedesktop.org/archives/dri-devel/2014-January/051737.html
[2] http://lists.freedesktop.org/archives/dri-devel/2014-January/051791.html
Comment 1 Paul Menzel 2014-01-13 00:02:34 UTC
*** Bug 73529 has been marked as a duplicate of this bug. ***
Comment 2 Paul Menzel 2014-01-13 00:08:10 UTC
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`.
Comment 3 Paul Menzel 2014-01-13 00:09:40 UTC
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`.
Comment 4 Alex Deucher 2014-01-14 15:04:00 UTC
(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.
Comment 5 Alex Deucher 2014-01-14 15:11:08 UTC
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.
Comment 6 Alex Deucher 2014-01-14 15:12:45 UTC
Created attachment 92048 [details] [review]
disable ss

Does this kernel patch help?
Comment 7 Alex Deucher 2014-01-14 15:19:43 UTC
Created attachment 92049 [details] [review]
debugging output

Can you also attach the dmesg output with this patch applied?
Comment 8 Paul Menzel 2014-01-15 00:06:29 UTC
Just a note, that the Debian Linux kernel has fbcon compiled in.

    CONFIG_FRAMEBUFFER_CONSOLE=y
Comment 9 Paul Menzel 2014-01-15 09:04:16 UTC
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)
Comment 10 Paul Menzel 2014-01-15 09:28:15 UTC
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.
Comment 11 Paul Menzel 2014-01-15 09:31:18 UTC
Created attachment 92128 [details]
X server log file with Linux 3.13-rc8-disable-ss

I attached an USB mouse later on.
Comment 12 Paul Menzel 2014-01-15 13:50:03 UTC
Alex, please tell me if you still need the Linux output with your second patch applied or anything else. Thanks again!
Comment 13 Paul Menzel 2014-01-15 13:51:40 UTC
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.)
Comment 14 Alex Deucher 2014-01-15 14:09:42 UTC
(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?
Comment 15 Alex Deucher 2014-01-15 14:15:41 UTC
(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.
Comment 16 Paul Menzel 2014-01-15 15:59:52 UTC
(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?
Comment 17 Alex Deucher 2014-01-15 16:05:31 UTC
(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.
Comment 18 Alex Deucher 2014-01-15 19:05:21 UTC
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.
Comment 19 Alex Deucher 2014-01-15 19:06:08 UTC
Created attachment 92172 [details] [review]
patch 2/2

Patch 2/2.  The actual fix for this bug.
Comment 20 Paul Menzel 2014-01-15 20:57:38 UTC
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)
Comment 21 Alex Deucher 2014-01-15 21:03:52 UTC
(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.
Comment 22 Alex Deucher 2014-01-15 21:05:29 UTC
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.
Comment 23 Paul Menzel 2014-01-15 21:06:12 UTC
Turning the display off and on again, the display works fine.

    $ xrandr --output eDP --off
    $ xrandr --output eDP --auto
Comment 24 Alex Deucher 2014-01-15 21:08:40 UTC
(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)?
Comment 25 Paul Menzel 2014-01-15 21:11:54 UTC
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?
Comment 26 Alex Deucher 2014-01-15 21:16:32 UTC
(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.
Comment 27 Paul Menzel 2014-01-15 22:10:38 UTC
So turning the display off and on with xrandr or xset does not always work even with the patched Linux kernel.
Comment 28 Paul Menzel 2014-01-15 22:18:31 UTC
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.
Comment 29 Paul Menzel 2014-01-15 23:27:35 UTC
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.
Comment 30 Alex Deucher 2014-01-16 03:14:50 UTC
Have you tested the patch in attachment 92172 [details] [review]?  Does it help at all?
Comment 31 Paul Menzel 2014-01-16 08:19:45 UTC
Sorry, I missed the two patches. I’ll test them now.
Comment 32 Paul Menzel 2014-01-16 09:05:26 UTC
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.
Comment 33 Paul Menzel 2014-01-16 09:33:58 UTC
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.
Comment 34 Paul Menzel 2014-01-16 09:37:34 UTC
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.
Comment 35 Alex Deucher 2014-01-16 15:01:37 UTC
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
Comment 36 Paul Menzel 2014-01-16 23:02:46 UTC
(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.
Comment 37 Paul Menzel 2014-01-17 00:34:29 UTC
(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.
Comment 38 Paul Menzel 2014-01-17 00:35:01 UTC
Is there a way to look at the Windows driver to know what the timing should be?
Comment 39 Paul Menzel 2014-01-17 00:35:48 UTC
Once the display works, it seems to work always during consecutive off/on cycles.
Comment 40 Paul Menzel 2014-01-17 08:35:28 UTC
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.
Comment 41 Paul Menzel 2014-01-17 08:38:15 UTC
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.
Comment 42 Paul Menzel 2014-01-17 16:03:40 UTC
Do you still need the debugging output of the native(?) mode lines and want me to apply your patch and test it?
Comment 43 Paul Menzel 2014-01-17 16:05:56 UTC
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.
Comment 44 Alex Deucher 2014-01-17 17:41:32 UTC
(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.
Comment 45 Paul Menzel 2014-01-17 22:03:58 UTC
Anything I should try/look at over the weekend?
Comment 46 Paul Menzel 2014-01-22 15:24:24 UTC
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.
Comment 47 Paul Menzel 2014-01-22 16:15:44 UTC
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
Comment 48 Alex Deucher 2014-01-22 16:21:15 UTC
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.
Comment 49 Paul Menzel 2014-01-25 09:27:47 UTC
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.)
Comment 50 Paul Menzel 2014-01-25 13:25:39 UTC
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.
Comment 51 Paul Menzel 2014-01-29 22:25:43 UTC
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.
Comment 52 Paul Menzel 2014-01-30 08:54:14 UTC
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
Comment 53 Paul Menzel 2014-01-30 11:48:11 UTC
So where can I get the specifications about DisplayPort link training? Is it in [1]?

[1] http://www.vesa.org/vesa-standards/free-standards/
Comment 54 Alex Deucher 2014-01-30 14:47:48 UTC
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().
Comment 55 Paul Menzel 2014-02-01 11:50:26 UTC
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;
Comment 56 Paul Menzel 2014-02-01 11:57:04 UTC
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?
Comment 57 Paul Menzel 2014-02-01 12:00:26 UTC
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.
Comment 58 Paul Menzel 2014-02-01 12:02:18 UTC
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.
Comment 59 Paul Menzel 2014-02-03 09:49:42 UTC
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)?
Comment 60 Paul Menzel 2014-02-06 09:43:00 UTC
Just an update that I get the same behavior with Dave’s drm-fixes branch, which has Linux 3.14-rc1 included.
Comment 61 Paul Menzel 2014-02-17 13:08:00 UTC
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.
Comment 62 Paul Menzel 2014-02-17 13:09:35 UTC
I forgot to thank you for all your help and it makes me sad that I had to come to the conclusion.
Comment 63 Christian Aßfalg 2014-10-21 15:03:40 UTC
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?
Comment 64 Paul Menzel 2014-10-22 20:42:37 UTC
(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?
Comment 65 Alex Deucher 2014-10-22 21:14:20 UTC
(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);
Comment 66 Christian Aßfalg 2014-10-22 21:29:48 UTC
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.
Comment 67 Christian Aßfalg 2014-10-22 21:34:57 UTC
@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?
Comment 68 Florentin Raud 2014-11-06 22:20:18 UTC
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.
Comment 69 Nicolas Werner 2014-11-16 12:14:28 UTC
(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
Comment 70 Alex Deucher 2014-11-17 16:02:33 UTC
(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.
Comment 71 Nicolas Werner 2014-11-17 19:03:51 UTC
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!
Comment 72 Benjamin 2014-11-28 01:28:55 UTC
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.
Comment 73 Alex Deucher 2014-12-01 02:10:34 UTC
(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.
Comment 74 Paul Menzel 2015-01-13 23:16:34 UTC
(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.
Comment 75 N.Leiten 2015-05-04 08:44:36 UTC
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.
Comment 76 Nicolas Werner 2015-05-08 00:01:14 UTC
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
Comment 77 N.Leiten 2015-05-08 07:36:31 UTC
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.
Comment 78 Alex Deucher 2015-05-08 13:47:54 UTC
Please note that DP is not direct clocked.  The link runs at either 1.62 or 2.7 Ghz depending on the bandwidth requirements.
Comment 79 N.Leiten 2015-05-08 14:03:41 UTC
(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.
Comment 80 N.Leiten 2015-05-10 17:26:10 UTC
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.
Comment 81 Nicolas Werner 2015-05-11 16:09:37 UTC
I can confirm that hacking radeon_dp_get_dp_lane_number to return 2 does yield a working display (and acceleration), great find!
Comment 82 N.Leiten 2015-05-11 17:10:32 UTC
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.
Comment 83 Alex Deucher 2015-05-11 17:29:29 UTC
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.
Comment 84 N.Leiten 2015-05-11 17:44:26 UTC
(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.
Comment 85 Alex Deucher 2015-05-11 17:59:52 UTC
(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.
Comment 86 N.Leiten 2015-05-11 18:03:27 UTC
(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.
Comment 87 Samir Ibradžić 2015-05-12 17:17:55 UTC
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?
Comment 88 Alex Deucher 2015-05-14 13:33:35 UTC
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.
Comment 89 Nicolas Werner 2015-05-14 15:37:30 UTC
(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
Comment 90 Alex Deucher 2015-05-14 15:59:28 UTC
(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
Comment 91 Nicolas Werner 2015-05-14 16:15:29 UTC
(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?
Comment 92 Nicolas Werner 2015-05-14 16:22:34 UTC
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
Comment 93 Alex Deucher 2015-05-14 17:36:23 UTC
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.
Comment 94 Nicolas Werner 2015-05-14 18:34:33 UTC
(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
Comment 95 Alex Deucher 2015-05-14 19:10:16 UTC
Created attachment 115780 [details] [review]
add some debugging output

Can you attach the dmesg output with the attached patch?
Comment 96 Nicolas Werner 2015-05-14 19:45:04 UTC
(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
Comment 97 Alex Deucher 2015-05-14 20:01:51 UTC
Created attachment 115782 [details] [review]
more debugging

Can you attach your dmesg output with the attached patch?  Please include all the radeon related output.
Comment 98 Nicolas Werner 2015-05-14 20:40:44 UTC
(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
Comment 99 Alex Deucher 2015-05-14 23:50:48 UTC
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.
Comment 100 Nicolas Werner 2015-05-15 01:04:59 UTC
(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
Comment 101 Alex Deucher 2015-05-15 14:16:17 UTC
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?
Comment 102 Alex Deucher 2015-05-15 14:28:33 UTC
Created attachment 115802 [details] [review]
retry dpcd fetch

Does this patch help?
Comment 103 Nicolas Werner 2015-05-15 20:16:09 UTC
(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
Comment 104 Nicolas Werner 2015-05-15 20:22:50 UTC
(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
Comment 105 Samir Ibradžić 2015-05-16 15:40:03 UTC
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.
Comment 106 Samir Ibradžić 2015-05-16 15:48:21 UTC
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.
Comment 107 Alex Deucher 2015-05-18 21:44:47 UTC
(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.
Comment 108 N.Leiten 2015-05-19 18:45:00 UTC
(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.
Comment 109 Alex Deucher 2015-05-19 19:05:13 UTC
(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.
Comment 110 Norbert Pfeiler 2015-07-15 08:02:03 UTC
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.
Comment 111 N.Leiten 2015-08-06 09:24:46 UTC
At this point I see that problem was fixed with linux kernel 4.2.0-rc4.
Comment 112 Paul Menzel 2015-08-09 06:15:03 UTC
(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?
Comment 113 Alex Deucher 2015-08-10 02:41:00 UTC
(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
Comment 114 Christian Aßfalg 2015-08-10 13:47:44 UTC
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!
Comment 115 Norbert Pfeiler 2015-08-12 01:53:29 UTC
(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.
Comment 116 Alex Deucher 2015-08-12 13:17:11 UTC
(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).


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.