From: David Henningsson <david.henningsson@canonical.com>
To: "Lin, Mengdong" <mengdong.lin@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"Girdwood, Liam R" <liam.r.girdwood@intel.com>
Subject: Re: [PATCH] ALSA: hda - delay resume haswell hdmi codec in system resume
Date: Tue, 09 Apr 2013 11:15:13 +0200 [thread overview]
Message-ID: <5163DC21.9020702@canonical.com> (raw)
In-Reply-To: <F46914AEC2663F4A9BB62374E5EEF8F837A47F@SHSMSX101.ccr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 3738 bytes --]
On 04/09/2013 10:18 AM, Lin, Mengdong wrote:
>> -----Original Message-----
>> From: Takashi Iwai [mailto:tiwai@suse.de]
>> Sent: Tuesday, April 09, 2013 3:43 PM
>> To: David Henningsson
>> Cc: Lin, Mengdong; alsa-devel@alsa-project.org; Girdwood, Liam R
>> Subject: Re: [alsa-devel] [PATCH] ALSA: hda - delay resume haswell hdmi codec
>> in system resume
>
>>>>> I've been answering the power_save questions a little bit uncertain
>>>>> so far, and that's because I don't really know. I've not
>>>>> investigated power management much.
>>>>>
>>>>> But the person with the hardware reports that this problem happens
>>>>> when on AC power only. And that makes sense with your observations
>>>>> about power_save - there could very well be something that turns
>>>>> power_save off when on AC power and on when on battery power.
>>>>>
>>>>> So, if it's just a matter of re-initializing the pin, what do you
>>>>> think about this solution:
>>>>>
>>>>> - Resume as normal (this will enable unsol events)
>>>>> - Any time an unsol event comes in, have a haswell specific
>>>>> function that checks relevant pins to see that is still in D0 and
>>>>> mute state correct. If not, correct it.
>>>>> - This check could possibly also be done in the prepare hook for
>>>>> extra safety.
>>>>
>>>> It won't work reliably. The problem is that the codec might be set
>>>> up wrongly if it's used before the unsol event comes up. For
>>>> example, a PCM resume may be performed immediately after the normal
>>>> resume is finished. Meanwhile the first unsol may arrive much later than
>> that.
>>>
>>> Right, but if this will only mean a few samples (max 300 ms?) will
>>> never reach the HDMI cable, it might be the least bad workaround.
>
> I've tried enabling the unsol event on system resume, the unsol event will arrive in 70~80ms for HDMI and about 10ms for DP.
>
>> It's not only about the missing few samples. The whole setup isn't reliable at
>> that point, and you don't know what to re-setup for the
>> *running* stream.
>>
>>>> Thus we need to delay the resume operation in anyway. And if so,
>>>> there is no merit to perform the normal resume operation at the
>>>> first step.
>>>
>>> The normal resume operation enables unsol events, which is important,
>>> otherwise we don't get the unsol notification from when the gfx
>>> pipeline has finished.
>>
>> It seems that the intrinsic unsol event is always issued once when the unsol
>> event is enabled, according to Intel. So, you won't miss it.
>>
>> But heck, we need more test coverage, obviously.
>>
>>> I guess the question here is how much of the codec setup is really
>>> destroyed by the gfx driver? Is it just a pin in D3 and a right
>>> channel mute, or is it much more that needs to be re-done after the
>>> gfx driver has finished?
>>
>> I'm afraid it's too native to assume that...
>
> Actually, we're not sure how much setting are destroyed, although it seems only the pin power state and mute status are affected.
I made a test patch (attached), sprinkled with printk, and asked the
person with hw to test it. He said it fixed the issue. Now, I'm sure he
did a simple playback test only, rather than having streams running
during S3 or anything like that.
The patch simply sets the pin to D0 and the copies the mute value from
the left channel to the right channel. The printk's confirmed this happened.
But at least it should show that not too much of the settings are
destroyed...or would that be jumping to conclusions too early?
Also, a different thought: what are the possibilities that Mengdong can
fix the gfx driver side not to destroy the settings in the first place?
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
[-- Attachment #2: hsw_d3_workaround.patch --]
[-- Type: text/x-patch, Size: 2276 bytes --]
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index ede8215..edee301 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1018,6 +1018,46 @@ static void hdmi_unsol_event(struct hda_codec *codec, unsigned int res)
hdmi_non_intrinsic_event(codec, res);
}
+static void haswell_verify_pin_D0(struct hda_codec *codec, hda_nid_t nid)
+{
+ int pwr, lamp, ramp;
+ printk("Haswell: Verify pin D0 on pin 0x%x\n", nid);
+
+ pwr = snd_hda_codec_read(codec, nid, 0, AC_VERB_GET_POWER_STATE, 0);
+ pwr = (pwr & AC_PWRST_ACTUAL) >> AC_PWRST_ACTUAL_SHIFT;
+ printk("Haswell: Found pin in state D%d\n", pwr);
+ if (pwr != AC_PWRST_D0) {
+ printk("Haswell: Trying to set power to D0\n");
+ snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_POWER_STATE,
+ AC_PWRST_D0);
+ msleep(40);
+ pwr = snd_hda_codec_read(codec, nid, 0, AC_VERB_GET_POWER_STATE, 0);
+ pwr = (pwr & AC_PWRST_ACTUAL) >> AC_PWRST_ACTUAL_SHIFT;
+ printk("Haswell: Found pin in state D%d\n", pwr);
+ }
+
+ lamp = snd_hda_codec_read(codec, nid, 0,
+ AC_VERB_GET_AMP_GAIN_MUTE,
+ AC_AMP_GET_LEFT | AC_AMP_GET_OUTPUT);
+ ramp = snd_hda_codec_read(codec, nid, 0,
+ AC_VERB_GET_AMP_GAIN_MUTE,
+ AC_AMP_GET_RIGHT | AC_AMP_GET_OUTPUT);
+ printk("Haswell: Verify mute on pin 0x%x: [0x%x 0x%x]\n", nid, lamp, ramp);
+ if (lamp != ramp) {
+ printk("Haswell: Setting r amp mute to l amp mute\n");
+ snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_AMP_GAIN_MUTE,
+ AC_AMP_SET_RIGHT | AC_AMP_SET_OUTPUT | lamp);
+
+ lamp = snd_hda_codec_read(codec, nid, 0,
+ AC_VERB_GET_AMP_GAIN_MUTE,
+ AC_AMP_GET_LEFT | AC_AMP_GET_OUTPUT);
+ ramp = snd_hda_codec_read(codec, nid, 0,
+ AC_VERB_GET_AMP_GAIN_MUTE,
+ AC_AMP_GET_RIGHT | AC_AMP_GET_OUTPUT);
+ printk("Haswell: Mute after set on pin 0x%x: [0x%x 0x%x]\n", nid, lamp, ramp);
+ }
+}
+
/*
* Callbacks
*/
@@ -1032,6 +1072,9 @@ static int hdmi_setup_stream(struct hda_codec *codec, hda_nid_t cvt_nid,
int pinctl;
int new_pinctl = 0;
+ if (codec->vendor_id == 0x80862807)
+ haswell_verify_pin_D0(codec, pin_nid);
+
if (snd_hda_query_pin_caps(codec, pin_nid) & AC_PINCAP_HBR) {
pinctl = snd_hda_codec_read(codec, pin_nid, 0,
AC_VERB_GET_PIN_WIDGET_CONTROL, 0);
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2013-04-09 9:15 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-26 18:12 [PATCH] ALSA: hda - delay resume haswell hdmi codec in system resume mengdong.lin
2013-03-26 7:02 ` Lin, Mengdong
2013-04-02 9:53 ` Takashi Iwai
2013-04-05 16:58 ` Lin, Mengdong
2013-04-07 7:28 ` Takashi Iwai
2013-03-26 10:58 ` David Henningsson
2013-03-27 2:03 ` Lin, Mengdong
2013-03-27 8:19 ` David Henningsson
2013-03-27 10:01 ` Lin, Mengdong
2013-04-02 11:53 ` David Henningsson
2013-04-02 12:18 ` Takashi Iwai
2013-04-02 12:49 ` David Henningsson
2013-04-05 13:01 ` Takashi Iwai
2013-04-05 13:08 ` Takashi Iwai
2013-04-05 16:42 ` Lin, Mengdong
2013-04-05 17:04 ` Takashi Iwai
2013-04-07 0:10 ` Lin, Mengdong
2013-04-08 9:49 ` David Henningsson
2013-04-08 10:24 ` Takashi Iwai
2013-04-08 11:06 ` Lin, Mengdong
2013-04-08 11:35 ` David Henningsson
2013-04-08 11:59 ` Takashi Iwai
2013-04-08 12:20 ` David Henningsson
2013-04-08 12:23 ` Takashi Iwai
2013-04-08 13:30 ` David Henningsson
2013-04-08 13:49 ` Takashi Iwai
2013-04-08 15:47 ` Lin, Mengdong
2013-04-09 6:45 ` David Henningsson
2013-04-09 6:53 ` Takashi Iwai
2013-04-09 7:10 ` David Henningsson
2013-04-09 7:42 ` Takashi Iwai
2013-04-09 8:18 ` Lin, Mengdong
2013-04-09 9:15 ` David Henningsson [this message]
2013-04-09 9:26 ` Takashi Iwai
2013-04-10 5:29 ` David Henningsson
2013-04-10 5:47 ` Takashi Iwai
2013-04-10 6:02 ` David Henningsson
2013-04-10 6:52 ` Takashi Iwai
2013-04-10 10:38 ` David Henningsson
2013-04-14 13:48 ` Lin, Mengdong
2013-04-15 7:02 ` David Henningsson
2013-04-15 7:48 ` Lin, Mengdong
2013-04-17 5:51 ` David Henningsson
2013-04-17 6:12 ` Takashi Iwai
2013-05-03 6:56 ` Lin, Mengdong
2013-05-03 7:20 ` David Henningsson
2013-05-03 7:30 ` Lin, Mengdong
2013-05-06 6:27 ` Lin, Mengdong
2013-05-06 7:08 ` David Henningsson
2013-05-06 9:48 ` Lin, Mengdong
2013-04-05 13:06 ` Takashi Iwai
2013-04-05 13:12 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5163DC21.9020702@canonical.com \
--to=david.henningsson@canonical.com \
--cc=alsa-devel@alsa-project.org \
--cc=liam.r.girdwood@intel.com \
--cc=mengdong.lin@intel.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.