With RX480 and 3x4k with two Displayport and one HDMI connected I got 60Hz60Hz60Hz up to kernel 4.18.0-0.rc0.git8 but starting with 4.18.0-0.rc0.git10 and 4.18.0-0.rc1.git0 I only get 30Hz 60Hz 60Hz and the one that will not give me more than 1970s television refreshrate is connected over HDMI. There seems to be big regression somewhere.
Created attachment 140217 [details] xorg log with HDMI connected monitor failing to do 60Hz, does 30Hz max
Created attachment 140218 [details] dmesg incriminating evidence 18.0-0.rc1.git0
Created attachment 140219 [details] Xorg log with last kernel that works and allows 4k 60Hz over HDMI
Created attachment 140220 [details] dmesg of working kernel 4.18.0-0.rc0.git8 no idea if this helps but if I must provide more incriminating evidence files to solve the bug then please let me know what files are required and commands to make them. thank you for you attention
Can you bisect?
(In reply to Michel Dänzer from comment #5) > Can you bisect? http://www.landley.net/writing/git-bisect-howto.html probably, it can't be that hard
in linux/kernel/git/torvalds/linux.git d819d298c7258849d56eb400be436aff3ba2aae2 works fine becfc5e97cbab00b25a592aabc36838ec7217d1f is the first that does not and gives me 30Hz 60Hz 60Hz That pull has lots of changes and I don't know which exact one causes this total scandal, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=becfc5e97cbab00b25a592aabc36838ec7217d1f don't know how to bisect just one file in a commit like that. perhaps it's not that difficult, figuring out this bisect howto thing wasn't.
The bisect process isn't finished yet. Keep going until git bisect either identifies the single commit which introduced the issue, or the minimum set of candidates.
Created attachment 140247 [details] e03fd3f300f6184c1264186a4c815e93bf658abb is the first bad commit e03fd3f300f6184c1264186a4c815e93bf658abb is the first bad commit commit e03fd3f300f6184c1264186a4c815e93bf658abb Author: Mikita Lipski <mikita.lipski@amd.com> Date: Wed May 16 16:46:18 2018 -0400 drm/amd/display: Do not limit color depth to 8bpc Delete if statement that would force any display's color depth higher than 8 bpc to 8 Signed-off-by: Mikita Lipski <mikita.lipski@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> :040000 040000 57c7a743a10059addbfdd1a122f90c4053d377fa 13139317e62ef56db1748bf48f31f81eb986c7f8 M drivers
is the cause that HDMI can't 10-bit color at 60Hz on 4k? the displays connected by DisplayPort don't have this problem and one DP connected monitor is identical to the HDMI connected one. The GPU don't have more than 2 DP connectors so I'm stuck with eeeew HDMI (don't like that connector, it's the worst) for one display.
Hi, Could you please dump the edids for both DP and HDMI, so we can identify the delta.
Created attachment 140248 [details] edid dump attempt file is output of for f in /sys/class/drm/*/edid ; do edid-decode $f;done > /tmp/edid-decode.txt this is running the kernel that gives 60hz 60hz 60hz, no idea if it makes a difference (edid should be the same?). let me know if you require more information and now to aquire it.
(In reply to Öyvind Saether from comment #10) > is the cause that HDMI can't 10-bit color at 60Hz on 4k? the displays > connected by DisplayPort don't have this problem and one DP connected > monitor is identical to the HDMI connected one. The GPU don't have more than > 2 DP connectors so I'm stuck with eeeew HDMI (don't like that connector, > it's the worst) for one display. That seems to be the case.
Could you please also enable KMS debug messages before plugging in HDMI display (or choosing 60Hz refresh rate), while I'm trying to find a display to reproduce the issue on my setup. Just run this command as a sudo: # echo 0x4 > /sys/module/drm/parameters/debug
Created attachment 140256 [details] dmesg after booting with drm.debug=0x04 log_buf_len=5M and switching to 24hz then back to 60hz with kernel that can do 60hz 60hz 60hz this is with kernel that does 60hz on HDMI, it's boot then switched to 24hz with xfce4-display-manager and then switch back to 60Hz. didn't unplug the monitor, didn't think it would differ (could do that if it's helpful) sent some other dmesg output files too per e-mail. let me know if this wasn't the right information required. Also, I have a RX560 connected to a 1440p via DP, I could connect a 4K monitor to that box and see what happens if it's somehow helpful (probably acts the same way?).
Created attachment 140266 [details] VP28U on HDMI gives same result as PB27U, 24hz on that display ASUS PB27U or VP28U on HDMI produces the same problem (4k 24Hz default, max 30Hz available, no 4k 60Hz). This is dmesg with drm.debug=0x04 log_buf_len=5M
Created attachment 140267 [details] VP28U on HDMI dmesg with working kernel that gives 4k 60Hz dmesg with drm.debug=0x04 log_buf_len=5M on kernel that works with 4k 60Hz on VP28U connected with HDMI.
Any progress on this? The bug is still present in 4.18.0-rc2 (git as of an hour ago). Total scandal. Works on my system right now, though, since I stuffed bpc = 8; before switch (bpc) in drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c and compiled. Perhaps a temporary fix could be a kernel parameter such as amdgpu.8bit=1 Or the code could check if the connector is HDMI and resolution is 4k and set bpc=8 if that is true. I suspect it would be a bit bad if 4.18 is released with this problem, btw. It breaks 4k60Hz over HDMI on both my 4K's so it probably applies to most of the 4K monitors out there. Thank you for reading all of this. Please fix my bug.
Created attachment 140449 [details] [review] This patch should fix the issue for you. It hasn't been pushed to the kernel tree since it is in our internal staging branch, but it should be released soon.
Created attachment 140450 [details] [review] Drop to the maximum supported colour depth on HDMI. Sorry the previous patch has 2 additional files modified that should not have been amended. Please ignore the previous patch and use this one instead. Thanks
(In reply to mikita.lipski@amd.com from comment #19) > This patch should fix the issue for you. It hasn't been pushed to the kernel > tree since it is in our internal staging branch, but it should be released > soon. Regression fixes need to go upstream ASAP. Please send the patch to the amd-gfx list for review, and push it to amd-staging-drm-next as soon as it's reviewed (and ideally confirmed to fix the regression). P.S. Please add Bugzilla: https://bugs.freedesktop.org/106959 to the commit log to reference this report.
Thank you so much. I replaced the RX470 with a RX570 with 3xDP but I really appreciate the quick fix anyway. Thank you.
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function ‘fill_stream_properties_from_drm_display_mode’: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:2273:51: error: ‘info’ undeclared (first use in this function); did you mean ‘insl’? check_if_display_depth_is_supported(timing_out, info); ^~~~ insl drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:2273:51: note: each undeclared identifier is reported only once for each function it appears in make[4]: *** [scripts/Makefile.build:317: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.o] Error 1 make[4]: *** Waiting for unfinished jobs.... make[3]: *** [scripts/Makefile.build:558: drivers/gpu/drm/amd/amdgpu] Error 2 make[2]: *** [scripts/Makefile.build:558: drivers/gpu/drm] Error 2 make[1]: *** [scripts/Makefile.build:558: drivers/gpu] Error 2 make: *** [Makefile:1034: drivers] Error 2
Created attachment 140464 [details] [review] Adding YCbCr4:2:0 pixel encoding support for HDMI connectors The previous patch depends on display_ingo structure introduced with this patch. I haven't realized that it has not been yet promoted with the rest of the DC patches. Not it should build fine. Thanks for testing.
Feel free to add my tested by on those two patches
Testing using a HDMI cable now on 4.18.0-rc3-2NE1+ which includes the patches as c42c12a905454734bbddaa9ca62413b4d493234e in kernel/git/torvalds/linux.git It seems to work just fine, 4k60Hz on all displays. Thanks.
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.