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_DETECTOk, 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 responseOk, 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).