Bug 100919

Summary: [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable
Product: DRI Reporter: Nikola Forró <nikola.forro>
Component: DRM/AMDgpuAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: freedesktop-bugs, harry.wentland
Version: DRI git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Relevant dmesg
none
Patch to fix this (hopefully)
none
2nd attempt at patch none

Description Nikola Forró 2017-05-03 19:12:30 UTC
I'm using the latest code from amd-staging-4.9 branch of ~agd5f/linux.

The problem is caused by this commit:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-4.9&id=2b2d4cfb0a629961a44e1ea0b29d336c1336deb9

After this change, when sink_signal is DVI_DUAL_LINK but pix_clk_khz is lower than TMDS_MAX_PIXEL_CLOCK_IN_KHZ, stream->signal is set to DVI_DUAL_LINK, while previously it was being set to DVI_SINGLE_LINK.

As a result, the connected display just reports "Out of range" error.
Comment 1 Thomas R. 2017-05-09 04:01:37 UTC
I arrived here by way of having a similar problem and bisecting it down to the very same commit. When running a kernel containing it, on my R9 285, modesetting on my two DVI monitors takes very long and results in a weird resolution that looks like 1920x1080 to the system and 960x1080 to the actual device (if its info menu can be trusted). Most other resolutions I tried fail with out of range.
Comment 2 Thomas R. 2017-05-09 04:02:51 UTC
Created attachment 131274 [details]
Relevant dmesg
Comment 3 Harry Wentland 2017-05-09 14:54:14 UTC
Created attachment 131276 [details] [review]
Patch to fix this (hopefully)

Hi Nikola, Thomas.

Thanks for reporting this.

Try this patch. I haven't been able to test it myself but it should fix this.

Harry
Comment 4 Nikola Forró 2017-05-09 17:12:28 UTC
Comment on attachment 131276 [details] [review]
Patch to fix this (hopefully)

Review of attachment 131276 [details] [review]:
-----------------------------------------------------------------

::: drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ +1268,4 @@
>  		stream->public.timing.pix_clk_khz > TMDS_MAX_PIXEL_CLOCK_IN_KHZ)
>  		stream->signal = SIGNAL_TYPE_DVI_DUAL_LINK;
> +	else
> +		stream->signal = SIGNAL_TYPE_DVI_SINGLE_LINK;

I don't think this is such a good idea, because AFAICS this sets stream->signal to SIGNAL_TYPE_DVI_SINGLE_LINK also for all types of signal other than DVI.
Comment 5 Harry Wentland 2017-05-09 17:24:45 UTC
Nikola, this line from the patch should take care of your concern:

