Bug 100919

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.

Created attachment 131274 [details]
Relevant dmesg

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 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.

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.

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;
        }

Hi Alex,

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

Nikola

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.

Thanks Harry,

I've just tested the patch and I can confirm it fixes the problem.

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!

Forgot to add a note: I'm not actually using HDMI or any converters, I had this problem with going directly DVI card <-> display.

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?

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.

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

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

Closed, creating new bug as per comment 15.