Bug 108139 - My HDMI stopped working at Linux 4.18.8
Summary: My HDMI stopped working at Linux 4.18.8
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/AMDgpu (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-03 02:32 UTC by Duncan Roe
Modified: 2019-08-05 08:03 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg output as requested (92.95 KB, text/plain)
2018-10-09 20:52 UTC, Duncan Roe
no flags Details
Current work-around patch (1014 bytes, patch)
2018-11-06 09:28 UTC, Duncan Roe
no flags Details | Splinter Review

Description Duncan Roe 2018-10-03 02:32:52 UTC
At Linux 4.18.8 the HDMI monitor started to report "No Signal" although Xorg can see a screen when it's started.(There's no signal with or without X).
Using bisection, I found the change that caused this is commit to be 691f2d763d0731224439686ecf2d440df8fe910e:

+++ b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
@@ -808,6 +808,24 @@ static enum bp_result transmitter_control_v1_5(
         * (=1: 8bpp, =1.25: 10bpp, =1.5:12bpp, =2: 16bpp)
         * LVDS mode: usPixelClock = pixel clock
         */
+       if  (cntl->signal == SIGNAL_TYPE_HDMI_TYPE_A) {
+               switch (cntl->color_depth) {
+               case COLOR_DEPTH_101010:
+                       params.usSymClock =
+                               cpu_to_le16((le16_to_cpu(params.usSymClock) * 30) / 24);
+                       break;
+               case COLOR_DEPTH_121212:
+                       params.usSymClock =
+                               cpu_to_le16((le16_to_cpu(params.usSymClock) * 36) / 24);
+                       break;
+               case COLOR_DEPTH_161616:
+                       params.usSymClock =
+                               cpu_to_le16((le16_to_cpu(params.usSymClock) * 48) / 24);
+                       break;
+               default:
+                       break;
+               }
+       }
 
        if (EXEC_BIOS_CMD_TABLE(UNIPHYTransmitterControl, params))
                result = BP_RESULT_OK;

Inserted printk stmts showed my monitor reports COLOR_DEPTH_121212. I suspect the clock speed is too high for the video card, so the code needs to check the card model before bumping the speed, but I don't know how to do that.
Here are all the details I an think of:
Video card (from lspci): VGA compatible controller:
Advanced Micro Devices, Inc. [AMD/ATI] Radeon R2 Graphics (rev ea)
Monitor (from /var/log/Xorg.0.log): Monitor name: DELL U2711
Ranges: V min: 49 V max: 86 Hz, H min: 29 H max: 113 kHz, PixClock max 285 MHz
Hardware name (from /var/log/debug):
HP HP Laptop 15-bw0xx/8330, BIOS F.11 07/05/2017
Comment 1 Duncan Roe 2018-10-03 02:33:44 UTC
Still need to pull the patch at 4.18.11
Comment 2 Nicholas Kazlauskas 2018-10-09 13:00:17 UTC
Do you mind posting a full dmesg log for your 4.18 kernel? It would probably help to have drm.debug=4 in your boot parameters as well for this.
Comment 3 Duncan Roe 2018-10-09 20:52:30 UTC
Created attachment 141963 [details]
dmesg output as requested

Added dmesg output as requested
Comment 4 Duncan Roe 2018-11-03 09:08:16 UTC
commit 691f2d763d0731224439686ecf2d440df8fe910e is on branch linux-4.18.y of git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git. It was merged into branch master as part of commit 54dbe75bbf1e189982516de179147208e90b5e45
Comment 5 Alex Deucher 2018-11-05 19:23:19 UTC
(In reply to Nicholas Kazlauskas from comment #2)
> Do you mind posting a full dmesg log for your 4.18 kernel? It would probably
> help to have drm.debug=4 in your boot parameters as well for this.

Is deep color support on Stoney limited?  IIRC, there were some limitations.
Comment 6 Duncan Roe 2018-11-06 09:28:36 UTC
Created attachment 142387 [details] [review]
Current work-around patch
Comment 7 Duncan Roe 2018-11-06 09:42:25 UTC
I am currently running Linux 4.19.1 with  Attachment 142387 [details] and not seeing the problem. Might it be possible to instead use an approach like Attachment 142350 [details] to Bug 108139 to conditionally obey this code instead of removing it?
Comment 8 Duncan Roe 2018-11-06 09:45:35 UTC
I am currently running Linux 4.19.1 with  Attachment 142387 [details] and not seeing the problem. Might it be possible to instead use an approach like Attachment 142350 [details] to Bug 108577 to conditionally obey this code instead of removing it?
Comment 9 Duncan Roe 2019-08-05 08:03:21 UTC
Since Linux 5.1, I do not see this bug any more.
So I guess it is "fixed".


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.