| Bug ID | 100919 |
|---|---|
| Summary | "Out of range" on a display connected to a DVI-D ou= tput of RX460 card via DVI-D<=3D>HDMI-A cable |
| Product | DRI |
| Version | DRI git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | nikola.forro@gmail.com |
I'm using the latest code from amd-staging-4.9 branch of ~agd5= f/linux. The problem is caused by this commit: https://cgit.freed= esktop.org/~agd5f/linux/commit/?h=3Damd-staging-4.9&id=3D2b2d4cfb0a6299= 61a44e1ea0b29d336c1336deb9 After this change, when sink_signal is DVI_DUAL_LINK but pix_clk_khz is low= er 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" er= ror.
| What | Removed | Added |
|---|---|---|
| Summary | "Out of range" on a display connected to a DVI-D o= utput of RX460 card via DVI-D<=3D>HDMI-A cable | [DC] "Out of range" on a display connected to a DV= I-D output of RX460 card via DVI-D<=3D>HDMI-A cable |
I arrived here by way of having a similar problem and bisectin= g 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 actu= al device (if its info menu can be trusted). Most other resolutions I tried fa= il with out of range.
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 thi= s. Harry
Comment on attachm= ent 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 > TMD= S_MAX_PIXEL_CLOCK_IN_KHZ) > stream->signal =3D SIGNAL_TYPE_DVI_DUAL_LINK; > + else > + stream->signal =3D 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 conc= ern: + 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 =3D SIGNAL_TYPE_DVI_DUAL_LINK;
else
stream->signal =3D SIGNAL_TYPE_DVI_SINGLE_LINK;
}
Hi Alex, yes, that's exactly what I meant. Sorry for not being clear. Nikola
| What | Removed | Added |
|---|---|---|
| Attachment #131276 is obsolete | 1 |
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 conve= rters, I had this problem with going directly DVI card <-> display.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | FIXED |
| What | Removed | Added |
|---|---|---|
| Status | RESOLVED | REOPENED |
| Resolution | FIXED | --- |
I finally came around to testing vanilla 4.15.4, and the probl= em is in there, still. Also I'm having trouble translating the patch by Harry to the refact= ored 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 uncertai= n 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=3Damd-staging-dr= m-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 =3D 31cd02/0 [ 0.584434] [drm] probing mlw for device 1002:5a16 =3D 31cd02 [ 0.584472] [drm] VCE enabled in physical mode [ 0.584775] amdgpu 0000:05:00.0: Invalid PCI ROM header signature: expec= ting 0xaa55, got 0xb60f [ 0.585447] [drm] vm size is 64 GB, 2 levels, block size is 10-bit, frag= ment 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=3D2048M, BAR=3D256M [ 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 0x000000F40004000= 0). [ 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 t= he 2nd monitor, including * dmesg log with amdgpu.dc_log=3D1 and drm.debug=3D0x6 kernel options * model of both monitors and how they're connected (DP, HDMI, etc... any adapter) * commit from amd-staging-drm-next being tested
| What | Removed | Added |
|---|---|---|
| Status | REOPENED | RESOLVED |
| Resolution | --- | FIXED |