Radeon Verde displayport failure.

2015-05-20 Thread Alex Deucher 
On Thu, May 14, 2015 at 11:52 PM, Dave Jones  wrote:
> On Thu, May 14, 2015 at 09:49:52AM -0400, Alex Deucher wrote:
>  > On Tue, May 12, 2015 at 8:04 PM, Dave Jones  
> wrote:
>  > > On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:
>  > >
>  > >  > > I tried tweaking the delays in 
> drm_dp_link_train_clock_recovery_delay, without any noticable
>  > >  > > difference.  Is there something else I can try to make it try 
> harder before giving up?
>  > >  > >
>  > >  >
>  > >  > Can you attach your boot dmesg output with drm.debug=0xf set?
>  > >  >
>  > >  > You might also check the dpcd values in the driver during boot up and
>  > >  > link training.  There appears to be an issue where that data gets
>  > >  > corrupted in some cases:
>  > >  > https://bugs.freedesktop.org/show_bug.cgi?id=73530
>  > >
>  > > I tried both the 'disable spread spectrum' and 'grab dpcd info from 
> vbios for eDP'
>  > > patches from that bug. Again, no obvious difference.
>  > >
>  > > Log from kernel with both applied attached.
>  > >
>  > > Also a log file from after I woke up the LCD when it was in sleep mode.
>  > >
>  > > Something else curious is how it only discovers a maximum mode from the 
> LCD
>  > > of 1024x768.
>  >
>  > I looks like the monitor is not responding.  I'm not entirely sure
>  > what's going on.  I posted a new debugging patch on the bug report
>  > that will dump the dpcd at various times to see if and when it's
>  > getting corrupt.  Fixing that should at least get the monitor to come
>  > up reliably (assuming you are experiencing the same issue).
>
> Thanks to some back-and-forth on irc, airlied got this mostly working.
> The working combo seems to be..
>
> - Switch monitor to DP 1.2
> - boot with radeon.mst=1
> - apply the patch below
>
> With all that, it boots up, and X starts up in 2560x1440 like it should.
>
> The only remaining problem is there are some visible glitches, mostly 
> noticable
> while scrolling a terminal.
>
> Happy to continue applying further debug patches if you have any more ideas.
>

I think the attached patch should get aux working as reliably as the
old atom code.  The atom code ignores bits 12-14 when checking the
transaction flags.

Alex


> thanks,
> Dave
>
>
> diff --git a/drivers/gpu/drm/radeon/radeon_dp_auxch.c 
> b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
> index bf1fecc6cceb..3b401cc8d209 100644
> --- a/drivers/gpu/drm/radeon/radeon_dp_auxch.c
> +++ b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
> @@ -30,7 +30,6 @@
> AUX_SW_RX_HPD_DISCON |   \
> AUX_SW_RX_PARTIAL_BYTE | \
> AUX_SW_NON_AUX_MODE |\
> -   AUX_SW_RX_MIN_COUNT_VIOL |   \
> AUX_SW_RX_INVALID_STOP | \
> AUX_SW_RX_SYNC_INVALID_L |   \
> AUX_SW_RX_SYNC_INVALID_H |   \
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-fix-error-flag-checking-in-native-aux-pat.patch
Type: text/x-patch
Size: 1055 bytes
Desc: not available
URL:

Radeon Verde displayport failure.

2015-05-15 Thread Michel Dänzer 
On 15.05.2015 12:52, Dave Jones wrote:
> 
> The only remaining problem is there are some visible glitches, mostly 
> noticable
> while scrolling a terminal.

What kind of glitches? If it's tearing, with current xf86-video-ati Git
you can try Option "TearFree".


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Radeon Verde displayport failure.

2015-05-15 Thread Dave Jones 
On Fri, May 15, 2015 at 06:16:59PM +0900, Michel Dänzer wrote:
 > On 15.05.2015 12:52, Dave Jones wrote:
 > > 
 > > The only remaining problem is there are some visible glitches, mostly 
 > > noticable
 > > while scrolling a terminal.
 > 
 > What kind of glitches? If it's tearing, with current xf86-video-ati Git
 > you can try Option "TearFree".

Hard to describe, just sort of.. bursts of coloured sparkle noise in
random positions.
They don't remain part of the image permanently, and only appear for a
split second. They are pretty constant when scrolling though.

I'll see if I can get video of it when I'm in front of it again on Monday.

One other bug I noticed: Once it goes into DPMS, I can't wake it up again
and need to reboot. Likewise if I power off the monitor and back on,
it goes into power saving again.

Dave

Radeon Verde displayport failure.

2015-05-15 Thread Dave Jones 
On Thu, May 14, 2015 at 09:49:52AM -0400, Alex Deucher wrote:
 > On Tue, May 12, 2015 at 8:04 PM, Dave Jones  
 > wrote:
 > > On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:
 > >
 > >  > > I tried tweaking the delays in 
 > > drm_dp_link_train_clock_recovery_delay, without any noticable
 > >  > > difference.  Is there something else I can try to make it try harder 
 > > before giving up?
 > >  > >
 > >  >
 > >  > Can you attach your boot dmesg output with drm.debug=0xf set?
 > >  >
 > >  > You might also check the dpcd values in the driver during boot up and
 > >  > link training.  There appears to be an issue where that data gets
 > >  > corrupted in some cases:
 > >  > https://bugs.freedesktop.org/show_bug.cgi?id=73530
 > >
 > > I tried both the 'disable spread spectrum' and 'grab dpcd info from vbios 
 > > for eDP'
 > > patches from that bug. Again, no obvious difference.
 > >
 > > Log from kernel with both applied attached.
 > >
 > > Also a log file from after I woke up the LCD when it was in sleep mode.
 > >
 > > Something else curious is how it only discovers a maximum mode from the LCD
 > > of 1024x768.
 > 
 > I looks like the monitor is not responding.  I'm not entirely sure
 > what's going on.  I posted a new debugging patch on the bug report
 > that will dump the dpcd at various times to see if and when it's
 > getting corrupt.  Fixing that should at least get the monitor to come
 > up reliably (assuming you are experiencing the same issue).

