[alsa-devel] [PATCH v3 1/1] ALSA: hda - bug fix for invalid connection list of Haswell HDMI codec pins
mengdong.lin at intel.com
Thu Jan 17 06:32:23 CET 2013
> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai at 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
> 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.
More information about the Alsa-devel