+	if (dc_is_dvi_signal(stream->signal) &&

Other signal types shouldn't be affected.
Comment 6 Alex Deucher 2017-05-09 17:29:36 UTC
what about the else case?  Shouldn't the logic be:


	if (dc_is_dvi_signal(stream->signal)) {
 		if (stream->public.timing.pix_clk_khz > TMDS_MAX_PIXEL_CLOCK_IN_KHZ)
 		        stream->signal = SIGNAL_TYPE_DVI_DUAL_LINK;
	        else
		        stream->signal = SIGNAL_TYPE_DVI_SINGLE_LINK;
        }
Comment 7 Nikola Forró 2017-05-09 17:34:52 UTC
Hi Alex,

yes, that's exactly what I meant.
Sorry for not being clear.

Nikola
Comment 8 Harry Wentland 2017-05-09 17:40:38 UTC
Created attachment 131279 [details] [review]
2nd attempt at patch

Thanks, Alex, Nikola, for pointing out the problem in my code. I should've looked more closely. Here's an update.
Comment 9 Nikola Forró 2017-05-09 18:13:03 UTC
Thanks Harry,

I've just tested the patch and I can confirm it fixes the problem.
Comment 10 Thomas R. 2017-05-26 14:32:32 UTC
Can confirm it works for me, too (although I accidentally also updated to 4.11 while testing it, but the relevant DC code looks unchanged and the patch applied, so I presume it's responsible, not the update). Thanks!
Comment 11 Thomas R. 2017-05-26 14:33:45 UTC
Forgot to add a note: I'm not actually using HDMI or any converters, I had this problem with going directly DVI card <-> display.
Comment 12 Thomas R. 2018-02-19 07:31:25 UTC
I finally came around to testing vanilla 4.15.4, and the problem is in there, still. Also I'm having trouble translating the patch by Harry to the refactored code - I guess it should go into display/dc/core/dc_link.c somewhere, but I don't know where exactly, as there is no update_stream_signal() in there anymore. The closest place I found is in dc_link_detect(), but I'm uncertain if I should make the SINGLE or DUAL_LINK decision in there?

Harry, can you look at this or do you need more info from me?
Comment 13 Harry Wentland 2018-02-20 19:38:13 UTC
Are you able to test amd-staging-drm-next (https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next)? The issue should be fixed there and you wouldn't have to fiddle with patches.
Comment 14 Thomas R. 2018-02-26 15:43:56 UTC
Harry, I tried amd-staging-drm-next and there is no corruption on the primary, but my second monitor is dead. It may be something like bug #91202 or something else entirely, the dmesg output is very sparse (egrep drm|amd below).

What can I do now?

[    0.583791] [drm] amdgpu kernel modesetting enabled.
[    0.583968] [drm] initializing kernel modesetting (TONGA 0x1002:0x6939 0x1043:0x0486 0x00).
[    0.584028] [drm] register mmio base: 0xFE980000
[    0.584071] [drm] register mmio size: 262144
[    0.584109] [drm] add ip block number 0 <vi_common>
[    0.584140] [drm] add ip block number 1 <gmc_v8_0>
[    0.584172] [drm] add ip block number 2 <tonga_ih>
[    0.584207] [drm] add ip block number 3 <amdgpu_powerplay>
[    0.584239] [drm] add ip block number 4 <dm>
[    0.584271] [drm] add ip block number 5 <gfx_v8_0>
[    0.584303] [drm] add ip block number 6 <sdma_v3_0>
[    0.584334] [drm] add ip block number 7 <uvd_v5_0>
[    0.584367] [drm] add ip block number 8 <vce_v3_0>
[    0.584402] [drm] probing gen 2 caps for device 1002:5a16 = 31cd02/0
[    0.584434] [drm] probing mlw for device 1002:5a16 = 31cd02
[    0.584472] [drm] VCE enabled in physical mode
[    0.584775] amdgpu 0000:05:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xb60f
[    0.585447] [drm] vm size is 64 GB, 2 levels, block size is 10-bit, fragment size is 9-bit
[    0.585490] amdgpu 0000:05:00.0: VRAM: 2048M 0x000000F400000000 - 0x000000F47FFFFFFF (2048M used)
[    0.585526] amdgpu 0000:05:00.0: GTT: 1024M 0x0000000000000000 - 0x000000003FFFFFFF
[    0.585563] [drm] Detected VRAM RAM=2048M, BAR=256M
[    0.585594] [drm] RAM width 256bits GDDR5
[    0.585843] [drm] amdgpu: 2048M of VRAM memory ready
[    0.585874] [drm] amdgpu: 3072M of GTT memory ready.
[    0.585907] [drm] GART: num cpu pages 262144, num gpu pages 262144
[    0.586405] [drm] PCIE GART of 1024M enabled (table at 0x000000F400040000).
[    0.587618] [drm] Found UVD firmware Version: 1.65 Family ID: 10
[    0.588927] [drm] Found VCE firmware Version: 52.8 Binary ID: 3
[    0.638265] [drm] Display Core initialized with v3.1.34!
[    0.651084] [drm] SADs count is: -2, don't need to read it
[    0.663759] [drm] SADs count is: -2, don't need to read it
[    0.663823] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    0.663879] [drm] Driver supports precise vblank timestamp query.
[    0.712563] [drm] UVD initialized successfully.
[    0.921688] [drm] VCE initialized successfully.
[    0.925673] [drm] fb mappable at 0xD0566000
[    0.925738] [drm] vram apper at 0xD0000000
[    0.925798] [drm] size 8294400
[    0.925857] [drm] fb depth is 24
[    0.925909] [drm]    pitch is 7680
[    0.926025] fbcon: amdgpudrmfb (fb0) is primary device
[    1.123458] amdgpu 0000:05:00.0: fb0: amdgpudrmfb frame buffer device
[    1.131506] [drm] Initialized amdgpu 3.25.0 20150101 for 0000:05:00.0 on minor 0
Comment 15 Harry Wentland 2018-02-26 15:50:30 UTC
Please open a separate ticket for the issue with amd-stg and the 2nd monitor, including
* dmesg log with amdgpu.dc_log=1 and drm.debug=0x6 kernel options
* model of both monitors and how they're connected (DP, HDMI, etc... any adapter)
* commit from amd-staging-drm-next being tested
Comment 16 Thomas R. 2018-03-09 14:02:17 UTC
Closed, creating new bug as per comment 15.

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.