[alsa-devel] [PATCH v2] ALSA: hda - re-apply fixup when resuming haswell hdmi codec
tiwai at suse.de
Tue May 7 17:39:10 CEST 2013
At Tue, 7 May 2013 15:33:34 +0000,
Lin, Mengdong wrote:
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai at suse.de]
> > Sent: Tuesday, May 07, 2013 10:16 PM
> > > These widgets need to be enabled before hda_set_power_state(codec,
> > AC_PWRST_D0) programs these widgets to D0.
> > > Otherwise, audio driver would program these disabled widgets to D0. The
> > codec will not respond when audio driver tries to sync power state. And later
> > verb execution will fail.
> > Hm, but this is needed only for the machines with PCI SSID 8086:2010,
> > right? If so, this will be never in market, and I wonder the
> > importance of this fix.
> > So, the question is -- in which situation do we need this fix at all?
> > Isn't it needed for all Haswell, or only certain Haswell variants, or only certain
> > setups?
> This fixup is needed for all Intel Haswell test machines on our hand, including desktop, mobile and ultrabook machines.
But obviously this doesn't match with other vendors (e.g. HP).
> All of these machines has both HDMI and DP connectors and so we need to enable these widgets to use HDMI on the 2nd pin.
> Without this fixup, we observed communication failure between controller and codec after a system suspend/resume.
... and I still see the problem with other vendors. So I suspect the
fix may be really a band-aid over Intel-devel machines but doesn't
help others in the current form.
> The BIOS team told us they will no longer change BIOS for Haswell, and they expect the Linux audio driver to enable the widgets, just like Windows driver does.
> Now we hope to have a BIOS specific fixup.
> Other OEM BIOS may enable the these widgets according to their machine design, or may not if they follow Intel BIOS. This need to be check case by case.
Hmm... your statement worries me pretty much. It sounds like that the
driver won't work as is unless we know what BIOS on each machine does
and how to paper over it. Can't we have a more generic solution?
> > > In hda_call_codec_resume(), generic_hdmi_init() is called from
> > codec->patch_ops.init, after setting power state to D0. It would be too late.
> > > Is it okay to add a new ops like "pre_resume" to apply the fixup?
> > No. Using the standard fixup doesn't look correct in this case.
> > Takashi
More information about the Alsa-devel