Thanks to some back-and-forth on irc, airlied got this mostly working.
The working combo seems to be..

- Switch monitor to DP 1.2
- boot with radeon.mst=1
- apply the patch below

With all that, it boots up, and X starts up in 2560x1440 like it should.

The only remaining problem is there are some visible glitches, mostly noticable
while scrolling a terminal.

Happy to continue applying further debug patches if you have any more ideas.

thanks,
Dave


diff --git a/drivers/gpu/drm/radeon/radeon_dp_auxch.c 
b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
index bf1fecc6cceb..3b401cc8d209 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_auxch.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
@@ -30,7 +30,6 @@
AUX_SW_RX_HPD_DISCON |   \
AUX_SW_RX_PARTIAL_BYTE | \
AUX_SW_NON_AUX_MODE |\
-   AUX_SW_RX_MIN_COUNT_VIOL |   \
AUX_SW_RX_INVALID_STOP | \
AUX_SW_RX_SYNC_INVALID_L |   \
AUX_SW_RX_SYNC_INVALID_H |   \

Radeon Verde displayport failure.

2015-05-14 Thread Dave Jones 
On Thu, May 14, 2015 at 09:49:52AM -0400, Alex Deucher wrote:
 > On Tue, May 12, 2015 at 8:04 PM, Dave Jones  
 > wrote:
 > > On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:
 > >
 > >  > > I tried tweaking the delays in 
 > > drm_dp_link_train_clock_recovery_delay, without any noticable
 > >  > > difference.  Is there something else I can try to make it try harder 
 > > before giving up?
 > >  > >
 > >  >
 > >  > Can you attach your boot dmesg output with drm.debug=0xf set?
 > >  >
 > >  > You might also check the dpcd values in the driver during boot up and
 > >  > link training.  There appears to be an issue where that data gets
 > >  > corrupted in some cases:
 > >  > https://bugs.freedesktop.org/show_bug.cgi?id=73530
 > >
 > > I tried both the 'disable spread spectrum' and 'grab dpcd info from vbios 
 > > for eDP'
 > > patches from that bug. Again, no obvious difference.
 > >
 > > Log from kernel with both applied attached.
 > >
 > > Also a log file from after I woke up the LCD when it was in sleep mode.
 > >
 > > Something else curious is how it only discovers a maximum mode from the LCD
 > > of 1024x768.
 > 
 > I looks like the monitor is not responding.  I'm not entirely sure
 > what's going on.  I posted a new debugging patch on the bug report
 > that will dump the dpcd at various times to see if and when it's
 > getting corrupt.  Fixing that should at least get the monitor to come
 > up reliably (assuming you are experiencing the same issue).

attached.

Dave

-- next part --
[7.071367] [drm] Initialized drm 1.1.0 20060810
[7.096163] [drm] radeon kernel modesetting enabled.
[7.096206] [drm:drm_pci_init] 
[7.096301] [drm:drm_get_pci_dev] 
[7.096385] [drm:drm_minor_register] 
[7.098055] [drm:drm_minor_register] new minor registered 64
[7.098065] [drm:drm_minor_register] 
[7.098158] [drm:drm_minor_register] new minor registered 128
[7.098163] [drm:drm_minor_register] 
[7.098225] [drm:drm_minor_register] new minor registered 0
[7.098237] [drm] initializing kernel modesetting (VERDE 0x1002:0x682C 
0x1002:0x2B1E).
[7.098251] [drm] register mmio base: 0xFBE0
[7.098254] [drm] register mmio size: 262144
[7.098315] [drm:radeon_get_bios] ATOMBIOS detected
[7.098325] [drm:atom_allocate_fb_scratch] atom firmware requested 001fffe0 
32kb
[7.098470] [drm] Detected VRAM RAM=2048M, BAR=256M
[7.098473] [drm] RAM width 128bits DDR
[7.098602] [drm] radeon: 2048M of VRAM memory ready
[7.098607] [drm] radeon: 1024M of GTT memory ready.
[7.098621] [drm:si_init_microcode] 
[7.098625] [drm] Loading verde Microcode
[7.103464] [drm] Internal thermal controller with fan control
[7.103596] [drm] probing gen 2 caps for device 8086:2f08 = 77a3903/e
[7.103631] [drm:radeon_ucode_print_mc_hdr] MC
[7.103635] [drm:radeon_ucode_print_common_hdr] size_bytes: 32044
[7.103638] [drm:radeon_ucode_print_common_hdr] header_size_bytes: 40
[7.103641] [drm:radeon_ucode_print_common_hdr] header_version_major: 1
[7.103645] [drm:radeon_ucode_print_common_hdr] header_version_minor: 0
[7.103648] [drm:radeon_ucode_print_common_hdr] ip_version_major: 6
[7.103651] [drm:radeon_ucode_print_common_hdr] ip_version_minor: 0
[7.103655] [drm:radeon_ucode_print_common_hdr] ucode_version: 0x00a37610
[7.103658] [drm:radeon_ucode_print_common_hdr] ucode_size_bytes: 31500
[7.103661] [drm:radeon_ucode_print_common_hdr] ucode_array_offset_bytes: 544
[7.103665] [drm:radeon_ucode_print_common_hdr] crc32: 0x442d834d
[7.103678] [drm:radeon_ucode_print_mc_hdr] io_debug_size_bytes: 288
[7.103681] [drm:radeon_ucode_print_mc_hdr] io_debug_array_offset_bytes: 256
[7.104415] [drm:radeon_ucode_print_smc_hdr] SMC
[7.104419] [drm:radeon_ucode_print_common_hdr] size_bytes: 61800
[7.104422] [drm:radeon_ucode_print_common_hdr] header_size_bytes: 36
[7.104426] [drm:radeon_ucode_print_common_hdr] header_version_major: 1
[7.104429] [drm:radeon_ucode_print_common_hdr] header_version_minor: 0
[7.104432] [drm:radeon_ucode_print_common_hdr] ip_version_major: 6
[7.104435] [drm:radeon_ucode_print_common_hdr] ip_version_minor: 0
[7.104439] [drm:radeon_ucode_print_common_hdr] ucode_version: 0x0133524b
[7.104442] [drm:radeon_ucode_print_common_hdr] ucode_size_bytes: 61544
[7.104445] [drm:radeon_ucode_print_common_hdr] ucode_array_offset_bytes: 256
[7.104449] [drm:radeon_ucode_print_common_hdr] crc32: 0xfcbfb6b3
[7.104452] [drm:radeon_ucode_print_smc_hdr] ucode_start_addr: 65536
[7.111599] [drm] radeon: dpm initialized
[7.135847] [drm] GART: num cpu pages 262144, num gpu pages 262144
[7.136428] [drm] probing gen 2 caps for device 8086:2f08 = 77a3903/e
[7.136435] [drm] PCIE gen 3 link speeds already enabled
[7.141626] [drm] PCIE GART of 1024M enabled (table at 0x00277000).
[7.142164] [drm] Supports vblank timestamp caching

