With 2.6.33rc4, 2.6.33rc5 and drm-radeon-testing as of 24-jan-2010, HDMI audio does no longer work when the machine has resumed after suspend-to-ram.
To solve this problem it would be enough to just re-enable audio engine after resume (as GPU state is reseted). However this way we keep r600_audio_update_hdmi timer looping all the time, even before we manage to re-enable audio engine. This leads to following situation: [ 173.838067] [drm:r600_audio_bits_per_sample] *ERROR* Unknown bits per sample 0xf using 16 instead. [ 173.938064] [drm:r600_audio_bits_per_sample] *ERROR* Unknown bits per sample 0xf using 16 instead. [ 174.038012] [drm:r600_audio_bits_per_sample] *ERROR* Unknown bits per sample 0xf using 16 instead. [ 174.138013] [drm:r600_audio_bits_per_sample] *ERROR* Unknown bits per sample 0xf using 16 instead. [ 174.238011] [drm:r600_audio_bits_per_sample] *ERROR* Unknown bits per sample 0xf using 16 instead. [ 174.338024] [drm:r600_audio_bits_per_sample] *ERROR* Unknown bits per sample 0xf using 16 instead. [ 174.438024] [drm:r600_audio_bits_per_sample] *ERROR* Unknown bits per sample 0xf using 16 instead. [ 174.533109] [drm] Clocks initialized ! [ 174.570184] [drm] ring test succeeded in 1 usecs [ 174.570199] [drm] ib test succeeded in 0 usecs [ 174.570202] [drm] Enabling audio support So I believe we should completely stop our audio stuff for suspend and restart it on resume.
The fix posted here seems to fix the issue: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg46762.html
Patch applied in 2.6.33-rc8.
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.