Radeon unconnected HDMI eats samples at 280 kHz

Radeon unconnected HDMI eats samples at 280 kHz

[David Henningsson]

Hi,

While investigating some interesting debug output from PulseAudio, I 
tried to figure out the cause.

 From what I can tell, my Radeon seems to ask for new samples at a very 
high rate, which I estimate to be around 280 kHz. My radeon card has 
DVI, HDMI and VGA connectors, and the only thing connected is my screen 
over DVI.

I'm currently running the 3.13 kernel with updated hda directory from 
Takashi's tree, but I think it's been this way for a long time.

Note that if a screen is connected to the HDMI card, the problem 
disappears and sample rates are normal.
In short, do you think this is a driver bug, or just something we have 
to live with as some sort of hw anomaly?
Since nothing is connected, it does not really hurt, except PulseAudio 
gets confused (in a way that could potentially cause problems for 
low-latency output, should something be connected later on).

For reference, here's lspci of the HDMI card:

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]
01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] 
RV710/730 HDMI Audio [Radeon HD 4000 series] [1002:aa38]
	Subsystem: PC Partner Limited / Sapphire Technology Device [174b:aa38]


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

Re: Radeon unconnected HDMI eats samples at 280 kHz

[Anssi Hannula]

17.09.2014, 16:40, David Henningsson kirjoitti:
> Hi,

Hi,

> While investigating some interesting debug output from PulseAudio, I 
> tried to figure out the cause.
> 
>  From what I can tell, my Radeon seems to ask for new samples at a very 
> high rate, which I estimate to be around 280 kHz. My radeon card has 
> DVI, HDMI and VGA connectors, and the only thing connected is my screen 
> over DVI.
> 
> I'm currently running the 3.13 kernel with updated hda directory from 
> Takashi's tree, but I think it's been this way for a long time.
> 
> Note that if a screen is connected to the HDMI card, the problem 
> disappears and sample rates are normal.
> In short, do you think this is a driver bug, or just something we have 
> to live with as some sort of hw anomaly?
> Since nothing is connected, it does not really hurt, except PulseAudio 
> gets confused (in a way that could potentially cause problems for 
> low-latency output, should something be connected later on).

Not sure.
IIRC, unlike the other gpus, on radeon the video driver needs to
"manually" set sample rate dividers/etc based on the pixel clock rate,
so I guess this might mean we can't have a proper audio clock without
enabled video...

Alex, any thoughts/info?


If this is the case, it would probably be best if we prevented opening
the device when output is not active (unless this causes some other
issues), but I guess there is currently no easy way for the _audio_
driver to know that...


> For reference, here's lspci of the HDMI card:
> 
> 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]
> 01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] 
> RV710/730 HDMI Audio [Radeon HD 4000 series] [1002:aa38]
> 	Subsystem: PC Partner Limited / Sapphire Technology Device [174b:aa38]
> 
> 


-- 
Anssi Hannula

Re: Radeon unconnected HDMI eats samples at 280 kHz

[David Henningsson]

[-- Attachment #1: Type: text/plain, Size: 2252 bytes --]



On 2014-09-17 23:26, Anssi Hannula wrote:
> 17.09.2014, 16:40, David Henningsson kirjoitti:
>> Hi,
>
> Hi,
>
>> While investigating some interesting debug output from PulseAudio, I
>> tried to figure out the cause.
>>
>>   From what I can tell, my Radeon seems to ask for new samples at a very
>> high rate, which I estimate to be around 280 kHz. My radeon card has
>> DVI, HDMI and VGA connectors, and the only thing connected is my screen
>> over DVI.
>>
>> I'm currently running the 3.13 kernel with updated hda directory from
>> Takashi's tree, but I think it's been this way for a long time.
>>
>> Note that if a screen is connected to the HDMI card, the problem
>> disappears and sample rates are normal.
>> In short, do you think this is a driver bug, or just something we have
>> to live with as some sort of hw anomaly?
>> Since nothing is connected, it does not really hurt, except PulseAudio
>> gets confused (in a way that could potentially cause problems for
>> low-latency output, should something be connected later on).
>
> Not sure.
> IIRC, unlike the other gpus, on radeon the video driver needs to
> "manually" set sample rate dividers/etc based on the pixel clock rate,
> so I guess this might mean we can't have a proper audio clock without
> enabled video...
>
> Alex, any thoughts/info?
>
>
> If this is the case, it would probably be best if we prevented opening
> the device when output is not active (unless this causes some other
> issues), but I guess there is currently no easy way for the _audio_
> driver to know that...

Well, if jack detection (get pin sense) works, there is. There are two 
major problems with that though:

1) When I look right here and now, it seems like jack detection returns 
"plugged in" status, and ELD info reports monitor_present=1, 
eld_valid=0. So pin sense isn't really working (or maybe it reports that 
my DVI monitor is plugged in, which isn't helpful here). I'm attaching 
codec proc info in case it's helpful.

2) It requires major work in PulseAudio to make sure we re-probe the 
HDMI device when it is plugged in. We should do that anyway, it's just 
that it is quite some work to do, and noone has done it yet.

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

[-- Attachment #2: codec.txt --]
[-- Type: text/plain, Size: 1236 bytes --]

Codec: ATI R6xx HDMI
Address: 0
AFG Function Id: 0x1 (unsol 0)
Vendor Id: 0x1002aa01
Subsystem Id: 0x00aa0100
Revision Id: 0x100100
No Modem Function Group found
Default PCM:
    rates [0x70]: 32000 44100 48000
    bits [0x2]: 16
    formats [0x1]: PCM
Default Amp-In caps: N/A
Default Amp-Out caps: N/A
State of AFG node 0x01:
  Power states:  D0 D3
  Power: setting=D0, actual=D0
GPIO: io=0, o=0, i=0, unsolicited=0, wake=0
Node 0x02 [Audio Output] wcaps 0x201: Stereo Digital
  Converter: stream=1, channel=0
  Digital: Enabled GenLevel
  Digital category: 0x2
  IEC Coding Type: 0x0
Node 0x03 [Pin Complex] wcaps 0x400381: Stereo Digital
  Control: name="HDMI/DP,pcm=3 Jack", index=0, device=0
  Control: name="IEC958 Playback Con Mask", index=0, device=0
  Control: name="IEC958 Playback Pro Mask", index=0, device=0
  Control: name="IEC958 Playback Default", index=0, device=0
  Control: name="IEC958 Playback Switch", index=0, device=0
  Control: name="ELD", index=0, device=3
  Pincap 0x00000094: OUT Detect HDMI
  Pin Default 0x18560010: [Jack] Digital Out at Int HDMI
    Conn = Digital, Color = Unknown
    DefAssociation = 0x1, Sequence = 0x0
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=01, enabled=1
  Connection: 1
     0x02

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: Radeon unconnected HDMI eats samples at 280 kHz

[Takashi Iwai]

At Thu, 18 Sep 2014 06:13:01 +0200,
David Henningsson wrote:
> 
> 
> 
> On 2014-09-17 23:26, Anssi Hannula wrote:
> > 17.09.2014, 16:40, David Henningsson kirjoitti:
> >> Hi,
> >
> > Hi,
> >
> >> While investigating some interesting debug output from PulseAudio, I
> >> tried to figure out the cause.
> >>
> >>   From what I can tell, my Radeon seems to ask for new samples at a very
> >> high rate, which I estimate to be around 280 kHz. My radeon card has
> >> DVI, HDMI and VGA connectors, and the only thing connected is my screen
> >> over DVI.
> >>
> >> I'm currently running the 3.13 kernel with updated hda directory from
> >> Takashi's tree, but I think it's been this way for a long time.
> >>
> >> Note that if a screen is connected to the HDMI card, the problem
> >> disappears and sample rates are normal.
> >> In short, do you think this is a driver bug, or just something we have
> >> to live with as some sort of hw anomaly?
> >> Since nothing is connected, it does not really hurt, except PulseAudio
> >> gets confused (in a way that could potentially cause problems for
> >> low-latency output, should something be connected later on).
> >
> > Not sure.
> > IIRC, unlike the other gpus, on radeon the video driver needs to
> > "manually" set sample rate dividers/etc based on the pixel clock rate,
> > so I guess this might mean we can't have a proper audio clock without
> > enabled video...
> >
> > Alex, any thoughts/info?
> >
> >
> > If this is the case, it would probably be best if we prevented opening
> > the device when output is not active (unless this causes some other
> > issues), but I guess there is currently no easy way for the _audio_
> > driver to know that...
> 
> Well, if jack detection (get pin sense) works, there is.

Does it react if we turn off the HDMI output via xrandr, too?
I'm not sure whether we need reprogram things in that case, though...

> There are two 
> major problems with that though:
> 
> 1) When I look right here and now, it seems like jack detection returns 
> "plugged in" status, and ELD info reports monitor_present=1, 
> eld_valid=0. So pin sense isn't really working (or maybe it reports that 
> my DVI monitor is plugged in, which isn't helpful here). I'm attaching 
> codec proc info in case it's helpful.
>
> 2) It requires major work in PulseAudio to make sure we re-probe the 
> HDMI device when it is plugged in. We should do that anyway, it's just 
> that it is quite some work to do, and noone has done it yet.

Would it make easier if we create/delete HDMI PCM on the fly?  Or it's
rather confusing?


Takashi

Re: Radeon unconnected HDMI eats samples at 280 kHz

[David Henningsson]

On 2014-09-18 09:33, Takashi Iwai wrote:
> At Thu, 18 Sep 2014 06:13:01 +0200,
> David Henningsson wrote:
>>
>>
>>
>> On 2014-09-17 23:26, Anssi Hannula wrote:
>>> 17.09.2014, 16:40, David Henningsson kirjoitti:
>>>> Hi,
>>>
>>> Hi,
>>>
>>>> While investigating some interesting debug output from PulseAudio, I
>>>> tried to figure out the cause.
>>>>
>>>>    From what I can tell, my Radeon seems to ask for new samples at a very
>>>> high rate, which I estimate to be around 280 kHz. My radeon card has
>>>> DVI, HDMI and VGA connectors, and the only thing connected is my screen
>>>> over DVI.
>>>>
>>>> I'm currently running the 3.13 kernel with updated hda directory from
>>>> Takashi's tree, but I think it's been this way for a long time.
>>>>
>>>> Note that if a screen is connected to the HDMI card, the problem
>>>> disappears and sample rates are normal.
>>>> In short, do you think this is a driver bug, or just something we have
>>>> to live with as some sort of hw anomaly?
>>>> Since nothing is connected, it does not really hurt, except PulseAudio
>>>> gets confused (in a way that could potentially cause problems for
>>>> low-latency output, should something be connected later on).
>>>
>>> Not sure.
>>> IIRC, unlike the other gpus, on radeon the video driver needs to
>>> "manually" set sample rate dividers/etc based on the pixel clock rate,
>>> so I guess this might mean we can't have a proper audio clock without
>>> enabled video...
>>>
>>> Alex, any thoughts/info?
>>>
>>>
>>> If this is the case, it would probably be best if we prevented opening
>>> the device when output is not active (unless this causes some other
>>> issues), but I guess there is currently no easy way for the _audio_
>>> driver to know that...
>>
>> Well, if jack detection (get pin sense) works, there is.
>
> Does it react if we turn off the HDMI output via xrandr, too?
> I'm not sure whether we need reprogram things in that case, though...