Radeon Verde displayport failure.

2015-05-14 Thread Alex Deucher 
On Tue, May 12, 2015 at 8:04 PM, Dave Jones  wrote:
> On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:
>
>  > > I tried tweaking the delays in drm_dp_link_train_clock_recovery_delay, 
> without any noticable
>  > > difference.  Is there something else I can try to make it try harder 
> before giving up?
>  > >
>  >
>  > Can you attach your boot dmesg output with drm.debug=0xf set?
>  >
>  > You might also check the dpcd values in the driver during boot up and
>  > link training.  There appears to be an issue where that data gets
>  > corrupted in some cases:
>  > https://bugs.freedesktop.org/show_bug.cgi?id=73530
>
> I tried both the 'disable spread spectrum' and 'grab dpcd info from vbios for 
> eDP'
> patches from that bug. Again, no obvious difference.
>
> Log from kernel with both applied attached.
>
> Also a log file from after I woke up the LCD when it was in sleep mode.
>
> Something else curious is how it only discovers a maximum mode from the LCD
> of 1024x768.

I looks like the monitor is not responding.  I'm not entirely sure
what's going on.  I posted a new debugging patch on the bug report
that will dump the dpcd at various times to see if and when it's
getting corrupt.  Fixing that should at least get the monitor to come
up reliably (assuming you are experiencing the same issue).

Alex

Radeon Verde displayport failure.

2015-05-12 Thread Dave Jones 
On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:

 > > I tried tweaking the delays in drm_dp_link_train_clock_recovery_delay, 
 > > without any noticable
 > > difference.  Is there something else I can try to make it try harder 
 > > before giving up?
 > >
 > 
 > Can you attach your boot dmesg output with drm.debug=0xf set?
 > 
 > You might also check the dpcd values in the driver during boot up and
 > link training.  There appears to be an issue where that data gets
 > corrupted in some cases:
 > https://bugs.freedesktop.org/show_bug.cgi?id=73530

I tried both the 'disable spread spectrum' and 'grab dpcd info from vbios for 
eDP'
patches from that bug. Again, no obvious difference.

Log from kernel with both applied attached.

Also a log file from after I woke up the LCD when it was in sleep mode.

Something else curious is how it only discovers a maximum mode from the LCD
of 1024x768.

Dave

