-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, January 15, 2013 7:33 PM
When trying to get Haswell HDMI audio working, I discovered that this verb when executed can get pins to change state from D0 to D3.
Oh, does this verb do it? It's bad.
No, I think these verbs ((0x781 & 0xf81) don't change pin state. So I'm asking David to share more Information.
Also, Mengdong, could you define these verbs (0x781 & 0xf81) in hda_codec.h to understand and read the code better?
Okay, I will.
As the fixup is executed after hda_call_codec_resume this means that the pins will remain in D3. I'm not entirely sure of this, but I think we have no runtime power transitions if we are on AC power, so this could potentially be for a very long time.
Actually you spotted a potential bug -- the code isn't called in the resume callback. This is a code called directly from parse_generic_hdmi(), so it's called only once to override the connections. But the verb 0x781 isn't set.
Yes. intel_haswell_fixup_connect_list() is called only once from parse_generic_hdmi().
I thought we can simply replace the call snd_hda_codec_read(codec, 0x08, 0, 0x781, ...) with snd_hda_codec_write_cache(), so that the same verb will be executed automatically on resume. But, if this verb has any bad side effect (like touching D state), it's no good idea to do it in the cache resume.
But at first, we need to find out whether snd_hda_codec_read (codec, 0x08, 0, 0x781, ...) cannot bring the codec out of D3 before executing 0x781. I suspect it's not the executing the verb but before that that the whole codec (including the pins) enters D3.
Thanks Mengdong