Bug 108139 - My HDMI stopped working at Linux 4.18.8
Summary: My HDMI stopped working at Linux 4.18.8
Status: NEW
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: 2018-11-06 09:45 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

Note You need to log in before you can comment on or make changes to this bug.
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?


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.