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

[Deucher, Alexander]

> -----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.

> 
> 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.

Alex

> 
> --
> David Henningsson, Canonical Ltd.
> https://launchpad.net/~diwic