xrandr correctly reports that "HDMI-0" is disconnected.

I'm not sure how to turn the HDMI output via xrandr, but I tried "xrandr 
--output HDMI-0 --off" and it made no difference in either xrandr 
output, nor in codec/eld output.

What I'm thinking is that it could be that the monitor_present is 
indicating the presence of my DVI monitor, as some cards are capable of 
outputting HDMI audio on their DVI outputs (through a passive DVI->HDMI 
adapter). This is just a guess though.

>> There are two
>> major problems with that though:
>>
>> 1) When I look right here and now, it seems like jack detection returns
>> "plugged in" status, and ELD info reports monitor_present=1,
>> eld_valid=0. So pin sense isn't really working (or maybe it reports that
>> my DVI monitor is plugged in, which isn't helpful here). I'm attaching
>> codec proc info in case it's helpful.
>>
>> 2) It requires major work in PulseAudio to make sure we re-probe the
>> HDMI device when it is plugged in. We should do that anyway, it's just
>> that it is quite some work to do, and noone has done it yet.
>
> Would it make easier if we create/delete HDMI PCM on the fly?  Or it's
> rather confusing?

I don't think that would make it any easier for PulseAudio, if anything 
it would be more complicated - we would then have to listen to PCM 
devices appearing and disappearing and reprobe, instead of listening to 
jack detection events and reprobe based on that.

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

Re: Radeon unconnected HDMI eats samples at 280 kHz

[Deucher, Alexander]

> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson@canonical.com]
> Sent: Thursday, September 18, 2014 3:54 AM
> To: Takashi Iwai
> Cc: Anssi Hannula; Deucher, Alexander; alsa-devel@alsa-project.org
> Subject: Re: [alsa-devel] Radeon unconnected HDMI eats samples at 280 kHz
> 
> 
> 
> On 2014-09-18 09:33, Takashi Iwai wrote:
> > At Thu, 18 Sep 2014 06:13:01 +0200,
> > David Henningsson wrote:
> >>
> >>
> >>
> >> On 2014-09-17 23:26, Anssi Hannula wrote:
> >>> 17.09.2014, 16:40, David Henningsson kirjoitti:
> >>>> Hi,
> >>>
> >>> Hi,
> >>>
> >>>> While investigating some interesting debug output from PulseAudio, I
> >>>> tried to figure out the cause.
> >>>>
> >>>>    From what I can tell, my Radeon seems to ask for new samples at a
> very
> >>>> high rate, which I estimate to be around 280 kHz. My radeon card has
> >>>> DVI, HDMI and VGA connectors, and the only thing connected is my
> screen
> >>>> over DVI.
> >>>>
> >>>> I'm currently running the 3.13 kernel with updated hda directory from
> >>>> Takashi's tree, but I think it's been this way for a long time.
> >>>>
> >>>> Note that if a screen is connected to the HDMI card, the problem
> >>>> disappears and sample rates are normal.
> >>>> In short, do you think this is a driver bug, or just something we have
> >>>> to live with as some sort of hw anomaly?
> >>>> Since nothing is connected, it does not really hurt, except PulseAudio
> >>>> gets confused (in a way that could potentially cause problems for
> >>>> low-latency output, should something be connected later on).
> >>>
> >>> Not sure.
> >>> IIRC, unlike the other gpus, on radeon the video driver needs to
> >>> "manually" set sample rate dividers/etc based on the pixel clock rate,
> >>> so I guess this might mean we can't have a proper audio clock without
> >>> enabled video...
> >>>
> >>> Alex, any thoughts/info?
> >>>
> >>>
> >>> If this is the case, it would probably be best if we prevented opening
> >>> the device when output is not active (unless this causes some other
> >>> issues), but I guess there is currently no easy way for the _audio_
> >>> driver to know that...
> >>
> >> Well, if jack detection (get pin sense) works, there is.
> >
> > Does it react if we turn off the HDMI output via xrandr, too?
> > I'm not sure whether we need reprogram things in that case, though...
> 
> xrandr correctly reports that "HDMI-0" is disconnected.
> 
> I'm not sure how to turn the HDMI output via xrandr, but I tried "xrandr
> --output HDMI-0 --off" and it made no difference in either xrandr
> output, nor in codec/eld output.
> 
> What I'm thinking is that it could be that the monitor_present is
> indicating the presence of my DVI monitor, as some cards are capable of
> outputting HDMI audio on their DVI outputs (through a passive DVI->HDMI
> adapter). This is just a guess though.

I'm not that familiar with the audio side, but on there are registers on the gpu side that will change what is reported to the audio side as far as I can tell.  You might try the new hdmi patches I sent out today:
http://lists.freedesktop.org/archives/dri-devel/2014-September/068544.html
patch 5/5 is probably the most relevant for this discussion.  It explicitly clears the audio enable bit when the display is disabled which should cascade down to the audio side if I understand correctly.  If not, I think playing with the AZ_HOT_PLUG_CONTROL registers in that patch set can probably sort it out.  I'm just not familiar enough with the azalia hw to know exactly how it's supposed to interact with the audio side.

Alex

> 
> >> There are two
> >> major problems with that though:
> >>
> >> 1) When I look right here and now, it seems like jack detection returns
> >> "plugged in" status, and ELD info reports monitor_present=1,
> >> eld_valid=0. So pin sense isn't really working (or maybe it reports that
> >> my DVI monitor is plugged in, which isn't helpful here). I'm attaching
> >> codec proc info in case it's helpful.
> >>
> >> 2) It requires major work in PulseAudio to make sure we re-probe the
> >> HDMI device when it is plugged in. We should do that anyway, it's just
> >> that it is quite some work to do, and noone has done it yet.
> >
> > Would it make easier if we create/delete HDMI PCM on the fly?  Or it's
> > rather confusing?
> 
> I don't think that would make it any easier for PulseAudio, if anything
> it would be more complicated - we would then have to listen to PCM
> devices appearing and disappearing and reprobe, instead of listening to
> jack detection events and reprobe based on that.
> 
> --
> David Henningsson, Canonical Ltd.
> https://launchpad.net/~diwic

Re: Radeon unconnected HDMI eats samples at 280 kHz

[David Henningsson]

[-- Attachment #1: Type: text/plain, Size: 2754 bytes --]

On 2014-09-19 00:29, Deucher, Alexander wrote:
>>>> Well, if jack detection (get pin sense) works, there is.
>>>
>>> Does it react if we turn off the HDMI output via xrandr, too?
>>> I'm not sure whether we need reprogram things in that case, though...
>>
>> xrandr correctly reports that "HDMI-0" is disconnected.
>>
>> I'm not sure how to turn the HDMI output via xrandr, but I tried "xrandr
>> --output HDMI-0 --off" and it made no difference in either xrandr
>> output, nor in codec/eld output.
>>
>> What I'm thinking is that it could be that the monitor_present is
>> indicating the presence of my DVI monitor, as some cards are capable of
>> outputting HDMI audio on their DVI outputs (through a passive DVI->HDMI
>> adapter). This is just a guess though.
>
> I'm not that familiar with the audio side, but on there are registers on the gpu side that will change what is reported to the audio side as far as I can tell.  You might try the new hdmi patches I sent out today:
> http://lists.freedesktop.org/archives/dri-devel/2014-September/068544.html
> patch 5/5 is probably the most relevant for this discussion.  It explicitly clears the audio enable bit when the display is disabled which should cascade down to the audio side if I understand correctly.  If not, I think playing with the AZ_HOT_PLUG_CONTROL registers in that patch set can probably sort it out.

Thanks for the attention and the patches!

I compiled a 3.17-rc4 kernel plus the five patches. (I usually run the 
Ubuntu 3.13 kernel).

With this I saw that the jack reported "unplugged" when booting without 
an HDMI monitor, and that when the HDMI monitor was connected and got 
video output, the jack was now reported to be plugged in.
However, when I unplugged the monitor, the jack was still reported to be 
plugged in.

I also tried running a get_pin_sense verb manually and it still reported 
to be plugged in.

Also, I think it was the third time I plugged the monitor in, I got some 
type of GPU hang (see attached log). It never recovered by itself so I 
had to use SysRq to reboot the computer.

> I'm just not familiar enough with the azalia hw to know exactly how it's supposed to interact with the audio side.

Well, feel free to ask questions if you think we can answer them :-)

The bits that say PIN*_JACK_DETECTION_ENABLE and 
PIN*_UNSOLICITED_RESPONSE_ENABLE sounds like things that should be 
turned on all the time so we can properly get unsol jack detection 
events when the monitor is plugged or unplugged. Unless the 
PIN*_JACK_DETECTION_ENABLE actually represents the current state rather 
than the detection capability. But that's just guesses, as I assume the 
specs are not released?


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

