Bug 67767

Summary: no HDMI audio, no display with radeon.audio=1
Product: xorg Reporter: willem
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: medium CC: willem
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
avivotool regs hdmi output when failure happens none

Description willem 2013-08-05 05:48:35 UTC 
I am running Archlinux (kernel 3.10.3) with ati driver 1:7.1, on an ASRock E350M1 Mini ITX board that has a Radeon HD 6310 on-board. (From the evergreen family, feature matrix shows "DONE" at HDMI audio). Further specs:

processor: AMD Fusion E-350
chipset: AMD A50M (Hudson-M1)

Attached to the board is my TV set, via HDMI.

Vanilla install works fine, except: no audio via HDMI.

The standard alsa device is configured as card 0, device 0. But poking around (aplay -l, cat /proc/asound/cards) shows me this should be card 0, device 3. That's something that needs fixing. But

mplayer -ao alsa:device=hw=0.3 <some file>

returns no errors but I hear no sound...

Reading the (excellent) arch wiki (https://wiki.archlinux.org/index.php/Radeon#HDMI_audio) I was recommended to add radeon.audio=1 to my kernel parameters. Without it, I see that I /sys/.../parameters/audio = 0. Setting the kernel parameter does flip this parameter into 1...

But: as soon as the kernel loads with this parameter set, the screen goes blank with no signal detected by my TV. The system continues booting as per normal. Logging in through ssh and trying to play the same audio file: still no sound from my TV set. Switching the TV off and back on or unplugging and plugging back in (all this while mplayer runs), still no sound.

Just for fun: also setting radeon.tv=0 as kernel parameter does not help. Same thing...

When I run mplayer, nothing awkward shows up in journalctl -f

Any clue as to what to try next?
Comment 1 Rafał Miłecki 2013-08-05 07:14:19 UTC 
Is this a regression from 3.9 maybe? We have some similar report:
https://bugzilla.kernel.org/show_bug.cgi?id=60687

Could you try using audio=1, wait for blank screen and execute:
avivotools regs hdmi
? I hope Arch provides that tool, in case it doesn't, there is URL:
http://cgit.freedesktop.org/~airlied/radeontool
Comment 2 willem 2013-08-05 08:01:30 UTC 
Yes, archlinux has radeontool in it's repository ;-)

The result is attached.
Comment 3 willem 2013-08-05 08:02:17 UTC 
Created attachment 83643 [details]
avivotool regs hdmi output when failure happens
Comment 4 Rafał Miłecki 2013-08-06 14:57:29 UTC 
@Willem: after connecting your HDMI display (and experiencing failure) please call:
avivotool regset 0x7044 0x00000033

I'm 99% sure it'll solve your problem, so you can use it as a temporary workaround.

I'll work on the real fix.
Comment 5 willem 2013-08-06 22:35:14 UTC 
(In reply to comment #4)
> @Willem: after connecting your HDMI display (and experiencing failure)
> please call:
> avivotool regset 0x7044 0x00000033
> 
> I'm 99% sure it'll solve your problem, so you can use it as a temporary
> workaround.
> 
> I'll work on the real fix.

Works like magic! Thanks...
Comment 6 Rafał Miłecki 2013-08-15 16:57:18 UTC 
Fix posted:
[FIX][PATCH] drm/radeon: fix WREG32_OR macro setting bits in a register
http://lists.freedesktop.org/archives/dri-devel/2013-August/043835.html
Comment 7 Simon Putt 2013-09-19 13:40:03 UTC 
This is still a problem on my Turks (6670) card, running kernel 3.11.1 (fedora version)
Comment 8 Martin Peres 2019-11-19 07:42:06 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/75.

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.