[alsa-devel] Radeon unconnected HDMI eats samples at 280 kHz

[Deucher, Alexander]

> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson at canonical.com]
> Sent: Tuesday, September 23, 2014 5:48 AM
> To: Deucher, Alexander; Takashi Iwai
> Cc: Anssi Hannula; alsa-devel at alsa-project.org
> Subject: Re: [alsa-devel] Radeon unconnected HDMI eats samples at 280 kHz
> 
> 
> 
> On 2014-09-22 16:52, Deucher, Alexander wrote:
> >> -----Original Message-----
> >> From: David Henningsson [mailto:david.henningsson at canonical.com]
> >> Sent: Monday, September 22, 2014 10:39 AM
> >> To: Deucher, Alexander; Takashi Iwai
> >> Cc: Anssi Hannula; alsa-devel at alsa-project.org
> >> Subject: Re: [alsa-devel] Radeon unconnected HDMI eats samples at 280
> kHz
> >>
> >> On 2014-09-22 14:46, Deucher, Alexander wrote:
> >>>> -----Original Message-----
> >>>> From: David Henningsson [mailto:david.henningsson at canonical.com]
> >>>> Sent: Friday, September 19, 2014 8:07 PM
> >>>> To: Deucher, Alexander; Takashi Iwai
> >>>> Cc: Anssi Hannula; alsa-devel at alsa-project.org
> >>>> Subject: Re: [alsa-devel] Radeon unconnected HDMI eats samples at
> 280
> >> kHz
> >>>>
> >>>> Btw, is there a register dump utility I could use to get the current
> >>>> register value, e g by reading sysfs or procfs? It could be interesting
> >>>> to see if anything we do on the audio side would affect this register.
> >>>
> >>> You can use the radeonreg tool to dump registers:
> >>> http://cgit.freedesktop.org/~airlied/radeontool
> >>
> >> Thanks, I have now tried this, together with the kernel from
> >> drm-next-3.18-wip.
> >>
> >>   From your patches it looks like I should look at the dumped register
> >> 0x7300, is that correct?
> >
> > What GPU do you have?  The offset of that register varies between
> generations.
> 
> Not sure exactly what GPU info you need, but here's the lspci info:
> 
> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
> [AMD/ATI] RV710 [Radeon HD 4550] [1002:9540] (prog-if 00 [VGA controller])
>          Subsystem: PC Partner Limited / Sapphire Technology Device
> [174b:e106]
> 

That's an R7xx, so 0x7300 is correct.

> >> At boot up, this register is 001000f0. (Out of curiousity, I tried
> >> disabling unsol events from the audio side, but this did not change the
> >> register.)
> >> After HDMI plug in, the register changed to 0x8f1000f0, the jack
> >> reported being plugged in, and audio worked.
> >>
> >> After HDMI unplugged again, the register remained at 0x8f1000f0, and
> >> "xrandr --output HDMI-0 --off" did not help.
> >>
> >> However, when looking at your code, I also spotted something in the
> >> patch called "disable audio when we disable hdmi":
> >>
> >> if (!enable && dig->afmt->pin) {
> >>       r600_audio_enable(rdev, dig->afmt->pin, 0xf);
> >>                                               ^^^
> >> If enable is false, should we not set the last parameter to 0 instead of
> >> 0xf?
> >
> > Yup.  Good catch.  I've fixed that up and pushed a new drm-next-3.18-wip
> branch.
> 
> Ok, I have tested this now, with mixed results. One time when I
> unplugged I believe it correctly switched back to unplugged on the audio
> side (after running "xrandr", with no parameters). But the next time it
> did not.
> 

Like I said, it's not tied to the physical unplug event.  You have to actually turn off the display with xrandr either explicitly or by your desktop environment as a response to a hotplug event.

> So far, it looks like whenever the audio side reports presence, the
> 0x7300 register is set to 0x8f1000f0. So as long as we can get the video
> side to correctly turn off the right bits of that register when the
> monitor is disabled/disconnected, things should be working on the audio
> side.

Can you confirm the value of 0x7300 matches what you expect in the audio driver?  E.g., does setting/clearing the appropriate bits reflect properly on the audio side?  I think the only bit that may matter is bit 31 (AUDIO_ENABLED).

Alex