R9270X - audio not perfect normally, but there is none at all after - bead330b1af6fce76aedac9f89d20edcaeae27b3 is the first bad commit commit bead330b1af6fce76aedac9f89d20edcaeae27b3 Author: Slava Grigorev <slava.grigorev@amd.com> Date: Tue Dec 2 15:22:43 2014 -0500 radeon/audio: consolidate audio_get_pin() functions There is also another minor issue on head, but I haven't had time to bisect and it doesn't always show. If I bring TV up after booting with TV off there are a few pix of pink on left of screen - doing anything that resets mode/on/off or if on from boot avoids. Didn't see it in the bisect - first was bad so I guess it's in the other half.
Are you sure that's the right commit? I don't see any functional change. It just switches a direct function call to a function pointer.
(In reply to Alex Deucher from comment #1) > Are you sure that's the right commit? I don't see any functional change. > It just switches a direct function call to a function pointer. Hmm, I just built a fresh kernel reset on that and testing in the same way as my normal use case (TV off at boot) it is a bad. There is a but though, in that it is possible to make it work by doing an extra off/on or TV on from boot. When I first noticed the issue on head I tried and failed to get sound doing the same sort of thing. Maybe some pot luck is involved, maybe there is more than one issue - all the goods during the bisect were just tested once with boot from TV off. So the bisect is suspect - I'll have to play around more when I have time.
(In reply to Andy Furniss from comment #2) > Maybe some pot luck is involved, maybe there is more than one issue - all > the goods during the bisect were just tested once with boot from TV off. Early testing - alternate booting a 10 times between "bad" kernel and a kernel on the commit before shows it's not pot luck. The kernel "before" always works and the one on the commit I bisected as bad always fails (TV off at boot) until it gets a prod via xrandr. Seems almost anything will do, though just xrandr alone won't but any of off then auto --set audio on --set dither on --mode 0x.. will get sound back. Also reconfirmed that the above tricks do not work on head.
Created attachment 112574 [details] [review] possible fix I think this should fix it.
(In reply to Alex Deucher from comment #4) > Created attachment 112574 [details] [review] [review] > possible fix > > I think this should fix it. Partially - on head still pink line and no sound, but off/auto now gets sound (and makes line disappear, but that happened without patch). Can't test on my bad as it doesn't apply when reset there. Will try a new bisect later.
(In reply to Andy Furniss from comment #5) Bisecting unpatched for still no sound after off/auto came up with - 4ee40262749f150fa3644884326602d8ef240a0a is the first bad commit commit 4ee40262749f150fa3644884326602d8ef240a0a Author: Slava Grigorev <slava.grigorev@amd.com> Date: Sat Dec 6 20:19:16 2014 -0500 radeon/audio: consolidate update_acr() functions Pink line will need its own bisect.
(In reply to Andy Furniss from comment #6) > (In reply to Andy Furniss from comment #5) > > Bisecting unpatched for still no sound after off/auto came up with - > > 4ee40262749f150fa3644884326602d8ef240a0a is the first bad commit > commit 4ee40262749f150fa3644884326602d8ef240a0a > Author: Slava Grigorev <slava.grigorev@amd.com> > Date: Sat Dec 6 20:19:16 2014 -0500 > > radeon/audio: consolidate update_acr() functions Ugh so this doesn't exist anymore as the repo has been updated.
(In reply to Andy Furniss from comment #7) > (In reply to Andy Furniss from comment #6) > > (In reply to Andy Furniss from comment #5) > > > > Bisecting unpatched for still no sound after off/auto came up with - > > > > 4ee40262749f150fa3644884326602d8ef240a0a is the first bad commit > > commit 4ee40262749f150fa3644884326602d8ef240a0a > > Author: Slava Grigorev <slava.grigorev@amd.com> > > Date: Sat Dec 6 20:19:16 2014 -0500 > > > > radeon/audio: consolidate update_acr() functions > > Ugh so this doesn't exist anymore as the repo has been updated. It's been updated with the patch since it was obviously wrong as is.
(In reply to Alex Deucher from comment #8) > (In reply to Andy Furniss from comment #7) > > (In reply to Andy Furniss from comment #6) > > > (In reply to Andy Furniss from comment #5) > > > > > > Bisecting unpatched for still no sound after off/auto came up with - > > > > > > 4ee40262749f150fa3644884326602d8ef240a0a is the first bad commit > > > commit 4ee40262749f150fa3644884326602d8ef240a0a > > > Author: Slava Grigorev <slava.grigorev@amd.com> > > > Date: Sat Dec 6 20:19:16 2014 -0500 > > > > > > radeon/audio: consolidate update_acr() functions > > > > Ugh so this doesn't exist anymore as the repo has been updated. > > It's been updated with the patch since it was obviously wrong as is. Yea - the ugh was because I didn't notice and I wouldn't have spent time doing that bisect if I had. But anyway on updated tree I bisected the pink line and came up with - 93f91b2e85a27f9260fb20498ad12a7b2cfa5762 is the first bad commit commit 93f91b2e85a27f9260fb20498ad12a7b2cfa5762 Author: Slava Grigorev <slava.grigorev@amd.com> Date: Mon Dec 8 18:28:33 2014 -0500 radeon/audio: set_avi_packet() function cleanup I didn't do another bisect on sound as I hit consolidate update_acr() functions v2 doing pink and it's bad for sound, so as nothing before that seems to have changed I think my first bisect is still valid for that.
(In reply to Alex Deucher from comment #1) > Are you sure that's the right commit? I don't see any functional change. > It just switches a direct function call to a function pointer. I played a bit more - trying to see if there was any real change or maybe some unlucky h/w timing/order issue. There is a functional change, I guess seeded in a preceding commit. Testing with debugging like - diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c b/drivers/gpu/drm/radeon/dce6_afmt.c index 96f298c..266f32a 100644 --- a/drivers/gpu/drm/radeon/dce6_afmt.c +++ b/drivers/gpu/drm/radeon/dce6_afmt.c @@ -75,6 +75,7 @@ struct r600_audio_pin *dce6_audio_get_pin(struct radeon_device *rdev) { int i; + DRM_ERROR("[ADF] in dce6_audio_get_pin\n"); dce6_afmt_get_connected_pins(rdev); for (i = 0; i < rdev->audio.num_pins; i++) { On the bad commit there is no output after doing xrandr --output HDMI-0 --auto on the commit before there is. On the bad I do get the output with a second use of xrandr.
Do the patches on bug 89327 help?
(In reply to Alex Deucher from comment #11) > Do the patches on bug 89327 help? No, also tested your audio-fixes branch but that doesn't fix either.
I've posted an updated audio-fixes branch that may help: http://cgit.freedesktop.org/~agd5f/linux/log/?h=audio-fixes
(In reply to Alex Deucher from comment #13) > I've posted an updated audio-fixes branch that may help: > http://cgit.freedesktop.org/~agd5f/linux/log/?h=audio-fixes Doesn't seem to change anything for me.
Updated patches here: http://cgit.freedesktop.org/~agd5f/linux/log/?h=audio-fixes
(In reply to Alex Deucher from comment #15) > Updated patches here: > http://cgit.freedesktop.org/~agd5f/linux/log/?h=audio-fixes Still doesn't fix pink line or no sound for me starting hdmi as second screen with xrandr from X already started.
Not sure if I'm seeing the same, but I have the HDMI/DP audio device available with 4.0-rcN, just get no sound through it. This worked with 3.19. Another datapoint is that pulling most of core drm changes from 4.0-rc1 (for SKL backport) also broke it, so that the HDMI audio device isn't even available.
I don't have the h/w to test this anymore. Since drm/radeon: rework audio detect (v4) Similar bug reports seem to be fixed now so closing.
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.