[-- Attachment #2: gpu-hang.txt --]
[-- Type: text/plain, Size: 10611 bytes --]

Sep 19 14:56:23 david-desktop colord: Automatic metadata add icc-0bd271b6f2ece9bf0a1fe82805c29d74 to xrandr-CVTE TV
Sep 19 14:56:23 david-desktop colord: Device added: xrandr-CVTE TV
Sep 19 14:57:11 david-desktop kernel: [  162.034771] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 130
Sep 19 14:57:11 david-desktop kernel: [  162.034780] Raw EDID:
Sep 19 14:57:11 david-desktop kernel: [  162.034786]  	00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
Sep 19 14:57:11 david-desktop kernel: [  162.034790]  	ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Sep 19 14:57:11 david-desktop kernel: [  162.034794]  	ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Sep 19 14:57:11 david-desktop kernel: [  162.034798]  	ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Sep 19 14:57:11 david-desktop kernel: [  162.034801]  	ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Sep 19 14:57:11 david-desktop kernel: [  162.034804]  	ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Sep 19 14:57:11 david-desktop kernel: [  162.034808]  	ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Sep 19 14:57:11 david-desktop kernel: [  162.034811]  	ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Sep 19 14:57:11 david-desktop kernel: [  162.035933] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID
Sep 19 14:58:14 david-desktop kernel: [  224.787757] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 136
Sep 19 14:58:22 david-desktop colord: device removed: xrandr-CVTE TV
Sep 19 15:14:14 david-desktop colord: Automatic metadata add icc-0bd271b6f2ece9bf0a1fe82805c29d74 to xrandr-CVTE TV
Sep 19 15:14:14 david-desktop colord: Device added: xrandr-CVTE TV
Sep 19 15:14:24 david-desktop kernel: [ 1194.816168] radeon 0000:01:00.0: ring 0 stalled for more than 10052msec
Sep 19 15:14:24 david-desktop kernel: [ 1194.816184] radeon 0000:01:00.0: GPU lockup (waiting for 0x0000000000006f5b last fence id 0x0000000000006f51 on ring 0)
Sep 19 15:14:24 david-desktop kernel: [ 1194.816191] radeon 0000:01:00.0: ring 0 stalled for more than 10052msec
Sep 19 15:14:24 david-desktop kernel: [ 1194.816200] radeon 0000:01:00.0: GPU lockup (waiting for 0x0000000000006f5b last fence id 0x0000000000006f51 on ring 0)
Sep 19 15:14:24 david-desktop kernel: [ 1194.839669] radeon 0000:01:00.0: Saved 1145 dwords of commands on ring 0.
Sep 19 15:14:24 david-desktop kernel: [ 1194.839688] radeon 0000:01:00.0: GPU softreset: 0x00000008
Sep 19 15:14:24 david-desktop kernel: [ 1194.839696] radeon 0000:01:00.0:   R_008010_GRBM_STATUS      = 0xA0003028
Sep 19 15:14:24 david-desktop kernel: [ 1194.839702] radeon 0000:01:00.0:   R_008014_GRBM_STATUS2     = 0x00000002
Sep 19 15:14:24 david-desktop kernel: [ 1194.839708] radeon 0000:01:00.0:   R_000E50_SRBM_STATUS      = 0x200000C0
Sep 19 15:14:24 david-desktop kernel: [ 1194.839713] radeon 0000:01:00.0:   R_008674_CP_STALLED_STAT1 = 0x00000000
Sep 19 15:14:24 david-desktop kernel: [ 1194.839718] radeon 0000:01:00.0:   R_008678_CP_STALLED_STAT2 = 0x00010002
Sep 19 15:14:24 david-desktop kernel: [ 1194.839723] radeon 0000:01:00.0:   R_00867C_CP_BUSY_STAT     = 0x00020182
Sep 19 15:14:24 david-desktop kernel: [ 1194.839729] radeon 0000:01:00.0:   R_008680_CP_STAT          = 0x80038647
Sep 19 15:14:24 david-desktop kernel: [ 1194.839734] radeon 0000:01:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
Sep 19 15:14:25 david-desktop kernel: [ 1194.916762] radeon 0000:01:00.0: R_008020_GRBM_SOFT_RESET=0x00004001
Sep 19 15:14:25 david-desktop kernel: [ 1194.916819] radeon 0000:01:00.0: SRBM_SOFT_RESET=0x00000100
Sep 19 15:14:25 david-desktop kernel: [ 1194.918911] radeon 0000:01:00.0:   R_008010_GRBM_STATUS      = 0x00003028
Sep 19 15:14:25 david-desktop kernel: [ 1194.918917] radeon 0000:01:00.0:   R_008014_GRBM_STATUS2     = 0x00000002
Sep 19 15:14:25 david-desktop kernel: [ 1194.918922] radeon 0000:01:00.0:   R_000E50_SRBM_STATUS      = 0x200000C0
Sep 19 15:14:25 david-desktop kernel: [ 1194.918927] radeon 0000:01:00.0:   R_008674_CP_STALLED_STAT1 = 0x00000000
Sep 19 15:14:25 david-desktop kernel: [ 1194.918932] radeon 0000:01:00.0:   R_008678_CP_STALLED_STAT2 = 0x00000000
Sep 19 15:14:25 david-desktop kernel: [ 1194.918938] radeon 0000:01:00.0:   R_00867C_CP_BUSY_STAT     = 0x00000000
Sep 19 15:14:25 david-desktop kernel: [ 1194.918943] radeon 0000:01:00.0:   R_008680_CP_STAT          = 0x00000000
Sep 19 15:14:25 david-desktop kernel: [ 1194.918948] radeon 0000:01:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
Sep 19 15:14:25 david-desktop kernel: [ 1194.918960] radeon 0000:01:00.0: GPU reset succeeded, trying to resume
Sep 19 15:14:25 david-desktop kernel: [ 1194.935955] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
Sep 19 15:14:25 david-desktop kernel: [ 1194.937152] [drm] PCIE GART of 1024M enabled (table at 0x000000000025D000).
Sep 19 15:14:25 david-desktop kernel: [ 1194.937170] radeon 0000:01:00.0: WB enabled
Sep 19 15:14:25 david-desktop kernel: [ 1194.937175] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff880035a88c00
Sep 19 15:14:25 david-desktop kernel: [ 1194.937179] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0xffff880035a88c0c
Sep 19 15:14:25 david-desktop kernel: [ 1194.937606] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x000000000005c598 and cpu addr 0xffffc90010c9c598
Sep 19 15:14:25 david-desktop kernel: [ 1194.983369] [drm] ring test on 0 succeeded in 1 usecs
Sep 19 15:14:25 david-desktop kernel: [ 1194.983434] [drm] ring test on 3 succeeded in 1 usecs
Sep 19 15:14:25 david-desktop kernel: [ 1195.168039] [drm] ring test on 5 succeeded in 1 usecs
Sep 19 15:14:25 david-desktop kernel: [ 1195.168064] [drm] UVD initialized successfully.
Sep 19 15:14:35 david-desktop kernel: [ 1205.166422] radeon 0000:01:00.0: ring 0 stalled for more than 10000msec
Sep 19 15:14:35 david-desktop kernel: [ 1205.166435] radeon 0000:01:00.0: GPU lockup (waiting for 0x0000000000006f75 last fence id 0x0000000000006f51 on ring 0)
Sep 19 15:14:35 david-desktop kernel: [ 1205.166451] [drm:r600_ib_test] *ERROR* radeon: fence wait failed (-35).
Sep 19 15:14:35 david-desktop kernel: [ 1205.166460] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on GFX ring (-35).
Sep 19 15:14:35 david-desktop kernel: [ 1205.166466] radeon 0000:01:00.0: ib ring test failed (-35).
Sep 19 15:14:35 david-desktop kernel: [ 1205.188427] radeon 0000:01:00.0: GPU softreset: 0x00000008
Sep 19 15:14:35 david-desktop kernel: [ 1205.188438] radeon 0000:01:00.0:   R_008010_GRBM_STATUS      = 0xA0003028
Sep 19 15:14:35 david-desktop kernel: [ 1205.188444] radeon 0000:01:00.0:   R_008014_GRBM_STATUS2     = 0x00000002
Sep 19 15:14:35 david-desktop kernel: [ 1205.188450] radeon 0000:01:00.0:   R_000E50_SRBM_STATUS      = 0x200000C0
Sep 19 15:14:35 david-desktop kernel: [ 1205.188455] radeon 0000:01:00.0:   R_008674_CP_STALLED_STAT1 = 0x00000000
Sep 19 15:14:35 david-desktop kernel: [ 1205.188460] radeon 0000:01:00.0:   R_008678_CP_STALLED_STAT2 = 0x00010002
Sep 19 15:14:35 david-desktop kernel: [ 1205.188465] radeon 0000:01:00.0:   R_00867C_CP_BUSY_STAT     = 0x00000002
Sep 19 15:14:35 david-desktop kernel: [ 1205.188471] radeon 0000:01:00.0:   R_008680_CP_STAT          = 0x80018647
Sep 19 15:14:35 david-desktop kernel: [ 1205.188476] radeon 0000:01:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
Sep 19 15:14:35 david-desktop kernel: [ 1205.238203] radeon 0000:01:00.0: R_008020_GRBM_SOFT_RESET=0x00004001
Sep 19 15:14:35 david-desktop kernel: [ 1205.238260] radeon 0000:01:00.0: SRBM_SOFT_RESET=0x00000100
Sep 19 15:14:35 david-desktop kernel: [ 1205.240351] radeon 0000:01:00.0:   R_008010_GRBM_STATUS      = 0x00003028
Sep 19 15:14:35 david-desktop kernel: [ 1205.240357] radeon 0000:01:00.0:   R_008014_GRBM_STATUS2     = 0x00000002
Sep 19 15:14:35 david-desktop kernel: [ 1205.240362] radeon 0000:01:00.0:   R_000E50_SRBM_STATUS      = 0x200000C0
Sep 19 15:14:35 david-desktop kernel: [ 1205.240367] radeon 0000:01:00.0:   R_008674_CP_STALLED_STAT1 = 0x00000000
Sep 19 15:14:35 david-desktop kernel: [ 1205.240372] radeon 0000:01:00.0:   R_008678_CP_STALLED_STAT2 = 0x00000000
Sep 19 15:14:35 david-desktop kernel: [ 1205.240377] radeon 0000:01:00.0:   R_00867C_CP_BUSY_STAT     = 0x00000000
Sep 19 15:14:35 david-desktop kernel: [ 1205.240382] radeon 0000:01:00.0:   R_008680_CP_STAT          = 0x00000000
Sep 19 15:14:35 david-desktop kernel: [ 1205.240388] radeon 0000:01:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
Sep 19 15:14:35 david-desktop kernel: [ 1205.240398] radeon 0000:01:00.0: GPU reset succeeded, trying to resume
Sep 19 15:14:35 david-desktop kernel: [ 1205.243106] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
Sep 19 15:14:35 david-desktop kernel: [ 1205.244289] [drm] PCIE GART of 1024M enabled (table at 0x000000000025D000).
Sep 19 15:14:35 david-desktop kernel: [ 1205.244314] radeon 0000:01:00.0: WB enabled
Sep 19 15:14:35 david-desktop kernel: [ 1205.244324] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff880035a88c00
Sep 19 15:14:35 david-desktop kernel: [ 1205.244332] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0xffff880035a88c0c
Sep 19 15:14:35 david-desktop kernel: [ 1205.245036] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x000000000005c598 and cpu addr 0xffffc90010c9c598
Sep 19 15:14:35 david-desktop kernel: [ 1205.290816] [drm] ring test on 0 succeeded in 1 usecs
Sep 19 15:14:35 david-desktop kernel: [ 1205.290881] [drm] ring test on 3 succeeded in 1 usecs
Sep 19 15:14:35 david-desktop kernel: [ 1205.465562] [drm] ring test on 5 succeeded in 1 usecs
Sep 19 15:14:35 david-desktop kernel: [ 1205.465573] [drm] UVD initialized successfully.
Sep 19 15:14:35 david-desktop kernel: [ 1205.465626] [drm] ib test on ring 0 succeeded in 0 usecs
Sep 19 15:14:35 david-desktop kernel: [ 1205.465684] [drm] ib test on ring 3 succeeded in 1 usecs
Sep 19 15:14:45 david-desktop kernel: [ 1215.620652] radeon 0000:01:00.0: ring 5 stalled for more than 10000msec
Sep 19 15:14:45 david-desktop kernel: [ 1215.620664] radeon 0000:01:00.0: GPU lockup (waiting for 0x0000000000000004 last fence id 0x0000000000000002 on ring 5)
Sep 19 15:14:45 david-desktop kernel: [ 1215.620671] [drm:uvd_v1_0_ib_test] *ERROR* radeon: fence wait failed (-35).
Sep 19 15:14:45 david-desktop kernel: [ 1215.620678] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-35).


[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: Radeon unconnected HDMI eats samples at 280 kHz

[Deucher, Alexander]

> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson@canonical.com]
> Sent: Friday, September 19, 2014 9:39 AM
> To: Deucher, Alexander; Takashi Iwai
> Cc: Anssi Hannula; alsa-devel@alsa-project.org
> Subject: Re: [alsa-devel] Radeon unconnected HDMI eats samples at 280 kHz
> 
> On 2014-09-19 00:29, Deucher, Alexander wrote:
> >>>> Well, if jack detection (get pin sense) works, there is.
> >>>
> >>> Does it react if we turn off the HDMI output via xrandr, too?
> >>> I'm not sure whether we need reprogram things in that case, though...
> >>
> >> xrandr correctly reports that "HDMI-0" is disconnected.
> >>
> >> I'm not sure how to turn the HDMI output via xrandr, but I tried "xrandr
> >> --output HDMI-0 --off" and it made no difference in either xrandr
> >> output, nor in codec/eld output.
> >>
> >> What I'm thinking is that it could be that the monitor_present is
> >> indicating the presence of my DVI monitor, as some cards are capable of
> >> outputting HDMI audio on their DVI outputs (through a passive DVI-
> >HDMI
> >> adapter). This is just a guess though.
> >
> > I'm not that familiar with the audio side, but on there are registers on the
> gpu side that will change what is reported to the audio side as far as I can tell.
> You might try the new hdmi patches I sent out today:
> > http://lists.freedesktop.org/archives/dri-devel/2014-
> September/068544.html
> > patch 5/5 is probably the most relevant for this discussion.  It explicitly
> clears the audio enable bit when the display is disabled which should cascade
> down to the audio side if I understand correctly.  If not, I think playing with
> the AZ_HOT_PLUG_CONTROL registers in that patch set can probably sort it
> out.
> 
> Thanks for the attention and the patches!
> 
> I compiled a 3.17-rc4 kernel plus the five patches. (I usually run the
> Ubuntu 3.13 kernel).

I've pushed an updated set to:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.18-wip

> 
> With this I saw that the jack reported "unplugged" when booting without
> an HDMI monitor, and that when the HDMI monitor was connected and got
> video output, the jack was now reported to be plugged in.
> However, when I unplugged the monitor, the jack was still reported to be
> plugged in.

Did you also run xrandr --output <output> --off?  The audio pins are not tied to a specific output (e.g., there can be multiple HDMI or DP ports on a system), so they are not directly tied to a hotplug pin.  I think the gpu driver has to set the appropriate bits in this register to have the changes reflected in the audio driver.

> 
> I also tried running a get_pin_sense verb manually and it still reported
> to be plugged in.
> 
> Also, I think it was the third time I plugged the monitor in, I got some
> type of GPU hang (see attached log). It never recovered by itself so I
> had to use SysRq to reboot the computer.
> 
> > I'm just not familiar enough with the azalia hw to know exactly how it's
> supposed to interact with the audio side.
> 
> Well, feel free to ask questions if you think we can answer them :-)
> 
> The bits that say PIN*_JACK_DETECTION_ENABLE and
> PIN*_UNSOLICITED_RESPONSE_ENABLE sounds like things that should be
> turned on all the time so we can properly get unsol jack detection
> events when the monitor is plugged or unplugged. Unless the
> PIN*_JACK_DETECTION_ENABLE actually represents the current state rather
> than the detection capability. But that's just guesses, as I assume the
> specs are not released?

I'm not familiar enough with the audio side, but here is some information about the bits in that register.  Hopefully someone more familiar with the audio side can help out.

PIN*_JACK_DETECTION_ENABLE
If PIN0_JACK_DETECTION_ENABLE is 1, changing PIN0_AUDIO_ENABLED will produce jack connection and disconnection status changes in pin0 accordingly. 

 POSSIBLE VALUES:
      00 - setting PIN0_AUDIO_ENABLED does not set pin0 PRESENCE_DETECT
      01 - setting PIN0_AUDIO_ENABLED sets pin0 PRESENCE_DETECT

PIN*_UNSOLICITED_RESPONSE_ENABLE 

For PIN0, If 1, when AUDIO_ENABLED changes, an unsolicited response with payload UNSOLICITED_RESPONSE_PAYLOAD will be sent. 
 POSSIBLE VALUES:
      00 - changing AUDIO_ENABLED does not produce an unsolicited response
      01 - changing AUDIO_ENABLED produces an unsolicited response

CODEC_HOT_PLUG_ENABLE 
If 1, changing AUDIO_ENABLED sets STATE_CHANGE_STATUS.

 POSSIBLE VALUES:
      00 - changing AUDIO_ENABLED does not set STATE_CHANGE_STATUS
      01 - changing AUDIO_ENABLED sets STATE_CHANGE_STATUS

PIN*_AUDIO_ENABLED 
Set to 1 by the driver if an HDMI TV able to take channel pair 0,1 for PIN0 (or 2,3 for PIN1, etc.) is connected, set to 0 if not.

 POSSIBLE VALUES:
      00 - disabled
      01 - enabled

AUDIO_ENABLED 
Set to 1 by the driver when an Audio Enabled HDMI TV is connected, set to 0 when it is disconnected. Zeroed by the driver during mode change to disable audio temporarily in order to avoid noise. The software changes on this bit are used by the CODEC hardware to emulate hot plugging-unplugging of the audio-enabled HDMI TV.

 POSSIBLE VALUES:
      00 - disabled
      01 - enabled

Alex

Re: Radeon unconnected HDMI eats samples at 280 kHz

[David Henningsson]

On 2014-09-19 16:14, Deucher, Alexander wrote:
>> -----Original Message-----
>> From: David Henningsson [mailto:david.henningsson@canonical.com]
>> Sent: Friday, September 19, 2014 9:39 AM
>> To: Deucher, Alexander; Takashi Iwai
>> Cc: Anssi Hannula; alsa-devel@alsa-project.org
>> Subject: Re: [alsa-devel] Radeon unconnected HDMI eats samples at 280 kHz
>>
>> On 2014-09-19 00:29, Deucher, Alexander wrote:
>>>>>> Well, if jack detection (get pin sense) works, there is.
>>>>>
>>>>> Does it react if we turn off the HDMI output via xrandr, too?
>>>>> I'm not sure whether we need reprogram things in that case, though...
>>>>
>>>> xrandr correctly reports that "HDMI-0" is disconnected.
>>>>
>>>> I'm not sure how to turn the HDMI output via xrandr, but I tried "xrandr
>>>> --output HDMI-0 --off" and it made no difference in either xrandr
>>>> output, nor in codec/eld output.
>>>>
>>>> What I'm thinking is that it could be that the monitor_present is
>>>> indicating the presence of my DVI monitor, as some cards are capable of
>>>> outputting HDMI audio on their DVI outputs (through a passive DVI-
>>> HDMI
>>>> adapter). This is just a guess though.
>>>
>>> I'm not that familiar with the audio side, but on there are registers on the
>> gpu side that will change what is reported to the audio side as far as I can tell.
>> You might try the new hdmi patches I sent out today:
>>> http://lists.freedesktop.org/archives/dri-devel/2014-
>> September/068544.html
>>> patch 5/5 is probably the most relevant for this discussion.  It explicitly
>> clears the audio enable bit when the display is disabled which should cascade
>> down to the audio side if I understand correctly.  If not, I think playing with
>> the AZ_HOT_PLUG_CONTROL registers in that patch set can probably sort it
>> out.
>>
>> Thanks for the attention and the patches!
>>
>> I compiled a 3.17-rc4 kernel plus the five patches. (I usually run the
>> Ubuntu 3.13 kernel).
>
> I've pushed an updated set to:
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.18-wip

Thanks, will try this later. In this case, would you expect me to take 
the entire kernel from the drm-next-3.18-wip branch, or mix it somehow 
with a 3.17 kernel?

>> With this I saw that the jack reported "unplugged" when booting without
>> an HDMI monitor, and that when the HDMI monitor was connected and got
>> video output, the jack was now reported to be plugged in.
>> However, when I unplugged the monitor, the jack was still reported to be
>> plugged in.
>
> Did you also run xrandr --output <output> --off?

Not that exact command, but I tried "Detect displays" (in the system 
settings dialog) to see if that helped. Also xrandr showed the HDMI-0 
display as disconnected.

> The audio pins are not tied to a specific output (e.g., there can be multiple HDMI or DP ports on a system), so they are not directly tied to a hotplug pin.  I think the gpu driver has to set the appropriate bits in this register to have the changes reflected in the audio driver.

In my case, I have one HDMI, one VGA and one DVI. But there is only one 
pin on the audio side. So the question here is whether the DVI output is 
audio capable, and if that could possibly cause confusion here, or if 
one would expect the pin to always map to the HDMI output?

>> I also tried running a get_pin_sense verb manually and it still reported
>> to be plugged in.
>>
>> Also, I think it was the third time I plugged the monitor in, I got some
>> type of GPU hang (see attached log). It never recovered by itself so I
>> had to use SysRq to reboot the computer.
>>
>>> I'm just not familiar enough with the azalia hw to know exactly how it's
>> supposed to interact with the audio side.
>>
>> Well, feel free to ask questions if you think we can answer them :-)
>>
>> The bits that say PIN*_JACK_DETECTION_ENABLE and
>> PIN*_UNSOLICITED_RESPONSE_ENABLE sounds like things that should be
>> turned on all the time so we can properly get unsol jack detection
>> events when the monitor is plugged or unplugged. Unless the
>> PIN*_JACK_DETECTION_ENABLE actually represents the current state rather
>> than the detection capability. But that's just guesses, as I assume the
>> specs are not released?
>
> I'm not familiar enough with the audio side, but here is some information about the bits in that register.

Thanks!

> Hopefully someone more familiar with the audio side can help out.
>
> PIN*_JACK_DETECTION_ENABLE
> If PIN0_JACK_DETECTION_ENABLE is 1, changing PIN0_AUDIO_ENABLED will produce jack connection and disconnection status changes in pin0 accordingly.
>
>   POSSIBLE VALUES:
>        00 - setting PIN0_AUDIO_ENABLED does not set pin0 PRESENCE_DETECT
>        01 - setting PIN0_AUDIO_ENABLED sets pin0 PRESENCE_DETECT

Ok, we definitely need this enabled.

> PIN*_UNSOLICITED_RESPONSE_ENABLE
>
> For PIN0, If 1, when AUDIO_ENABLED changes, an unsolicited response with payload UNSOLICITED_RESPONSE_PAYLOAD will be sent.
>   POSSIBLE VALUES:
>        00 - changing AUDIO_ENABLED does not produce an unsolicited response
>        01 - changing AUDIO_ENABLED produces an unsolicited response

Ok, we need this enabled too.

Note: to make sure both plug and unplug events are delivered, these two 
should probably remain enabled even when the monitor is disconnected. 
There is a risk that setting these to zero when also setting 
AUDIO_ENABLED to zero could cause either event not to trigger on the 
audio side.

> CODEC_HOT_PLUG_ENABLE
> If 1, changing AUDIO_ENABLED sets STATE_CHANGE_STATUS.
>
>   POSSIBLE VALUES:
>        00 - changing AUDIO_ENABLED does not set STATE_CHANGE_STATUS
>        01 - changing AUDIO_ENABLED sets STATE_CHANGE_STATUS

This probably refer to audio controller register STATESTS, because 
that's the only thing labelled "State change status" in the HDA spec. I 
think this should be enabled too, but it's possible that it's only 
relevant if the audio device is in a power down state.

> PIN*_AUDIO_ENABLED
> Set to 1 by the driver if an HDMI TV able to take channel pair 0,1 for PIN0 (or 2,3 for PIN1, etc.) is connected, set to 0 if not.
>
>   POSSIBLE VALUES:
>        00 - disabled
>        01 - enabled
>
> AUDIO_ENABLED
> Set to 1 by the driver when an Audio Enabled HDMI TV is connected, set to 0 when it is disconnected. Zeroed by the driver during mode change to disable audio temporarily in order to avoid noise. The software changes on this bit are used by the CODEC hardware to emulate hot plugging-unplugging of the audio-enabled HDMI TV.
>
>   POSSIBLE VALUES:
>        00 - disabled
>        01 - enabled

If audio_enabled quickly changes to off and then on when there is a mode 
change, it might make sense to *not* wake up the audio driver in this 
case, as I assume that the audio capabilities on the HDMI TV will not 
change just because the video mode changes.

To sum up, what the audio driver needs is PRESENCE_DETECT to correctly 
correspond to whether something is plugged in or not. And we need an 
unsolicited event when PRESENCE_DETECT changes.

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

Re: Radeon unconnected HDMI eats samples at 280 kHz

[Alexander E. Patrakov]

19.09.2014 23:47, David Henningsson wrote:
> If audio_enabled quickly changes to off and then on when there is a mode
> change, it might make sense to *not* wake up the audio driver in this
> case, as I assume that the audio capabilities on the HDMI TV will not
> change just because the video mode changes.

Unfortunately, they will. Some low-resolution video modes just don't 
have enough pixel clock to transfer the 7.1 audio signal at 192 kHz. See 
the table on page 105 (shown as 121 in some readers) of 
http://www.microprocessor.org/HDMISpecification13a.pdf , section "7.3.3 
Video Dependency".

-- 
Alexander E. Patrakov

Re: Radeon unconnected HDMI eats samples at 280 kHz

[Deucher, Alexander]

> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson@canonical.com]
> Sent: Friday, September 19, 2014 1:47 PM
> To: Deucher, Alexander; Takashi Iwai
> Cc: Anssi Hannula; alsa-devel@alsa-project.org
> Subject: Re: [alsa-devel] Radeon unconnected HDMI eats samples at 280 kHz
> 
> 
> 
> On 2014-09-19 16:14, Deucher, Alexander wrote:
> >> -----Original Message-----
> >> From: David Henningsson [mailto:david.henningsson@canonical.com]
> >> Sent: Friday, September 19, 2014 9:39 AM
> >> To: Deucher, Alexander; Takashi Iwai
> >> Cc: Anssi Hannula; alsa-devel@alsa-project.org
> >> Subject: Re: [alsa-devel] Radeon unconnected HDMI eats samples at 280
> kHz
> >>
> >> On 2014-09-19 00:29, Deucher, Alexander wrote:
> >>>>>> Well, if jack detection (get pin sense) works, there is.
> >>>>>
> >>>>> Does it react if we turn off the HDMI output via xrandr, too?
> >>>>> I'm not sure whether we need reprogram things in that case,
> though...
> >>>>
> >>>> xrandr correctly reports that "HDMI-0" is disconnected.
> >>>>
> >>>> I'm not sure how to turn the HDMI output via xrandr, but I tried "xrandr
> >>>> --output HDMI-0 --off" and it made no difference in either xrandr
> >>>> output, nor in codec/eld output.
> >>>>
> >>>> What I'm thinking is that it could be that the monitor_present is
> >>>> indicating the presence of my DVI monitor, as some cards are capable
> of
> >>>> outputting HDMI audio on their DVI outputs (through a passive DVI-
> >>> HDMI
> >>>> adapter). This is just a guess though.
> >>>
> >>> I'm not that familiar with the audio side, but on there are registers on
> the
> >> gpu side that will change what is reported to the audio side as far as I can
> tell.
> >> You might try the new hdmi patches I sent out today:
> >>> http://lists.freedesktop.org/archives/dri-devel/2014-
> >> September/068544.html
> >>> patch 5/5 is probably the most relevant for this discussion.  It explicitly
> >> clears the audio enable bit when the display is disabled which should
> cascade
> >> down to the audio side if I understand correctly.  If not, I think playing
> with
> >> the AZ_HOT_PLUG_CONTROL registers in that patch set can probably sort
> it
> >> out.
> >>
> >> Thanks for the attention and the patches!
> >>
> >> I compiled a 3.17-rc4 kernel plus the five patches. (I usually run the
> >> Ubuntu 3.13 kernel).
> >
> > I've pushed an updated set to:
> > http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.18-wip
> 
> Thanks, will try this later. In this case, would you expect me to take
> the entire kernel from the drm-next-3.18-wip branch, or mix it somehow
> with a 3.17 kernel?

It's just a collection of patches I'm working on for 3.18.  The branch is actually based on 3.17 and the top 5 patches (which are the relevant ones) should apply to most other 3.17 trees.

> 
> >> With this I saw that the jack reported "unplugged" when booting without
> >> an HDMI monitor, and that when the HDMI monitor was connected and
> got
> >> video output, the jack was now reported to be plugged in.
> >> However, when I unplugged the monitor, the jack was still reported to be
> >> plugged in.
> >
> > Did you also run xrandr --output <output> --off?
> 
> Not that exact command, but I tried "Detect displays" (in the system
> settings dialog) to see if that helped. Also xrandr showed the HDMI-0
> display as disconnected.
> 

The audio is not "connected" and the sink information is not passed to the audio driver until you turn on the display.  It's not tied to the connected status of the displays since there is not a 1:1 mapping of displays and audio pins.

> > The audio pins are not tied to a specific output (e.g., there can be multiple
> HDMI or DP ports on a system), so they are not directly tied to a hotplug pin.
> I think the gpu driver has to set the appropriate bits in this register to have
> the changes reflected in the audio driver.
> 
> In my case, I have one HDMI, one VGA and one DVI. But there is only one
> pin on the audio side. So the question here is whether the DVI output is
> audio capable, and if that could possibly cause confusion here, or if
> one would expect the pin to always map to the HDMI output?
> 

All of the digital encoders on the chips (up to 7 depending on the asic) are hdmi capable, the number and types or ports are up to the oem.  The DVI port supports HDMI audio as well if you use a DVI to HDMI adapter.

> >> I also tried running a get_pin_sense verb manually and it still reported
> >> to be plugged in.
> >>
> >> Also, I think it was the third time I plugged the monitor in, I got some
> >> type of GPU hang (see attached log). It never recovered by itself so I
> >> had to use SysRq to reboot the computer.
> >>
> >>> I'm just not familiar enough with the azalia hw to know exactly how it's
> >> supposed to interact with the audio side.
> >>
> >> Well, feel free to ask questions if you think we can answer them :-)
> >>
> >> The bits that say PIN*_JACK_DETECTION_ENABLE and
> >> PIN*_UNSOLICITED_RESPONSE_ENABLE sounds like things that should be
> >> turned on all the time so we can properly get unsol jack detection
> >> events when the monitor is plugged or unplugged. Unless the
> >> PIN*_JACK_DETECTION_ENABLE actually represents the current state
> rather
> >> than the detection capability. But that's just guesses, as I assume the
> >> specs are not released?
> >
> > I'm not familiar enough with the audio side, but here is some information
> about the bits in that register.
> 
> Thanks!
> 
> > Hopefully someone more familiar with the audio side can help out.
> >
> > PIN*_JACK_DETECTION_ENABLE
> > If PIN0_JACK_DETECTION_ENABLE is 1, changing PIN0_AUDIO_ENABLED
> will produce jack connection and disconnection status changes in pin0
> accordingly.
> >
> >   POSSIBLE VALUES:
> >        00 - setting PIN0_AUDIO_ENABLED does not set pin0
> PRESENCE_DETECT
> >        01 - setting PIN0_AUDIO_ENABLED sets pin0 PRESENCE_DETECT
> 
> Ok, we definitely need this enabled.
> 
> > PIN*_UNSOLICITED_RESPONSE_ENABLE
> >
> > For PIN0, If 1, when AUDIO_ENABLED changes, an unsolicited response
> with payload UNSOLICITED_RESPONSE_PAYLOAD will be sent.
> >   POSSIBLE VALUES:
> >        00 - changing AUDIO_ENABLED does not produce an unsolicited
> response
> >        01 - changing AUDIO_ENABLED produces an unsolicited response
> 
> Ok, we need this enabled too.
> 
> Note: to make sure both plug and unplug events are delivered, these two
> should probably remain enabled even when the monitor is disconnected.
> There is a risk that setting these to zero when also setting
> AUDIO_ENABLED to zero could cause either event not to trigger on the
> audio side.

The driver would need to be restructured a bit to actually reflect the connected/disconnected state of the monitor on the audio side.  Right now we set up audio when the display is enabled, not when it's probed.

> 
> > CODEC_HOT_PLUG_ENABLE
> > If 1, changing AUDIO_ENABLED sets STATE_CHANGE_STATUS.
> >
> >   POSSIBLE VALUES:
> >        00 - changing AUDIO_ENABLED does not set STATE_CHANGE_STATUS
> >        01 - changing AUDIO_ENABLED sets STATE_CHANGE_STATUS
> 
> This probably refer to audio controller register STATESTS, because
> that's the only thing labelled "State change status" in the HDA spec. I
> think this should be enabled too, but it's possible that it's only
> relevant if the audio device is in a power down state.

Yes, STATE_CHANGE_STATUS is an audio register.

> 
> > PIN*_AUDIO_ENABLED
> > Set to 1 by the driver if an HDMI TV able to take channel pair 0,1 for PIN0
> (or 2,3 for PIN1, etc.) is connected, set to 0 if not.
> >
> >   POSSIBLE VALUES:
> >        00 - disabled
> >        01 - enabled
> >
> > AUDIO_ENABLED
> > Set to 1 by the driver when an Audio Enabled HDMI TV is connected, set to
> 0 when it is disconnected. Zeroed by the driver during mode change to
> disable audio temporarily in order to avoid noise. The software changes on
> this bit are used by the CODEC hardware to emulate hot plugging-unplugging
> of the audio-enabled HDMI TV.
> >
> >   POSSIBLE VALUES:
> >        00 - disabled
> >        01 - enabled
> 
> If audio_enabled quickly changes to off and then on when there is a mode
> change, it might make sense to *not* wake up the audio driver in this
> case, as I assume that the audio capabilities on the HDMI TV will not
> change just because the video mode changes.
> 
> To sum up, what the audio driver needs is PRESENCE_DETECT to correctly
> correspond to whether something is plugged in or not. And we need an
> unsolicited event when PRESENCE_DETECT changes.

The tricky part is that you may only have 1 audio pin.  What do you do if you have multiple displays that support audio connected?  I guess we could report connected if any displays that support audio are connected, but pass the sink information to the audio driver when the display was actually enabled since the sinks may have different audio capabilities.

Alex

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

Re: Radeon unconnected HDMI eats samples at 280 kHz

[David Henningsson]

On 2014-09-19 20:19, Alexander E. Patrakov wrote:
> 19.09.2014 23:47, David Henningsson wrote:
>> If audio_enabled quickly changes to off and then on when there is a mode
>> change, it might make sense to *not* wake up the audio driver in this
>> case, as I assume that the audio capabilities on the HDMI TV will not
>> change just because the video mode changes.
>
> Unfortunately, they will. Some low-resolution video modes just don't
> have enough pixel clock to transfer the 7.1 audio signal at 192 kHz. See
> the table on page 105 (shown as 121 in some readers) of
> http://www.microprocessor.org/HDMISpecification13a.pdf , section "7.3.3
> Video Dependency".

Ok, I stand corrected. I wonder what the least ugly thing to do would be 
if the user is currently running audio when this happens, e g, if the 
user is running a game with background music, and goes to "video 
settings" and switches mode.

But if such thing would audio glitch anyhow, like it seems maybe we 
should let the audio_enabled signal pass through to the audio side to 
indicate a short disconnection. It's just not going to be that fun 
if/when we implement reprobing the HDMI device on plug in. And also the 
risk of the audio stream switching to somewhere else, like going from 
HDMI to analog.


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

Re: Radeon unconnected HDMI eats samples at 280 kHz

[David Henningsson]

On 2014-09-20 01:32, Deucher, Alexander wrote:
>> -----Original Message-----
>> From: David Henningsson [mailto:david.henningsson@canonical.com]
>> Sent: Friday, September 19, 2014 1:47 PM
>> To: Deucher, Alexander; Takashi Iwai
>> Cc: Anssi Hannula; alsa-devel@alsa-project.org
>> Subject: Re: [alsa-devel] Radeon unconnected HDMI eats samples at 280 kHz
>> On 2014-09-19 16:14, Deucher, Alexander wrote:
>>>> -----Original Message-----
>>>> From: David Henningsson [mailto:david.henningsson@canonical.com]
>>>> Sent: Friday, September 19, 2014 9:39 AM
>>>> To: Deucher, Alexander; Takashi Iwai
>>>> Cc: Anssi Hannula; alsa-devel@alsa-project.org
>>>> Subject: Re: [alsa-devel] Radeon unconnected HDMI eats samples at 280
>> kHz
>>>>
>>>> On 2014-09-19 00:29, Deucher, Alexander wrote:
>>> PIN*_JACK_DETECTION_ENABLE
>>> If PIN0_JACK_DETECTION_ENABLE is 1, changing PIN0_AUDIO_ENABLED
>> will produce jack connection and disconnection status changes in pin0
>> accordingly.
>>>
>>>    POSSIBLE VALUES:
>>>         00 - setting PIN0_AUDIO_ENABLED does not set pin0
>> PRESENCE_DETECT
>>>         01 - setting PIN0_AUDIO_ENABLED sets pin0 PRESENCE_DETECT
>>
>> Ok, we definitely need this enabled.
>>
>>> PIN*_UNSOLICITED_RESPONSE_ENABLE
>>>
>>> For PIN0, If 1, when AUDIO_ENABLED changes, an unsolicited response
>> with payload UNSOLICITED_RESPONSE_PAYLOAD will be sent.
>>>    POSSIBLE VALUES:
>>>         00 - changing AUDIO_ENABLED does not produce an unsolicited
>> response
>>>         01 - changing AUDIO_ENABLED produces an unsolicited response
>>
>> Ok, we need this enabled too.
>>
>> Note: to make sure both plug and unplug events are delivered, these two
>> should probably remain enabled even when the monitor is disconnected.
>> There is a risk that setting these to zero when also setting
>> AUDIO_ENABLED to zero could cause either event not to trigger on the
>> audio side.
>
> The driver would need to be restructured a bit to actually reflect the connected/disconnected state of the monitor on the audio side.  Right now we set up audio when the display is enabled, not when it's probed.

I think the current behaviour is okay. If there's no video enabled, then 
it's okay to report audio as disconnected too.

So my sentence above should be rephrased as "these two should probably 
remain enabled even when the display is disabled or disconnected".

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.

>>> CODEC_HOT_PLUG_ENABLE
>>> If 1, changing AUDIO_ENABLED sets STATE_CHANGE_STATUS.
>>>
>>>    POSSIBLE VALUES:
>>>         00 - changing AUDIO_ENABLED does not set STATE_CHANGE_STATUS
>>>         01 - changing AUDIO_ENABLED sets STATE_CHANGE_STATUS
>>
>> This probably refer to audio controller register STATESTS, because
>> that's the only thing labelled "State change status" in the HDA spec. I
>> think this should be enabled too, but it's possible that it's only
>> relevant if the audio device is in a power down state.
>
> Yes, STATE_CHANGE_STATUS is an audio register.
>
>>
>>> PIN*_AUDIO_ENABLED
>>> Set to 1 by the driver if an HDMI TV able to take channel pair 0,1 for PIN0
>> (or 2,3 for PIN1, etc.) is connected, set to 0 if not.
>>>
>>>    POSSIBLE VALUES:
>>>         00 - disabled
>>>         01 - enabled
>>>
>>> AUDIO_ENABLED
>>> Set to 1 by the driver when an Audio Enabled HDMI TV is connected, set to
>> 0 when it is disconnected. Zeroed by the driver during mode change to
>> disable audio temporarily in order to avoid noise. The software changes on
>> this bit are used by the CODEC hardware to emulate hot plugging-unplugging
>> of the audio-enabled HDMI TV.
>>>
>>>    POSSIBLE VALUES:
>>>         00 - disabled
>>>         01 - enabled
>>
>> If audio_enabled quickly changes to off and then on when there is a mode
>> change, it might make sense to *not* wake up the audio driver in this
>> case, as I assume that the audio capabilities on the HDMI TV will not
>> change just because the video mode changes.
>>
>> To sum up, what the audio driver needs is PRESENCE_DETECT to correctly
>> correspond to whether something is plugged in or not. And we need an
>> unsolicited event when PRESENCE_DETECT changes.
>
> The tricky part is that you may only have 1 audio pin.  What do you do if you have multiple displays that support audio connected?  I guess we could report connected if any displays that support audio are connected, but pass the sink information to the audio driver when the display was actually enabled since the sinks may have different audio capabilities.

 From the audio driver's point of view, if you have 1 audio pin, then 
that's one display. Presence detect, as well as ELD information, should 
reflect the status of that one display.

How to multiplex that against several audio capable monitors is tricky, 
but it's something you have to solve on the video driver side.
I'm not sure how other video drivers have solved that, or if AMD/ATI is 
the only manufacturer who has cards with this hw design (i e fewer audio 
pins than audio capable outputs).


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

Re: Radeon unconnected HDMI eats samples at 280 kHz

[Alexander E. Patrakov]

20.09.2014 06:06, David Henningsson wrote:
>  From the audio driver's point of view, if you have 1 audio pin, then
> that's one display. Presence detect, as well as ELD information, should
> reflect the status of that one display.
>
> How to multiplex that against several audio capable monitors is tricky,
> but it's something you have to solve on the video driver side.
> I'm not sure how other video drivers have solved that, or if AMD/ATI is
> the only manufacturer who has cards with this hw design (i e fewer audio
> pins than audio capable outputs).

A similar problem exists for Intel on Haswell, and here is how they 
solved it.

They have three HDMI outputs, but only two audio pins. Audio can be 
routed to any two of the three connected monitors. This is done by 
opening the following PCMs: hdmi:0,0, hdmi:0,1 and hdmi:0,2, with 1:1 
correspondence to the physical outputs. I.e. the driver pretends that 
there are three subdevices. However, only two of them (any two) can be 
opened simultaneously. The third one gives -EBUSY on attempts to open it.

-- 
Alexander E. Patrakov

Re: Radeon unconnected HDMI eats samples at 280 kHz

[Anssi Hannula]

20.09.2014, 02:35, David Henningsson kirjoitti:
> 
> 
> On 2014-09-19 20:19, Alexander E. Patrakov wrote:
>> 19.09.2014 23:47, David Henningsson wrote:
>>> If audio_enabled quickly changes to off and then on when there is a mode
>>> change, it might make sense to *not* wake up the audio driver in this
>>> case, as I assume that the audio capabilities on the HDMI TV will not
>>> change just because the video mode changes.
>>
>> Unfortunately, they will. Some low-resolution video modes just don't
>> have enough pixel clock to transfer the 7.1 audio signal at 192 kHz. See
>> the table on page 105 (shown as 121 in some readers) of
>> http://www.microprocessor.org/HDMISpecification13a.pdf , section "7.3.3
>> Video Dependency".
> 
> Ok, I stand corrected. I wonder what the least ugly thing to do would be 
> if the user is currently running audio when this happens, e g, if the 
> user is running a game with background music, and goes to "video 
> settings" and switches mode.
> 
> But if such thing would audio glitch anyhow, like it seems maybe we 
> should let the audio_enabled signal pass through to the audio side to 
> indicate a short disconnection. It's just not going to be that fun 
> if/when we implement reprobing the HDMI device on plug in. And also the 
> risk of the audio stream switching to somewhere else, like going from 
> HDMI to analog.

Note that I don't think this case is currently handled by any other
driver either. The HDMI audio driver doesn't know what video mode is
currently in use and what audio modes to disallow.

The EDID and therefore reported capabilities of the TV do not change.

-- 
Anssi Hannula

Re: Radeon unconnected HDMI eats samples at 280 kHz

[Alexander E. Patrakov]

20.09.2014 05:35, David Henningsson wrote:
>
>
> On 2014-09-19 20:19, Alexander E. Patrakov wrote:
>> 19.09.2014 23:47, David Henningsson wrote:
>>> If audio_enabled quickly changes to off and then on when there is a mode
>>> change, it might make sense to *not* wake up the audio driver in this
>>> case, as I assume that the audio capabilities on the HDMI TV will not
>>> change just because the video mode changes.
>>
>> Unfortunately, they will. Some low-resolution video modes just don't
>> have enough pixel clock to transfer the 7.1 audio signal at 192 kHz. See
>> the table on page 105 (shown as 121 in some readers) of
>> http://www.microprocessor.org/HDMISpecification13a.pdf , section "7.3.3
>> Video Dependency".
>
> Ok, I stand corrected. I wonder what the least ugly thing to do would be
> if the user is currently running audio when this happens, e g, if the
> user is running a game with background music, and goes to "video
> settings" and switches mode.
>
> But if such thing would audio glitch anyhow, like it seems maybe we
> should let the audio_enabled signal pass through to the audio side to
> indicate a short disconnection. It's just not going to be that fun
> if/when we implement reprobing the HDMI device on plug in. And also the
> risk of the audio stream switching to somewhere else, like going from
> HDMI to analog.

I think it is appropriate to interrupt the audio stream only if it 
doesn't fit the new mode. Then snd_pcm_writei can return an error code - 
but I don't have a good candidate. Neither -EIO nor -ENODEV nor 
-ESTRPIPE quite fits the bill.

-- 
Alexander E. Patrakov

Re: Radeon unconnected HDMI eats samples at 280 kHz

[Deucher, Alexander]

> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson@canonical.com]
> Sent: Friday, September 19, 2014 8:07 PM
> To: Deucher, Alexander; Takashi Iwai
> Cc: Anssi Hannula; alsa-devel@alsa-project.org
> Subject: Re: [alsa-devel] Radeon unconnected HDMI eats samples at 280 kHz
> 
> 
> 
> On 2014-09-20 01:32, Deucher, Alexander wrote:
> >> -----Original Message-----
> >> From: David Henningsson [mailto:david.henningsson@canonical.com]
> >> Sent: Friday, September 19, 2014 1:47 PM
> >> To: Deucher, Alexander; Takashi Iwai
> >> Cc: Anssi Hannula; alsa-devel@alsa-project.org
> >> Subject: Re: [alsa-devel] Radeon unconnected HDMI eats samples at 280
> kHz
> >> On 2014-09-19 16:14, Deucher, Alexander wrote:
> >>>> -----Original Message-----
> >>>> From: David Henningsson [mailto:david.henningsson@canonical.com]
> >>>> Sent: Friday, September 19, 2014 9:39 AM
> >>>> To: Deucher, Alexander; Takashi Iwai
> >>>> Cc: Anssi Hannula; alsa-devel@alsa-project.org
> >>>> Subject: Re: [alsa-devel] Radeon unconnected HDMI eats samples at
> 280
> >> kHz
> >>>>
> >>>> On 2014-09-19 00:29, Deucher, Alexander wrote:
> >>> PIN*_JACK_DETECTION_ENABLE
> >>> If PIN0_JACK_DETECTION_ENABLE is 1, changing PIN0_AUDIO_ENABLED
> >> will produce jack connection and disconnection status changes in pin0
> >> accordingly.
> >>>
> >>>    POSSIBLE VALUES:
> >>>         00 - setting PIN0_AUDIO_ENABLED does not set pin0
> >> PRESENCE_DETECT
> >>>         01 - setting PIN0_AUDIO_ENABLED sets pin0 PRESENCE_DETECT
> >>
> >> Ok, we definitely need this enabled.
> >>
> >>> PIN*_UNSOLICITED_RESPONSE_ENABLE
> >>>
> >>> For PIN0, If 1, when AUDIO_ENABLED changes, an unsolicited response
> >> with payload UNSOLICITED_RESPONSE_PAYLOAD will be sent.
> >>>    POSSIBLE VALUES:
> >>>         00 - changing AUDIO_ENABLED does not produce an unsolicited
> >> response
> >>>         01 - changing AUDIO_ENABLED produces an unsolicited response
> >>
> >> Ok, we need this enabled too.
> >>
> >> Note: to make sure both plug and unplug events are delivered, these two
> >> should probably remain enabled even when the monitor is disconnected.
> >> There is a risk that setting these to zero when also setting
> >> AUDIO_ENABLED to zero could cause either event not to trigger on the
> >> audio side.
> >
> > The driver would need to be restructured a bit to actually reflect the
> connected/disconnected state of the monitor on the audio side.  Right now
> we set up audio when the display is enabled, not when it's probed.
> 
> I think the current behaviour is okay. If there's no video enabled, then
> it's okay to report audio as disconnected too.
> 
> So my sentence above should be rephrased as "these two should probably
> remain enabled even when the display is disabled or disconnected".
> 
> 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

> 
> >>> CODEC_HOT_PLUG_ENABLE
> >>> If 1, changing AUDIO_ENABLED sets STATE_CHANGE_STATUS.
> >>>
> >>>    POSSIBLE VALUES:
> >>>         00 - changing AUDIO_ENABLED does not set
> STATE_CHANGE_STATUS
> >>>         01 - changing AUDIO_ENABLED sets STATE_CHANGE_STATUS
> >>
> >> This probably refer to audio controller register STATESTS, because
> >> that's the only thing labelled "State change status" in the HDA spec. I
> >> think this should be enabled too, but it's possible that it's only
> >> relevant if the audio device is in a power down state.
> >
> > Yes, STATE_CHANGE_STATUS is an audio register.
> >
> >>
> >>> PIN*_AUDIO_ENABLED
> >>> Set to 1 by the driver if an HDMI TV able to take channel pair 0,1 for PIN0
> >> (or 2,3 for PIN1, etc.) is connected, set to 0 if not.
> >>>
> >>>    POSSIBLE VALUES:
> >>>         00 - disabled
> >>>         01 - enabled
> >>>
> >>> AUDIO_ENABLED
> >>> Set to 1 by the driver when an Audio Enabled HDMI TV is connected, set
> to
> >> 0 when it is disconnected. Zeroed by the driver during mode change to
> >> disable audio temporarily in order to avoid noise. The software changes
> on
> >> this bit are used by the CODEC hardware to emulate hot plugging-
> unplugging
> >> of the audio-enabled HDMI TV.
> >>>
> >>>    POSSIBLE VALUES:
> >>>         00 - disabled
> >>>         01 - enabled
> >>
> >> If audio_enabled quickly changes to off and then on when there is a
> mode
> >> change, it might make sense to *not* wake up the audio driver in this
> >> case, as I assume that the audio capabilities on the HDMI TV will not
> >> change just because the video mode changes.
> >>
> >> To sum up, what the audio driver needs is PRESENCE_DETECT to correctly
> >> correspond to whether something is plugged in or not. And we need an
> >> unsolicited event when PRESENCE_DETECT changes.
> >
> > The tricky part is that you may only have 1 audio pin.  What do you do if you
> have multiple displays that support audio connected?  I guess we could
> report connected if any displays that support audio are connected, but pass
> the sink information to the audio driver when the display was actually
> enabled since the sinks may have different audio capabilities.
> 
>  From the audio driver's point of view, if you have 1 audio pin, then
> that's one display. Presence detect, as well as ELD information, should
> reflect the status of that one display.
> 
> How to multiplex that against several audio capable monitors is tricky,
> but it's something you have to solve on the video driver side.
> I'm not sure how other video drivers have solved that, or if AMD/ATI is
> the only manufacturer who has cards with this hw design (i e fewer audio
> pins than audio capable outputs).

It's pretty standard with older GPUs regardless of vendors.  Newer asics give you more flexibility, but there is still no hardcoded assignment.  E.g., the pins can be dynamically routed to multiple displays depending on the configuration the user wants.

Alex

Re: Radeon unconnected HDMI eats samples at 280 kHz

[David Henningsson]

On 2014-09-22 14:46, Deucher, Alexander wrote:
>> -----Original Message-----
>> From: David Henningsson [mailto:david.henningsson@canonical.com]
>> Sent: Friday, September 19, 2014 8:07 PM
>> To: Deucher, Alexander; Takashi Iwai
>> Cc: Anssi Hannula; alsa-devel@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?

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?

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

Re: Radeon unconnected HDMI eats samples at 280 kHz

[Deucher, Alexander]

> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson@canonical.com]
> Sent: Monday, September 22, 2014 10:39 AM
> To: Deucher, Alexander; Takashi Iwai
> Cc: Anssi Hannula; alsa-devel@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@canonical.com]
> >> Sent: Friday, September 19, 2014 8:07 PM
> >> To: Deucher, Alexander; Takashi Iwai
> >> Cc: Anssi Hannula; alsa-devel@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

Re: Radeon unconnected HDMI eats samples at 280 kHz

[David Henningsson]

On 2014-09-22 16:52, Deucher, Alexander wrote:
>> -----Original Message-----
>> From: David Henningsson [mailto:david.henningsson@canonical.com]
>> Sent: Monday, September 22, 2014 10:39 AM
>> To: Deucher, Alexander; Takashi Iwai
>> Cc: Anssi Hannula; alsa-devel@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@canonical.com]
>>>> Sent: Friday, September 19, 2014 8:07 PM
>>>> To: Deucher, Alexander; Takashi Iwai
>>>> Cc: Anssi Hannula; alsa-devel@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]

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

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.


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

Re: Radeon unconnected HDMI eats samples at 280 kHz

[Deucher, Alexander]

> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson@canonical.com]
> Sent: Tuesday, September 23, 2014 5:48 AM
> To: Deucher, Alexander; Takashi Iwai
> Cc: Anssi Hannula; alsa-devel@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@canonical.com]
> >> Sent: Monday, September 22, 2014 10:39 AM
> >> To: Deucher, Alexander; Takashi Iwai
> >> Cc: Anssi Hannula; alsa-devel@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@canonical.com]
> >>>> Sent: Friday, September 19, 2014 8:07 PM
> >>>> To: Deucher, Alexander; Takashi Iwai
> >>>> Cc: Anssi Hannula; alsa-devel@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

Re: Radeon unconnected HDMI eats samples at 280 kHz

[David Henningsson]

On 2014-09-23 16:07, Deucher, Alexander wrote:
>> -----Original Message-----
>> From: David Henningsson [mailto:david.henningsson@canonical.com]
>> Sent: Tuesday, September 23, 2014 5:48 AM
>> To: Deucher, Alexander; Takashi Iwai
>> Cc: Anssi Hannula; alsa-devel@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@canonical.com]
>>>> Sent: Monday, September 22, 2014 10:39 AM
>>>> To: Deucher, Alexander; Takashi Iwai
>>>> Cc: Anssi Hannula; alsa-devel@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@canonical.com]
>>>>>> Sent: Friday, September 19, 2014 8:07 PM
>>>>>> To: Deucher, Alexander; Takashi Iwai
>>>>>> Cc: Anssi Hannula; alsa-devel@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.

But it makes sense that the audio is turned off when the video is, right?

Because if first unplug HDMI (nothing happens) and then run "xrandr" 
(without parameters), running that command causes a "re-detection" or 
whatever the correct term is - i e, my DVI screen goes black for a 
second, and afterwards the mouse pointer can no longer move to the other 
non-existent display.
At that point, audio still remains in the "plugged in" state. Also, 
executing "xrandr --output HDMI-0 --off" has no effect in that state.

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

I've now tried these commands:

radeonreg regset 0x7300 0x001000f0 and
radeonreg regset 0x7300 0x8f1000f0

Both commands update the audio side to report either unplugged or 
plugged in, so things seem to work as expected w r t the connection 
between this register and the audio side.


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

Re: Radeon unconnected HDMI eats samples at 280 kHz

[Deucher, Alexander]

> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson@canonical.com]
> Sent: Wednesday, September 24, 2014 5:28 AM
> To: Deucher, Alexander; Takashi Iwai
> Cc: Anssi Hannula; alsa-devel@alsa-project.org
> Subject: Re: [alsa-devel] Radeon unconnected HDMI eats samples at 280 kHz
> 
> 
> 
> On 2014-09-23 16:07, Deucher, Alexander wrote:
> >> -----Original Message-----
> >> From: David Henningsson [mailto:david.henningsson@canonical.com]
> >> Sent: Tuesday, September 23, 2014 5:48 AM
> >> To: Deucher, Alexander; Takashi Iwai
> >> Cc: Anssi Hannula; alsa-devel@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@canonical.com]
> >>>> Sent: Monday, September 22, 2014 10:39 AM
> >>>> To: Deucher, Alexander; Takashi Iwai
> >>>> Cc: Anssi Hannula; alsa-devel@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@canonical.com]
> >>>>>> Sent: Friday, September 19, 2014 8:07 PM
> >>>>>> To: Deucher, Alexander; Takashi Iwai
> >>>>>> Cc: Anssi Hannula; alsa-devel@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.
> 
> But it makes sense that the audio is turned off when the video is, right?

It's a bit complicated.  X effectively just blanks (dpms off) the display when you disconnect it or xrandr --off.  The resources are not actually reclaimed and "disabled" until the next modeset.  I don't think we really want to turn audio off when the display goes into dpms as that will be reported as a disconnect on the audio side even if the display has just gone to sleep.

> 
> Because if first unplug HDMI (nothing happens) and then run "xrandr"
> (without parameters), running that command causes a "re-detection" or
> whatever the correct term is - i e, my DVI screen goes black for a
> second, and afterwards the mouse pointer can no longer move to the other
> non-existent display.
> At that point, audio still remains in the "plugged in" state. Also,
> executing "xrandr --output HDMI-0 --off" has no effect in that state.
> 

The problem is, X just puts the display to sleep when you unplug or xrandr --off.  The current KMS API doesn't really have a notion of "disable".  The actual disabling happens at the next modeset when displays that are no longer in use are disabled and their resources are freed for possible use in the upcoming modeset.  Forcing another modeset with the hdmi disconnected should get the status updated properly.

> >> 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).
> 
> I've now tried these commands:
> 
> radeonreg regset 0x7300 0x001000f0 and
> radeonreg regset 0x7300 0x8f1000f0
> 
> Both commands update the audio side to report either unplugged or
> plugged in, so things seem to work as expected w r t the connection
> between this register and the audio side.

Great.  Looks like we got this one sorted out.

Alex

Re: Radeon unconnected HDMI eats samples at 280 kHz

[David Henningsson]

On 2014-09-24 23:37, Deucher, Alexander wrote:
>> But it makes sense that the audio is turned off when the video is, right?
>
> It's a bit complicated.  X effectively just blanks (dpms off) the display when you disconnect it or xrandr --off.  The resources are not actually reclaimed and "disabled" until the next modeset.  I don't think we really want to turn audio off when the display goes into dpms as that will be reported as a disconnect on the audio side even if the display has just gone to sleep.
>
>>
>> Because if first unplug HDMI (nothing happens) and then run "xrandr"
>> (without parameters), running that command causes a "re-detection" or
>> whatever the correct term is - i e, my DVI screen goes black for a
>> second, and afterwards the mouse pointer can no longer move to the other
>> non-existent display.
>> At that point, audio still remains in the "plugged in" state. Also,
>> executing "xrandr --output HDMI-0 --off" has no effect in that state.
>>
>
> The problem is, X just puts the display to sleep when you unplug or xrandr --off.  The current KMS API doesn't really have a notion of "disable".  The actual disabling happens at the next modeset when displays that are no longer in use are disabled and their resources are freed for possible use in the upcoming modeset.  Forcing another modeset with the hdmi disconnected should get the status updated properly.

I'm not sure how to force a modeset, but just for comparison and for the 
desire of consistency, I did the same test with a laptop with an Intel 
built-in card.

In this case, both plug-in and unplug are responded to immediately on 
both sides, so when the cable is unplugged, the video does a 
"re-detection" which disables the HDMI display, and the audio side 
reports unplugged as well.

Also, executing "xrandr --output HDMI1 --off" while the cable is plugged 
causes the audio side to report unplugged.

I think this behaviour makes sense, but I'm not sure my rank is high 
enough to dictate behaviour. :-)

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

Re: Radeon unconnected HDMI eats samples at 280 kHz

[Deucher, Alexander]

> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson@canonical.com]
> Sent: Tuesday, September 30, 2014 8:25 AM
> To: Deucher, Alexander; Takashi Iwai
> Cc: Anssi Hannula; alsa-devel@alsa-project.org
> Subject: Re: [alsa-devel] Radeon unconnected HDMI eats samples at 280 kHz
> 
> 
> 
> On 2014-09-24 23:37, Deucher, Alexander wrote:
> >> But it makes sense that the audio is turned off when the video is, right?
> >
> > It's a bit complicated.  X effectively just blanks (dpms off) the display when
> you disconnect it or xrandr --off.  The resources are not actually reclaimed
> and "disabled" until the next modeset.  I don't think we really want to turn
> audio off when the display goes into dpms as that will be reported as a
> disconnect on the audio side even if the display has just gone to sleep.
> >
> >>
> >> Because if first unplug HDMI (nothing happens) and then run "xrandr"
> >> (without parameters), running that command causes a "re-detection" or
> >> whatever the correct term is - i e, my DVI screen goes black for a
> >> second, and afterwards the mouse pointer can no longer move to the
> other
> >> non-existent display.
> >> At that point, audio still remains in the "plugged in" state. Also,
> >> executing "xrandr --output HDMI-0 --off" has no effect in that state.
> >>
> >
> > The problem is, X just puts the display to sleep when you unplug or xrandr -
> -off.  The current KMS API doesn't really have a notion of "disable".  The
> actual disabling happens at the next modeset when displays that are no
> longer in use are disabled and their resources are freed for possible use in
> the upcoming modeset.  Forcing another modeset with the hdmi
> disconnected should get the status updated properly.
> 
> I'm not sure how to force a modeset, but just for comparison and for the
> desire of consistency, I did the same test with a laptop with an Intel
> built-in card.
> 
> In this case, both plug-in and unplug are responded to immediately on
> both sides, so when the cable is unplugged, the video does a
> "re-detection" which disables the HDMI display, and the audio side
> reports unplugged as well.
> 
> Also, executing "xrandr --output HDMI1 --off" while the cable is plugged
> causes the audio side to report unplugged.
> 
> I think this behaviour makes sense, but I'm not sure my rank is high
> enough to dictate behaviour. :-)

I agree.  It should be possible (barring figuring out what to do in the multiple-connected-HDMI case), but I don't have the cycles right now to do the necessary rework of the driver to move the audio enable/disable and speaker info fetch into the probe and hotplug code paths.

Alex