-- next part --
[7.082329] [drm:drm_get_pci_dev] 
[7.082418] [drm:drm_minor_register] 
[7.082492] [drm:drm_minor_register] new minor registered 64
[7.082497] [drm:drm_minor_register] 
[7.082544] [drm:drm_minor_register] new minor registered 128
[7.082547] [drm:drm_minor_register] 
[7.082631] [drm:drm_minor_register] new minor registered 0
[7.082643] [drm] initializing kernel modesetting (VERDE 0x1002:0x682C 
0x1002:0x2B1E).
[7.082661] [drm] register mmio base: 0xFBE0
[7.082664] [drm] register mmio size: 262144
[7.082699] radeon :01:00.0: Invalid ROM contents
[7.082749] [drm:radeon_get_bios] ATOMBIOS detected
[7.082761] [drm:atom_allocate_fb_scratch] atom firmware requested 001fffe0 
32kb
[7.082909] radeon :01:00.0: VRAM: 2048M 0x - 
0x7FFF (2048M used)
[7.082917] radeon :01:00.0: GTT: 1024M 0x8000 - 
0xBFFF
[7.082923] [drm] Detected VRAM RAM=2048M, BAR=256M
[7.082927] [drm] RAM width 128bits DDR
[7.083017] [drm] radeon: 2048M of VRAM memory ready
[7.083020] [drm] radeon: 1024M of GTT memory ready.
[7.083037] [drm:si_init_microcode] 
[7.083040] [drm] Loading verde Microcode
[7.087660] [drm] Internal thermal controller with fan control
[7.087745] [drm] probing gen 2 caps for device 8086:2f08 = 77a3903/e
[7.087797] [drm:radeon_ucode_print_mc_hdr] MC
[7.087801] [drm:radeon_ucode_print_common_hdr] size_bytes: 32044
[7.087804] [drm:radeon_ucode_print_common_hdr] header_size_bytes: 40
[7.087807] [drm:radeon_ucode_print_common_hdr] header_version_major: 1
[7.087809] [drm:radeon_ucode_print_common_hdr] header_version_minor: 0
[7.087831] [drm:radeon_ucode_print_common_hdr] ip_version_major: 6
[7.087834] [drm:radeon_ucode_print_common_hdr] ip_version_minor: 0
[7.087837] [drm:radeon_ucode_print_common_hdr] ucode_version: 0x00a37610
[7.087839] [drm:radeon_ucode_print_common_hdr] ucode_size_bytes: 31500
[7.087842] [drm:radeon_ucode_print_common_hdr] ucode_array_offset_bytes: 544
[7.087845] [drm:radeon_ucode_print_common_hdr] crc32: 0x442d834d
[7.087847] [drm:radeon_ucode_print_mc_hdr] io_debug_size_bytes: 288
[7.087850] [drm:radeon_ucode_print_mc_hdr] io_debug_array_offset_bytes: 256
[7.088947] [drm:radeon_ucode_print_smc_hdr] SMC
[7.088951] [drm:radeon_ucode_print_common_hdr] size_bytes: 61800
[7.088953] [drm:radeon_ucode_print_common_hdr] header_size_bytes: 36
[7.088957] [drm:radeon_ucode_print_common_hdr] header_version_major: 1
[7.088960] [drm:radeon_ucode_print_common_hdr] header_version_minor: 0
[7.088964] [drm:radeon_ucode_print_common_hdr] ip_version_major: 6
[7.088968] [d[7.097176] [drm] radeon: dpm initialized
[7.110401] [drm] GART: num cpu pages 262144, num gpu pages 262144
[7.111088] [drm] probing gen 2 caps for device 8086:2f08 = 77a3903/e
[7.111096] [drm] PCIE gen 3 link speeds already enabled
[7.116299] [drm] PCIE GART of 1024M enabled (table at 0x00277000).
[7.116423] radeon :01:00.0: WB enabled
[7.116430] radeon :01:00.0: fence driver on ring 0 use gpu addr 
0x8c00 and cpu addr 0x880805abdc00
[7.116438] radeon :01:00.0: fence driver on ring 1 use gpu addr 
0x8c04 and cpu addr 0x880805abdc04
[7.116445] radeon :01:00.0: fence driver on ring 2 use gpu addr 
0x8c08 and cpu addr 0x880805abdc08
[7.116451] radeon :01:00.0: fence driver on ring 3 use gpu addr 
0x8c0c and cpu addr 0x880805abdc0c
[7.116458] radeon :01:00.0: fence driver on ring 4 use gpu addr 
0x8c10 and cpu addr 0x880805abdc10
[7.116774] radeon :01:00.0: fence driver on ring 5 use gpu addr 
0x00075a18 and cpu addr 0xc9835a18
[7.116783] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[7.116786] [drm] Driver supports precise vblank timestamp query.
[7.116791] radeon

Radeon Verde displayport failure.

2015-05-12 Thread Dave Jones 
On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:

 > Can you attach your boot dmesg output with drm.debug=0xf set?

Strange, haven't seen this happen before.

[8.437431] [drm:drm_calc_vbltimestamp_from_scanoutpos] crtc 5: Noop due to 
uninitialized mode.
[8.437433] [drm:drm_update_vblank_count] updating vblank count on crtc 5, 
missed 0
[8.437444] [drm:drm_helper_probe_single_connector_modes_merge_bits] 
[CONNECTOR:40:DP-1]
[8.437506] [drm:si_irq_process] si_irq_process start: rptr 208, wptr 224
[8.437523] [drm:si_irq_process] si_irq_process start: rptr 224, wptr 224
[8.440711] [drm:radeon_dp_getdpcd] DPCD: 12 14 c4 01 01 01 01 81 02 00 06 
00 00 00 00
[8.441242] [drm:radeon_dp_aux_transfer_native] dp_aux_ch flags not zero: 
04001001
[8.441758] [drm:radeon_dp_probe_oui] Branch OUI: 00e04c
[8.442204] [drm:radeon_dp_mst_probe] Sink is MST capable
[8.742140] Oops:  [#1] PREEMPT SMP 
[8.742150] CPU: 3 PID: 418 Comm: systemd-udevd Not tainted 4.1.0-rc3-wopr+ 
#3
[8.742156] task: 88080a09f290 ti: 880808224000 task.ti: 
880808224000
[8.742160] RIP: 0010:[]  [] 
__list_add+0x50/0xe0
[8.742167] RSP: 0018:8808082276b8  EFLAGS: 00010246
[8.742170] RAX:  RBX:  RCX: 
[8.742173] RDX: 880805871720 RSI:  RDI: 8808082276f8
[8.742175] RBP: 8808082276e8 R08: 880808224000 R09: 
[8.742178] R10: 003d R11: 053e R12: 880805871720
[8.742181] R13: 88080a09f290 R14:  R15: 880805871720
[8.742184] FS:  7f16f77bd880() GS:88080f2c() 
knlGS:
[8.742188] CS:  0010 DS:  ES:  CR0: 80050033
[8.742190] CR2:  CR3: 00080820b000 CR4: 001407e0
[8.742193] Stack:
[8.742195]  0001 880805871718 0001 
880805871718
[8.742200]  88080587171c 88080a09f290 880808227748 
866ec970
[8.742205]  880808227758 866e5488 0018 
bea51cc4
[8.742210] Call Trace:
[8.742216]  [] __mutex_lock_slowpath+0x80/0x150
[8.742220]  [] ? printk+0x55/0x6b
[8.742223]  [] mutex_lock+0x1b/0x30
[8.742230]  [] drm_dp_mst_topology_mgr_set_mst+0x3a/0x3e0 
[drm_kms_helper]
[8.742251]  [] radeon_dp_mst_probe+0xaa/0x100 [radeon]
[8.742268]  [] radeon_dp_detect+0x26d/0x2f0 [radeon]
[8.742273]  [] 
drm_helper_probe_single_connector_modes_merge_bits+0x2c8/0x510 [drm_kms_helper]
[8.742278]  [] 
drm_helper_probe_single_connector_modes+0x13/0x20 [drm_kms_helper]
[8.742285]  [] 
drm_fb_helper_probe_connector_modes.isra.3+0x50/0x70 [drm_kms_helper]
[8.742291]  [] drm_fb_helper_initial_config+0x5a/0x410 
[drm_kms_helper]
[8.742304]  [] ? drm_modeset_unlock_all+0x42/0x70 [drm]
[8.742321]  [] radeon_fbdev_init+0xf4/0x120 [radeon]
[8.742335]  [] radeon_modeset_init+0x484/0xa60 [radeon]
[8.742354]  [] ? radeon_ib_ring_tests+0x5a/0xc0 [radeon]
[8.742368]  [] radeon_driver_load_kms+0x140/0x250 [radeon]
[8.742375]  [] drm_dev_register+0xb5/0x110 [drm]
[8.742382]  [] drm_get_pci_dev+0x8d/0x200 [drm]
[8.742394]  [] radeon_pci_probe+0xa3/0xd0 [radeon]
[8.742398]  [] pci_device_probe+0x8c/0xf0
[8.742402]  [] driver_probe_device+0x159/0x4c0
[8.742405]  [] __driver_attach+0x9b/0xa0
[8.742408]  [] ? __device_attach+0x40/0x40
[8.742412]  [] bus_for_each_dev+0x73/0xc0
[8.742415]  [] driver_attach+0x1e/0x20
[8.742418]  [] bus_add_driver+0x180/0x250
[8.742421]  [] driver_register+0x64/0xf0
[8.742425]  [] __pci_register_driver+0x4b/0x50
[8.742432]  [] drm_pci_init+0xfa/0x130 [drm]
[8.742436]  [] ? 0xc082d000
[8.742448]  [] radeon_init+0xdd/0xdf [radeon]
[8.742454]  [] do_one_initcall+0xd8/0x200
[8.742458]  [] ? __vunmap+0xa2/0x100
[8.742462]  [] ? kfree+0x173/0x180
[8.742465]  [] do_init_module+0x61/0x1cc
[8.742469]  [] load_module+0x1f90/0x23b0
[8.742472]  [] ? store_uevent+0x70/0x70
[8.742476]  [] ? copy_module_from_fd.isra.48+0xe5/0x1a0
[8.742479]  [] ? copy_module_from_fd.isra.48+0x132/0x1a0
[8.742483]  [] ? __acct_update_integrals+0x8b/0x120
[8.742486]  [] SyS_finit_module+0xa6/0xe0
[8.742490]  [] system_call_fastpath+0x12/0x6a
[8.742493] Code: c1 30 cc 84 86 31 c0 48 c7 c2 38 83 a3 86 be 1a 00 00 00 
48 c7 c7 b8 7d a3 86 e8 cc d8 cb ff 48 83 c4 18 5b 41 5c 41 5d 5d c3 90 <4c> 8b 
0e 4c 39 ca 74 38 48 89 34 24 49 89 d0 48 c7 c1 30 cc 84

Radeon Verde displayport failure.

2015-05-11 Thread Dave Jones 
On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:

 > >  >  > The link training with the monitor seems to fail periodically.  You 
 > > may have to play with the timing in the link training sequence.  It looks 
 > > like you also have some power management related issues.  Does booting 
 > > with radeon.dpm=0 on the kernel command line in grub help?  Also does the 
 > > monitor support audio?  You might also try radeon.audio=0.
 > >  >
 > >  > Pretty much the same story with those options..
 > >  >
 > >  > [8.162285] [drm:si_dpm_set_power_state [radeon]] *ERROR* 
 > > si_enable_smc_cac failed
 > >  > [8.170753] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport 
 > > link status failed
 > >  > [8.170778] [drm:radeon_dp_link_train [radeon]] *ERROR* clock 
 > > recovery failed
 > >  >
 > >  > I did manage to get it to display something for a while. By disabling 
 > > DP1.2 with the
 > >  > LCDs OSD, but then it would only do a maximum of 1024x768. And after a 
 > > reboot,
 > >  > I saw the same messages above, and straight to power saving.
 > >
 > > I tried tweaking the delays in drm_dp_link_train_clock_recovery_delay, 
 > > without any noticable
 > > difference.  Is there something else I can try to make it try harder 
 > > before giving up?
 > >
 > Can you attach your boot dmesg output with drm.debug=0xf set?

Sure. Attached.  I noticed some of the printks are garbled.
Hopefully the important parts lie elsewhere.

 > You might also check the dpcd values in the driver during boot up and
 > link training.  There appears to be an issue where that data gets
 > corrupted in some cases:
 > https://bugs.freedesktop.org/show_bug.cgi?id=73530

Hm, I'll try out some of the patches in that report later (Assuming they aren't
already in the 4.1rc kernel)

thanks for the pointers.

Dave
-- next part --
[7.182169] [drm] Initialized drm 1.1.0 20060810
[7.209807] [drm] radeon kernel modesetting enabled.
[7.209837] [drm:drm_pci_init] 
[7.209943] [drm:drm_get_pci_dev] 
[7.210022] [drm:drm_minor_register] 
[7.210093] [drm:drm_minor_register] new minor registered 64
[7.210101] [drm:drm_minor_register] 
[7.210145] [drm:drm_minor_register] new minor registered 128
[7.210150] [drm:drm_minor_register] 
[7.210185] [drm:drm_minor_register] new minor registered 0
[7.210195] [drm] initializing kernel modesetting (VERDE 0x1002:0x682C 
0x1002:0x2B1E).
[7.210209] [drm] register mmio base: 0xFBE0
[7.210211] [drm] register mmio size: 262144
[7.210274] [drm:radeon_get_bios] ATOMBIOS detected
[7.210281] [drm:atom_allocate_fb_scratch] atom firmware requested 001fffe0 
32kb
[7.210434] [drm] Detected VRAM RAM=2048M, BAR=256M
[7.210438] [drm] RAM width 128bits DDR
[7.210507] [drm] radeon: 2048M of VRAM memory ready
[7.210510] [drm] radeon: 1024M of GTT memory ready.
[7.210520] [drm:si_init_microcode] 
[7.210522] [drm] Loading verde Microcode
[7.215344] [drm] Internal thermal controller with fan control
[7.215420] [drm] probing gen 2 caps for device 8086:2f08 = 77a3903/e
[7.215454] [drm:radeon_ucode_print_mc_hdr] MC
[7.215458] [drm:radeon_ucode_print_common_hdr] size_bytes: 32044
[7.215461] [drm:radeon_ucode_print_common_hdr] header_size_bytes: 40
[7.215466] [drm:radeon_ucode_print_common_hdr] header_version_major: 1
[7.215472] [drm:radeon_ucode_print_common_hdr] header_version_minor: 0
[7.215477] [drm:radeon_ucode_print_common_hdr] ip_version_major: 6
[7.215481] [drm:radeon_ucode_print_common_hdr] ip_version_minor: 0
[7.215484] [drm:radeon_ucode_print_common_hdr] ucode_version: 0x00a37610
[7.215487] [drm:radeon_ucode_print_common_hdr] ucode_size_bytes: 31500
[7.215490] [drm:radeon_ucode_print_common_hdr] ucode_array_offset_bytes: 544
[7.215494] [drm:radeon_ucode_print_common_hdr] crc32: 0x442d834d
[7.215497] [drm:radeon_ucode_print_mc_hdr] io_debug_size_bytes: 288
[7.215500] [drm:radeon_ucode_print_mc_hdr] io_debug_array_offset_bytes: 256
[7.216170] [drm:radeon_ucode_print_smc_hdr] SMC
[7.216175] [drm:radeon_ucode_print_common_hdr] size_bytes: 61800
[7.216178] [drm:radeon_ucode_print_common_hdr] header_size_bytes: 36
[7.216181] [drm:radeon_ucode_print_common_hdr] header_version_major: 1
[7.216184] [drm:radeon_ucode_print_common_hdr] header_version_minor: 0
[7.216187] [drm:radeon_ucode_print_common_hdr] ip_version_major: 6
[7.216190] [drm:radeon_ucode_print_common_hdr] ip_version_minor: 0
[7.216193] [drm:radeon_ucode_print_common_hdr] ucode_version: 0x0133524b
[7.216196] [drm:radeon_ucode_print_common_hdr] ucode_size_bytes: 61544
[7.216199] [drm:radeon_ucode_print_common_hdr] ucode_array_offset_bytes: 256
[7.216202] [drm:radeon_ucode_print_common_hdr] crc32: 0xfcbfb6b3
[7.216205] [drm:radeon_ucode_print_smc_hdr] ucode_start_addr: 65536
[7.222971] [drm] radeon: dpm initialized
[

Radeon Verde displayport failure.

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

Can you attach your boot dmesg output with drm.debug=0xf set?

You might also check the dpcd values in the driver during boot up and
link training.  There appears to be an issue where that data gets
corrupted in some cases:
https://bugs.freedesktop.org/show_bug.cgi?id=73530

Alex

Radeon Verde displayport failure.

2015-05-11 Thread Dave Jones 
On Fri, May 08, 2015 at 11:40:55AM -0400, Dave Jones wrote:
 > On Fri, May 08, 2015 at 01:23:59PM +, Deucher, Alexander wrote:

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

I tried tweaking the delays in drm_dp_link_train_clock_recovery_delay, without 
any noticable
difference.  Is there something else I can try to make it try harder before 
giving up?

Dave

Radeon Verde displayport failure.

2015-05-08 Thread Deucher, Alexander 
> -Original Message-
> From: Dave Jones [mailto:davej at codemonkey.org.uk]
> Sent: Thursday, May 07, 2015 7:48 PM
> To: dri-devel at lists.freedesktop.org
> Cc: Deucher, Alexander; Koenig, Christian
> Subject: Radeon Verde displayport failure.
> 
> I just bought a new radeon (1002:682c), to pair with my shiny new displayport
> monitor.
> It shows a display during through the BIOS POST, and grub, but when the
> kernel
> starts up, it's a coin toss whether or not I get anything.
> Sometimes it just goes straight into power saving.
> 
> When I do get something on the console, it continues to boot and then X
> starts up and
> puts it into power saving too. Trying to flip back to tty1 doesn't light up 
> the
> display again.
> 
> I'm running On debian stable, with copied-by-hand verde_* firmware files
> from the linux-firmware git tree.
> Here's a log from the 4.0-rc2 kernel.
> 
> Any other info I can provide ?
> 

The link training with the monitor seems to fail periodically.  You may have to 
play with the timing in the link training sequence.  It looks like you also 
have some power management related issues.  Does booting with radeon.dpm=0 on 
the kernel command line in grub help?  Also does the monitor support audio?  
You might also try radeon.audio=0.

Alex

>   Dave
> 
> 
> 
> [drm] register mmio base: 0xFBE0
> [drm] register mmio size: 262144
> radeon :01:00.0: Invalid ROM contents
> ATOM BIOS: C755
> radeon :01:00.0: VRAM: 2048M 0x -
> 0x7FFF (2048M used)
> radeon :01:00.0: GTT: 1024M 0x8000 - 0xBFFF
> [drm] Detected VRAM RAM=2048M, BAR=256M
> [drm] RAM width 128bits DDR
> [TTM] Zone  kernel: Available graphics memory: 16400232 kiB
> [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
> [TTM] Initializing pool allocator
> [TTM] Initializing DMA pool allocator
> [drm] radeon: 2048M of VRAM memory ready
> [drm] radeon: 1024M of GTT memory ready.
> [drm] Loading verde Microcode
> [drm] Internal thermal controller with fan control
> [drm] probing gen 2 caps for device 8086:2f08 = 77a3103/e
> input: HDA ATI HDMI HDMI as
> /devices/pci:00/:00:03.0/:01:00.1/sound/card0/input4
> input: HDA ATI HDMI HDMI as
> /devices/pci:00/:00:03.0/:01:00.1/sound/card0/input5
> [drm] radeon: dpm initialized
> [drm] GART: num cpu pages 262144, num gpu pages 262144
> [drm] probing gen 2 caps for device 8086:2f08 = 77a3103/e
> [drm] PCIE gen 3 link speeds already enabled
> [drm] PCIE GART of 1024M enabled (table at 0x00277000).
> radeon :01:00.0: WB enabled
> radeon :01:00.0: fence driver on ring 0 use gpu addr 0x8c00
> and cpu addr 0x880807d0ac00
> radeon :01:00.0: fence driver on ring 1 use gpu addr 0x8c04
> and cpu addr 0x880807d0ac04
> radeon :01:00.0: fence driver on ring 2 use gpu addr 0x8c08
> and cpu addr 0x880807d0ac08
> radeon :01:00.0: fence driver on ring 3 use gpu addr 0x8c0c
> and cpu addr 0x880807d0ac0c
> radeon :01:00.0: fence driver on ring 4 use gpu addr 0x8c10
> and cpu addr 0x880807d0ac10
> radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00075a18
> and cpu addr 0xc90001035a18
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [drm] Driver supports precise vblank timestamp query.
> radeon :01:00.0: radeon: MSI limited to 32-bit
> radeon :01:00.0: radeon: using MSI.
> [drm] radeon: irq initialized.
> [drm] ring test on 0 succeeded in 1 usecs
> [drm] ring test on 1 succeeded in 1 usecs
> [drm] ring test on 2 succeeded in 1 usecs
> [drm] ring test on 3 succeeded in 9 usecs
> [drm] ring test on 4 succeeded in 3 usecs
> [drm] ring test on 5 succeeded in 2 usecs
> [drm] UVD initialized successfully.
> [drm] ib test on ring 0 succeeded in 0 usecs
> [drm] ib test on ring 1 succeeded in 0 usecs
> [drm] ib test on ring 2 succeeded in 0 usecs
> [drm] ib test on ring 3 succeeded in 0 usecs
> [drm] ib test on ring 4 succeeded in 0 usecs
> [drm] ib test on ring 5 succeeded
> [drm] Radeon Display Connectors
> [drm] Connector 0:
> [drm]   DP-1
> [drm]   HPD4
> [drm]   DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 0x654c
> [drm]   Encoders:
> [drm] DFP1: INTERNAL_UNIPHY2
> [drm] Connector 1:
> [drm]   DP-2
> [drm]   HPD5
> [drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c
> [drm]   Encoders:
> [drm] DFP2: INTERNAL_UNIPHY1
> [drm] Connector 2:
> [drm]   DP-3
> [drm]   HPD1
> [drm]   DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c 0x656c
> [drm]   Encoders:
> [drm] DFP3: INTERNAL_UNIPHY1
> [drm] Connec

Radeon Verde displayport failure.

2015-05-08 Thread Dave Jones 
On Fri, May 08, 2015 at 01:23:59PM +, Deucher, Alexander wrote:
 > > -Original Message-
 > > From: Dave Jones [mailto:davej at codemonkey.org.uk]
 > > Sent: Thursday, May 07, 2015 7:48 PM
 > > To: dri-devel at lists.freedesktop.org
 > > Cc: Deucher, Alexander; Koenig, Christian
 > > Subject: Radeon Verde displayport failure.
 > > 
 > > I just bought a new radeon (1002:682c), to pair with my shiny new 
 > > displayport
 > > monitor.
 > > It shows a display during through the BIOS POST, and grub, but when the
 > > kernel
 > > starts up, it's a coin toss whether or not I get anything.
 > > Sometimes it just goes straight into power saving.
 > > 
 > > When I do get something on the console, it continues to boot and then X
 > > starts up and
 > > puts it into power saving too. Trying to flip back to tty1 doesn't light 
 > > up the
 > > display again.
 > > 
 > > I'm running On debian stable, with copied-by-hand verde_* firmware files
 > > from the linux-firmware git tree.
 > > Here's a log from the 4.0-rc2 kernel.
 > > 
 > > Any other info I can provide ?
 > > 
 > 
 > The link training with the monitor seems to fail periodically.  You may have 
 > to play with the timing in the link training sequence.  It looks like you 
 > also have some power management related issues.  Does booting with 
 > radeon.dpm=0 on the kernel command line in grub help?  Also does the monitor 
 > support audio?  You might also try radeon.audio=0.

Pretty much the same story with those options..

[8.162285] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_enable_smc_cac 
failed
[8.170753] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link 
status failed
[8.170778] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed

I did manage to get it to display something for a while. By disabling DP1.2 
with the
LCDs OSD, but then it would only do a maximum of 1024x768. And after a reboot,
I saw the same messages above, and straight to power saving.

Dave

Radeon Verde displayport failure.

2015-05-07 Thread Dave Jones 
I just bought a new radeon (1002:682c), to pair with my shiny new displayport 
monitor.
It shows a display during through the BIOS POST, and grub, but when the kernel
starts up, it's a coin toss whether or not I get anything.
Sometimes it just goes straight into power saving.

When I do get something on the console, it continues to boot and then X starts 
up and
puts it into power saving too. Trying to flip back to tty1 doesn't light up the 
display again.

I'm running On debian stable, with copied-by-hand verde_* firmware files from 
the linux-firmware git tree.
Here's a log from the 4.0-rc2 kernel.

Any other info I can provide ?

Dave



[drm] register mmio base: 0xFBE0
[drm] register mmio size: 262144
radeon :01:00.0: Invalid ROM contents
ATOM BIOS: C755
radeon :01:00.0: VRAM: 2048M 0x - 0x7FFF (2048M 
used)
radeon :01:00.0: GTT: 1024M 0x8000 - 0xBFFF
[drm] Detected VRAM RAM=2048M, BAR=256M
[drm] RAM width 128bits DDR
[TTM] Zone  kernel: Available graphics memory: 16400232 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 2048M of VRAM memory ready
[drm] radeon: 1024M of GTT memory ready.
[drm] Loading verde Microcode
[drm] Internal thermal controller with fan control
[drm] probing gen 2 caps for device 8086:2f08 = 77a3103/e
input: HDA ATI HDMI HDMI as 
/devices/pci:00/:00:03.0/:01:00.1/sound/card0/input4
input: HDA ATI HDMI HDMI as 
/devices/pci:00/:00:03.0/:01:00.1/sound/card0/input5
[drm] radeon: dpm initialized
[drm] GART: num cpu pages 262144, num gpu pages 262144
[drm] probing gen 2 caps for device 8086:2f08 = 77a3103/e
[drm] PCIE gen 3 link speeds already enabled
[drm] PCIE GART of 1024M enabled (table at 0x00277000).
radeon :01:00.0: WB enabled
radeon :01:00.0: fence driver on ring 0 use gpu addr 0x8c00 and 
cpu addr 0x880807d0ac00
radeon :01:00.0: fence driver on ring 1 use gpu addr 0x8c04 and 
cpu addr 0x880807d0ac04
radeon :01:00.0: fence driver on ring 2 use gpu addr 0x8c08 and 
cpu addr 0x880807d0ac08
radeon :01:00.0: fence driver on ring 3 use gpu addr 0x8c0c and 
cpu addr 0x880807d0ac0c
radeon :01:00.0: fence driver on ring 4 use gpu addr 0x8c10 and 
cpu addr 0x880807d0ac10
radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00075a18 and 
cpu addr 0xc90001035a18
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
radeon :01:00.0: radeon: MSI limited to 32-bit
radeon :01:00.0: radeon: using MSI.
[drm] radeon: irq initialized.
[drm] ring test on 0 succeeded in 1 usecs
[drm] ring test on 1 succeeded in 1 usecs
[drm] ring test on 2 succeeded in 1 usecs
[drm] ring test on 3 succeeded in 9 usecs
[drm] ring test on 4 succeeded in 3 usecs
[drm] ring test on 5 succeeded in 2 usecs
[drm] UVD initialized successfully.
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 1 succeeded in 0 usecs
[drm] ib test on ring 2 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
[drm] ib test on ring 4 succeeded in 0 usecs
[drm] ib test on ring 5 succeeded
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   DP-1
[drm]   HPD4
[drm]   DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 0x654c
[drm]   Encoders:
[drm] DFP1: INTERNAL_UNIPHY2
[drm] Connector 1:
[drm]   DP-2
[drm]   HPD5
[drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c
[drm]   Encoders:
[drm] DFP2: INTERNAL_UNIPHY1
[drm] Connector 2:
[drm]   DP-3
[drm]   HPD1
[drm]   DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c 0x656c
[drm]   Encoders:
[drm] DFP3: INTERNAL_UNIPHY1
[drm] Connector 3:
[drm]   DP-4
[drm]   HPD2
[drm]   DDC: 0x6580 0x6580 0x6584 0x6584 0x6588 0x6588 0x658c 0x658c
[drm]   Encoders:
[drm] DFP4: INTERNAL_UNIPHY
[drm:si_dpm_set_power_state [radeon]] *ERROR* si_enable_smc_cac failed
[drm] fb mappable at 0xD047A000
[drm] vram apper at 0xD000
[drm] size 3145728
[drm] fb depth is 24
[drm]pitch is 4096
fbcon: radeondrmfb (fb0) is primary device
[drm:si_dpm_set_power_state [radeon]] *ERROR* si_enable_smc_cac failed
[drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
[drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
Console: switching to colour frame buffer device 128x48
radeon :01:00.0: fb0: radeondrmfb frame buffer device
radeon :01:00.0: registered panic notifier
[drm] Initialized radeon 2.42.0 20080528 for :01:00.0 on minor 0
[drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
[drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed