[alsa-devel] [PATCH v3 1/1] ALSA: hda - bug fix for invalid connection list of Haswell HDMI codec pins

[Lin, Mengdong]

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