Bug 102401 - Radeon Displayport Audio Warping
Summary: Radeon Displayport Audio Warping
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri
Depends on:
Reported: 2015-08-07 01:05 UTC by Maxqia
Modified: 2018-10-10 22:33 UTC (History)
4 users (show)

See Also:
Kernel Version: 4.2 RC5
Tree: Mainline
Regression: No

Patch (4.39 KB, patch)
2015-08-10 21:09 UTC, Maxqia
Details | Diff
dmesg log (174.00 KB, text/x-log)
2015-08-20 01:33 UTC, Maxqia
Possible Patch (1.46 KB, patch)
2015-08-21 00:28 UTC, Maxqia
Details | Diff
Updated Patch (1.41 KB, patch)
2015-08-21 23:44 UTC, Maxqia
Details | Diff
Explained Patch (4.37 KB, text/plain)
2016-09-18 03:47 UTC, Maxqia

Description Maxqia 2015-08-07 01:05:55 UTC
I'm having issues with Linux 4.2 RC5 with the Displayport audio being deeper then normal. Doesn't seem to happen with 4.1.3 with a backported patch from https://bugzilla.kernel.org/attachment.cgi?id=183611
Comment 1 Maxqia 2015-08-10 21:09:47 UTC
Created attachment 184611 [details]

Reverting Commit 7726e72b3d6879ee5fc743a230eb6f5afa12844b Seems to fix my issues.
Comment 2 Alex Deucher 2015-08-10 21:17:19 UTC
Are you sure that's the right commit?  That commit shouldn't have any affect on DP audio.  All it does is move the check for monitor audio support from radeon_atom_encoder_mode_set() into radeon_audio_mode_set().  It doesn't change the hw programming at all.
Comment 3 Maxqia 2015-08-10 22:47:03 UTC
Yes, I just double checked. With the commit, the displayport audio is warped.
Comment 4 Maxqia 2015-08-11 03:28:10 UTC
Huh seems to be the EDID detection. Windows/xrandr --verbose seem to get the EDID right but get-edid doesn't.
Comment 5 Maxqia 2015-08-17 08:47:19 UTC
Replacing drm_detect_monitor_audio(radeon_connector_edid(connector)) with true seems to fix the problem.
Comment 6 Alex Deucher 2015-08-19 18:00:42 UTC
(In reply to Maxqia from comment #5)
> Replacing drm_detect_monitor_audio(radeon_connector_edid(connector)) with
> true seems to fix the problem.

This means the EDID from your monitor claims not to support audio.
Comment 7 Maxqia 2015-08-20 01:33:04 UTC
Created attachment 185301 [details]
dmesg log
Comment 8 Maxqia 2015-08-20 01:34:46 UTC
It works with fglrx, also in the dmesg log it says "[drm:drm_detect_monitor_audio] Monitor has basic audio support"
Which is when it should output true
Comment 9 Maxqia 2015-08-21 00:28:13 UTC
Created attachment 185391 [details]
Possible Patch
Comment 10 Maxqia 2015-08-21 23:44:40 UTC
Created attachment 185441 [details]
Updated Patch
Comment 11 Maxqia 2015-09-17 03:23:43 UTC
Any Updates?
Comment 12 Alex Deucher 2015-09-23 15:42:05 UTC
I don't see what this patch changes.
Comment 13 Maxqia 2016-09-18 02:43:17 UTC
Looking back with an extra year of programming knowledge, it seems like commit 7726e72b3d6879ee5fc743a230eb6f5afa12844b doesn't do anything except add a drm_detect_monitor_audio to the hdmi audio pathway ..., before that commit only Displayport was checked for audio. Anyways, issue still present.
Comment 14 Maxqia 2016-09-18 03:47:35 UTC
Created attachment 238501 [details]
Explained Patch
Comment 15 Maxqia 2017-03-04 07:40:11 UTC
Comment on attachment 238501 [details]
Explained Patch

:/ I really don't know what I'm doing...
Commenting this if block fixes it...
That probably means that the thing setting the display clock frequency is broken in some way...
Comment 16 Vitor Antunes 2018-10-10 22:33:39 UTC
I'm having the same problem with my Tahiti GPU.
This output seems to confirm that there's an EDID issue:
> tail -n+1 /proc/asound/card*/eld*
edid_version		[0x0] no CEA EDID Timing Extension block present

These patches touch DCE6 and such: https://lists.freedesktop.org/archives/amd-gfx/2018-October/027462.html
Maybe it fixes this issue?

Don't have the availability to test at the moment.

Note You need to log in before you can comment on or make changes to this bug.