[alsa-devel] regression: from 3.8 to 3.9: headphones output no sound on Intel HDA, codec VIA VT1802
Hi,
I just noticed (use the headphones rarely) that the headphones on this System76 Lemur Ultra (lemu4) stopped working. There is absolutely no output.
I tried reverting all changes to patch_via.c since v3.8, and have the sound back, but there wasn't much to revert:
Revert "ALSA: hda - Rearrange INPUT_PIN_ATTR_*" Revert "ALSA: hda - Use generic parser for VIA codec driver" Revert "ALSA: hda - Enable parsing the independent HP mode as default for VIA codecs" Revert "ALSA: hda/via - Fix wrong checks of power state bits" Revert "ALSA: hda - Fix phantom jacks on VT1708" Revert "ALSA: hda - detect jacks on VT1708 even when no streams are active" Revert "ALSA: hda - Use generic array for loopback list management"
and one change (which I indeed suspect) is large: the use of generic parser.
The problem is also present in 3.10-rc1. The output of alsa-info.sh attached, for 3.8.12 and 3.9.2 respectively.
Regards, Alex Riesen
The original message is being held hostage by moderator approval. The attachments (alsa-info output) can be found here:
http://marc.info/?l=linux-kernel&m=136835246706699&w=2
---------- Forwarded message ----------
Hi,
I just noticed (use the headphones rarely) that the headphones on this System76 Lemur Ultra (lemu4) stopped working. There is absolutely no output.
I tried reverting all changes to patch_via.c since v3.8, and have the sound back, but there wasn't much to revert:
Revert "ALSA: hda - Rearrange INPUT_PIN_ATTR_*" Revert "ALSA: hda - Use generic parser for VIA codec driver" Revert "ALSA: hda - Enable parsing the independent HP mode as default for VIA codecs" Revert "ALSA: hda/via - Fix wrong checks of power state bits" Revert "ALSA: hda - Fix phantom jacks on VT1708" Revert "ALSA: hda - detect jacks on VT1708 even when no streams are active" Revert "ALSA: hda - Use generic array for loopback list management"
and one change (which I indeed suspect) is large: the use of generic parser.
The problem is also present in 3.10-rc1. The output of alsa-info.sh attached, for 3.8.12 and 3.9.2 respectively.
Regards, Alex Riesen
At Sun, 12 May 2013 11:53:41 +0200, Alex Riesen wrote:
Hi,
I just noticed (use the headphones rarely) that the headphones on this System76 Lemur Ultra (lemu4) stopped working. There is absolutely no output.
I tried reverting all changes to patch_via.c since v3.8, and have the sound back, but there wasn't much to revert:
Revert "ALSA: hda - Rearrange INPUT_PIN_ATTR_*" Revert "ALSA: hda - Use generic parser for VIA codec driver" Revert "ALSA: hda - Enable parsing the independent HP mode as default for VIA codecs" Revert "ALSA: hda/via - Fix wrong checks of power state bits" Revert "ALSA: hda - Fix phantom jacks on VT1708" Revert "ALSA: hda - detect jacks on VT1708 even when no streams are active" Revert "ALSA: hda - Use generic array for loopback list management"
and one change (which I indeed suspect) is large: the use of generic parser.
The problem is also present in 3.10-rc1. The output of alsa-info.sh attached, for 3.8.12 and 3.9.2 respectively.
It's strange that the pin 0x25 shows EAPD 0x00 and pin-control 0x00. They should be 0x02 and 0xc0 constantly. Is it taken at the moment the headphone is plugged, right? Please give alsa-info.sh outputs at both the headphone plugged and unplugged.
Could you check whether changing them makes the headphone output working? For example, get hda-verb program (see Documentation/sound/alsa/HD-Audio.txt) and run it like
hda-verb /dev/snd/hwC0D0 0x25 SET_PIN_WID 0xc0 hda-verb /dev/snd/hwC0D0 0x25 SET_EAPD 0x02
thanks,
Takashi
At Mon, 13 May 2013 17:26:04 +0200, Takashi Iwai wrote:
At Sun, 12 May 2013 11:53:41 +0200, Alex Riesen wrote:
Hi,
I just noticed (use the headphones rarely) that the headphones on this System76 Lemur Ultra (lemu4) stopped working. There is absolutely no output.
I tried reverting all changes to patch_via.c since v3.8, and have the sound back, but there wasn't much to revert:
Revert "ALSA: hda - Rearrange INPUT_PIN_ATTR_*" Revert "ALSA: hda - Use generic parser for VIA codec driver" Revert "ALSA: hda - Enable parsing the independent HP mode as default for VIA codecs" Revert "ALSA: hda/via - Fix wrong checks of power state bits" Revert "ALSA: hda - Fix phantom jacks on VT1708" Revert "ALSA: hda - detect jacks on VT1708 even when no streams are active" Revert "ALSA: hda - Use generic array for loopback list management"
and one change (which I indeed suspect) is large: the use of generic parser.
The problem is also present in 3.10-rc1. The output of alsa-info.sh attached, for 3.8.12 and 3.9.2 respectively.
It's strange that the pin 0x25 shows EAPD 0x00 and pin-control 0x00. They should be 0x02 and 0xc0 constantly. Is it taken at the moment the headphone is plugged, right? Please give alsa-info.sh outputs at both the headphone plugged and unplugged.
Could you check whether changing them makes the headphone output working? For example, get hda-verb program (see Documentation/sound/alsa/HD-Audio.txt) and run it like
hda-verb /dev/snd/hwC0D0 0x25 SET_PIN_WID 0xc0 hda-verb /dev/snd/hwC0D0 0x25 SET_EAPD 0x02
Also, what happens if you apply the patch below?
thanks,
Takashi
--- diff --git a/sound/pci/hda/patch_via.c b/sound/pci/hda/patch_via.c index e0dadcf..13ed791 100644 --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -1561,7 +1561,7 @@ static int patch_vt2002P(struct hda_codec *codec)
codec->patch_ops = via_patch_ops;
- spec->set_widgets_power_state = set_widgets_power_state_vt2002P; + //spec->set_widgets_power_state = set_widgets_power_state_vt2002P; return 0; }
On Mon, May 13, 2013 at 5:53 PM, Takashi Iwai tiwai@suse.de wrote:
At Mon, 13 May 2013 17:26:04 +0200, Takashi Iwai wrote:
At Sun, 12 May 2013 11:53:41 +0200, Alex Riesen wrote:
I just noticed (use the headphones rarely) that the headphones on this System76 Lemur Ultra (lemu4) stopped working. There is absolutely no output.
It's strange that the pin 0x25 shows EAPD 0x00 and pin-control 0x00. They should be 0x02 and 0xc0 constantly. Is it taken at the moment the headphone is plugged, right? Please give alsa-info.sh outputs at both the headphone plugged and unplugged.
Attached. Sorry for gzipping, the alsa-devel rejects two at a time: too large.
Could you check whether changing them makes the headphone output working? For example, get hda-verb program (see Documentation/sound/alsa/HD-Audio.txt) and run it like
hda-verb /dev/snd/hwC0D0 0x25 SET_PIN_WID 0xc0 hda-verb /dev/snd/hwC0D0 0x25 SET_EAPD 0x02
It helps, headphones start working.
Also, what happens if you apply the patch below?
spec->set_widgets_power_state = set_widgets_power_state_vt2002P;
//spec->set_widgets_power_state = set_widgets_power_state_vt2002P;
This helps as well. Yay! Thanks :) Whatever the outcome, I have them back more or less (more, for me) properly.
Probably unrelated, but I better mention it anyway: the "Auto-Mute Mode" works strangely, it never mutes anything but headphones. It might work as designed, but it is useless in this case: one still has to mute the speaker manually when plugging headphones (or do something with input events, which I failed to get to work).
And "Independent HP" has absolutely no effect, which is probably as it should be on this laptop.
At Mon, 13 May 2013 20:24:42 +0200, Alex Riesen wrote:
On Mon, May 13, 2013 at 5:53 PM, Takashi Iwai tiwai@suse.de wrote:
At Mon, 13 May 2013 17:26:04 +0200, Takashi Iwai wrote:
At Sun, 12 May 2013 11:53:41 +0200, Alex Riesen wrote:
I just noticed (use the headphones rarely) that the headphones on this System76 Lemur Ultra (lemu4) stopped working. There is absolutely no output.
It's strange that the pin 0x25 shows EAPD 0x00 and pin-control 0x00. They should be 0x02 and 0xc0 constantly. Is it taken at the moment the headphone is plugged, right? Please give alsa-info.sh outputs at both the headphone plugged and unplugged.
Attached. Sorry for gzipping, the alsa-devel rejects two at a time: too large.
Could you check whether changing them makes the headphone output working? For example, get hda-verb program (see Documentation/sound/alsa/HD-Audio.txt) and run it like
hda-verb /dev/snd/hwC0D0 0x25 SET_PIN_WID 0xc0 hda-verb /dev/snd/hwC0D0 0x25 SET_EAPD 0x02It helps, headphones start working.
Also, what happens if you apply the patch below?
spec->set_widgets_power_state = set_widgets_power_state_vt2002P;
//spec->set_widgets_power_state = set_widgets_power_state_vt2002P;This helps as well. Yay! Thanks :) Whatever the outcome, I have them back more or less (more, for me) properly.
OK, then we know the place to fix now. Try the patch below instead. Does it fix the problem as well?
Probably unrelated, but I better mention it anyway: the "Auto-Mute Mode" works strangely, it never mutes anything but headphones. It might work as designed, but it is useless in this case: one still has to mute the speaker manually when plugging headphones (or do something with input events, which I failed to get to work).
Does the problem still happen with the patch?
And "Independent HP" has absolutely no effect, which is probably as it should be on this laptop.
With the independent HP turned on, there should be no output to the headphone through the normal PCM. There is a secondary PCM device, and this is routed to the headphone when the independent HP is on.
thanks,
Takashi
--- diff --git a/sound/pci/hda/patch_via.c b/sound/pci/hda/patch_via.c index e0dadcf..09fd395 100644 --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -1410,6 +1410,7 @@ static void set_widgets_power_state_vt2002P(struct hda_codec *codec) /* outputs */ /* AOW0 (8h)*/ update_power_state(codec, 0x8, parm); + update_power_state(codec, 0x9, parm);
if (spec->codec_type == VT1802) { /* PW4 (28h), MW4 (18h), MUX4(38h) */ @@ -1439,16 +1440,14 @@ static void set_widgets_power_state_vt2002P(struct hda_codec *codec) update_power_state(codec, 0x35, parm); }
- if (spec->gen.indep_hp_enabled) - update_power_state(codec, 0x9, AC_PWRST_D0); - /* Class-D */ /* PW0 (24h), MW0(18h/14h), MUX0(34h) */ present = snd_hda_jack_detect(codec, 0x25);
parm = AC_PWRST_D3; set_pin_power_state(codec, 0x24, &parm); - parm = present ? AC_PWRST_D3 : AC_PWRST_D0; + if (parm == AC_PWRST_D0) + parm = present ? AC_PWRST_D3 : AC_PWRST_D0; if (spec->codec_type == VT1802) update_power_state(codec, 0x14, parm); else
At Tue, 14 May 2013 07:59:07 +0200, Takashi Iwai wrote:
At Mon, 13 May 2013 20:24:42 +0200, Alex Riesen wrote:
On Mon, May 13, 2013 at 5:53 PM, Takashi Iwai tiwai@suse.de wrote:
At Mon, 13 May 2013 17:26:04 +0200, Takashi Iwai wrote:
At Sun, 12 May 2013 11:53:41 +0200, Alex Riesen wrote:
I just noticed (use the headphones rarely) that the headphones on this System76 Lemur Ultra (lemu4) stopped working. There is absolutely no output.
It's strange that the pin 0x25 shows EAPD 0x00 and pin-control 0x00. They should be 0x02 and 0xc0 constantly. Is it taken at the moment the headphone is plugged, right? Please give alsa-info.sh outputs at both the headphone plugged and unplugged.
Attached. Sorry for gzipping, the alsa-devel rejects two at a time: too large.
Could you check whether changing them makes the headphone output working? For example, get hda-verb program (see Documentation/sound/alsa/HD-Audio.txt) and run it like
hda-verb /dev/snd/hwC0D0 0x25 SET_PIN_WID 0xc0 hda-verb /dev/snd/hwC0D0 0x25 SET_EAPD 0x02It helps, headphones start working.
Also, what happens if you apply the patch below?
spec->set_widgets_power_state = set_widgets_power_state_vt2002P;
//spec->set_widgets_power_state = set_widgets_power_state_vt2002P;This helps as well. Yay! Thanks :) Whatever the outcome, I have them back more or less (more, for me) properly.
OK, then we know the place to fix now. Try the patch below instead. Does it fix the problem as well?
The below is the revised patch, fixing not only for VT1802 but other VIA codecs, too. Please let me know if it works.
thanks,
Takashi
--- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Fix wrong power setup for HP paths of VIA codecs
The set_widgets_power_state_*() callbacks in patch_via.c are converted to evaluate spec->gen.indep_hp_enabled when the codec parser was switched to use the generic parser. However, the generic parser takes the headphone paths in a different way as the original VIA parser; it tries the paths with individual DACs as much as possible. This ended up with the incorrect check of the power status in the HP paths, resulting in the silent output from the headphones.
This patch removes the invalid check of indep_hp_enabled flag and sets the proper power status for those paths.
Reported-by: Alex Riesen raa.lkml@gmail.com Cc: stable@vger.kernel.org [v3.9+] Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/pci/hda/patch_via.c | 41 +++++++++++++++-------------------------- 1 file changed, 15 insertions(+), 26 deletions(-)
diff --git a/sound/pci/hda/patch_via.c b/sound/pci/hda/patch_via.c index e0dadcf..c74e1a1 100644 --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -856,7 +856,7 @@ static void set_widgets_power_state_vt1708B(struct hda_codec *codec) if (is_8ch) { update_power_state(codec, 0x25, parm); update_power_state(codec, 0x27, parm); - } else if (codec->vendor_id == 0x11064397 && spec->gen.indep_hp_enabled) + } else if (codec->vendor_id == 0x11064397) update_power_state(codec, 0x25, parm); }
@@ -1042,7 +1042,6 @@ static const struct hda_verb vt1718S_init_verbs[] = {
static void set_widgets_power_state_vt1718S(struct hda_codec *codec) { - struct via_spec *spec = codec->spec; int imux_is_smixer; unsigned int parm, parm2; /* MUX6 (1eh) = stereo mixer */ @@ -1079,10 +1078,9 @@ static void set_widgets_power_state_vt1718S(struct hda_codec *codec) /* PW0 (24h), AOW0 (8h) */ parm = AC_PWRST_D3; set_pin_power_state(codec, 0x24, &parm); - if (!spec->gen.indep_hp_enabled) /* check for redirected HP */ - set_pin_power_state(codec, 0x28, &parm); + set_pin_power_state(codec, 0x28, &parm); update_power_state(codec, 0x8, parm); - if (!spec->gen.indep_hp_enabled && parm2 != AC_PWRST_D3) + if (parm2 != AC_PWRST_D3) parm = parm2; update_power_state(codec, 0xb, parm); /* MW9 (21h), Mw2 (1ah), AOW0 (8h) */ @@ -1095,14 +1093,12 @@ static void set_widgets_power_state_vt1718S(struct hda_codec *codec) set_pin_power_state(codec, 0x2a, &parm); update_power_state(codec, 0x9, parm);
- if (spec->gen.indep_hp_enabled) { - /* PW4 (28h), MW3 (1bh), MUX1(34h), AOW4 (ch) */ - parm = AC_PWRST_D3; - set_pin_power_state(codec, 0x28, &parm); - update_power_state(codec, 0x1b, parm); - update_power_state(codec, 0x34, parm); - update_power_state(codec, 0xc, parm); - } + /* PW4 (28h), MW3 (1bh), MUX1(34h), AOW4 (ch) */ + parm = AC_PWRST_D3; + set_pin_power_state(codec, 0x28, &parm); + update_power_state(codec, 0x1b, parm); + update_power_state(codec, 0x34, parm); + update_power_state(codec, 0xc, parm); }
/* Add a connection to the primary DAC from AA-mixer for some codecs @@ -1307,7 +1303,7 @@ static void set_widgets_power_state_vt1716S(struct hda_codec *codec) mono_out = 0; else { present = snd_hda_jack_detect(codec, 0x1d); - if (!spec->gen.indep_hp_enabled && present) + if (present) mono_out = 0; else mono_out = 1; @@ -1321,9 +1317,7 @@ static void set_widgets_power_state_vt1716S(struct hda_codec *codec) parm = AC_PWRST_D3; set_pin_power_state(codec, 0x1c, &parm); set_pin_power_state(codec, 0x1d, &parm); - /* HP Independent Mode, power on AOW3 */ - if (spec->gen.indep_hp_enabled) - update_power_state(codec, 0x25, parm); + update_power_state(codec, 0x25, parm);
/* force to D0 for internal Speaker */ /* MW0 (16h), AOW0 (10h) */ @@ -1410,6 +1404,7 @@ static void set_widgets_power_state_vt2002P(struct hda_codec *codec) /* outputs */ /* AOW0 (8h)*/ update_power_state(codec, 0x8, parm); + update_power_state(codec, 0x9, parm);
if (spec->codec_type == VT1802) { /* PW4 (28h), MW4 (18h), MUX4(38h) */ @@ -1439,9 +1434,6 @@ static void set_widgets_power_state_vt2002P(struct hda_codec *codec) update_power_state(codec, 0x35, parm); }
- if (spec->gen.indep_hp_enabled) - update_power_state(codec, 0x9, AC_PWRST_D0); - /* Class-D */ /* PW0 (24h), MW0(18h/14h), MUX0(34h) */ present = snd_hda_jack_detect(codec, 0x25); @@ -1577,7 +1569,6 @@ static const struct hda_verb vt1812_init_verbs[] = {
static void set_widgets_power_state_vt1812(struct hda_codec *codec) { - struct via_spec *spec = codec->spec; unsigned int parm; unsigned int present; /* inputs */ @@ -1596,6 +1587,7 @@ static void set_widgets_power_state_vt1812(struct hda_codec *codec) /* outputs */ /* AOW0 (8h)*/ update_power_state(codec, 0x8, AC_PWRST_D0); + update_power_state(codec, 0x9, AC_PWRST_D0);
/* PW4 (28h), MW4 (18h), MUX4(38h) */ parm = AC_PWRST_D3; @@ -1608,8 +1600,6 @@ static void set_widgets_power_state_vt1812(struct hda_codec *codec) set_pin_power_state(codec, 0x25, &parm); update_power_state(codec, 0x15, parm); update_power_state(codec, 0x35, parm); - if (spec->gen.indep_hp_enabled) - update_power_state(codec, 0x9, AC_PWRST_D0);
/* Internal Speaker */ /* PW0 (24h), MW0(14h), MUX0(34h) */ @@ -1756,15 +1746,14 @@ static void set_widgets_power_state_vt3476(struct hda_codec *codec) set_pin_power_state(codec, 0x28, &parm); update_power_state(codec, 0x38, parm); update_power_state(codec, 0x18, parm); - if (spec->gen.indep_hp_enabled) - update_conv_power_state(codec, 0xb, parm, 3); + update_conv_power_state(codec, 0xb, parm, 3); parm2 = parm; /* for pin 0x0b */
/* PW0 (24h), MW0(34h), MW9(3fh), AOW0 (8h) */ parm = AC_PWRST_D3; set_pin_power_state(codec, 0x24, &parm); update_power_state(codec, 0x34, parm); - if (!spec->gen.indep_hp_enabled && parm2 != AC_PWRST_D3) + if (parm2 != AC_PWRST_D3) parm = parm2; update_conv_power_state(codec, 0x8, parm, 0); /* MW9 (21h), Mw2 (1ah), AOW0 (8h) */
On Tue, May 14, 2013 at 12:58 PM, Takashi Iwai tiwai@suse.de wrote:
OK, then we know the place to fix now. Try the patch below instead. Does it fix the problem as well?
The below is the revised patch, fixing not only for VT1802 but other VIA codecs, too. Please let me know if it works.
With this patch headphones work, but Auto-Mute is inverted, as it was before.
Regards, Alex
At Tue, 14 May 2013 21:55:43 +0200, Alex Riesen wrote:
On Tue, May 14, 2013 at 12:58 PM, Takashi Iwai tiwai@suse.de wrote:
OK, then we know the place to fix now. Try the patch below instead. Does it fix the problem as well?
The below is the revised patch, fixing not only for VT1802 but other VIA codecs, too. Please let me know if it works.
With this patch headphones work, but Auto-Mute is inverted, as it was before.
OK, could you give again alsa-info.sh outputs at HP plugged and unplugged?
thanks,
Takashi
On Wed, May 15, 2013 at 7:20 AM, Takashi Iwai tiwai@suse.de wrote:
The below is the revised patch, fixing not only for VT1802 but other VIA codecs, too. Please let me know if it works.
With this patch headphones work, but Auto-Mute is inverted, as it was before.
OK, could you give again alsa-info.sh outputs at HP plugged and unplugged?
Attached.
Sadly, I must have made a mistake when testing last time (either that, or it broke all by itself): the revised patch also does not work, same as the previous: no output at all, even on the alternate PCM.
Regards, Alex
At Wed, 15 May 2013 22:17:23 +0200, Alex Riesen wrote:
On Wed, May 15, 2013 at 7:20 AM, Takashi Iwai tiwai@suse.de wrote:
The below is the revised patch, fixing not only for VT1802 but other VIA codecs, too. Please let me know if it works.
With this patch headphones work, but Auto-Mute is inverted, as it was before.
OK, could you give again alsa-info.sh outputs at HP plugged and unplugged?
Attached.
Sadly, I must have made a mistake when testing last time (either that, or it broke all by itself): the revised patch also does not work, same as the previous: no output at all, even on the alternate PCM.
Ah, then the attached files are basically useless, unfortunately.
So, we need to disable the widgets power control in patch_via.c completely as a quick workaround. Could you check whether the patch below is OK (except for the possible headphone mute issue)?
Regarding the headphone mute: after confirming the headphone itself is working with the patch, please give alsa-info.sh outputs again with and without the headphone plug.
Then, at the headphone plugged (and the speaker is still audible wrongly), take a look at /proc/asound/card0/codec#0 file. Look for "Node 0x24", and check whether Pin-ctls item shows 0x00. If 0x00, it means that the driver behaves correctly, but the hardware reacts unexpectedly -- it produces the sound even though the pin control is cleared. OTOH, if it's 0x40, then the driver didn't do it right.
In the former case (0x00), try to run like:
hda-verb /dev/snd/hwC0D0 0x24 SET_EAPD 0x01
Does it mute the speaker? If not, make it back via
hda-verb /dev/snd/hwC0D0 0x24 SET_EAPD 0x03
then turn to D3 via
hda-verb /dev/snd/hwC0D0 0x24 SET_POWER 0x03
Does this mute? In return, after unplug, it may still be muted. In that case, try to power up the pin again via
hda-verb /dev/snd/hwC0D0 0x24 SET_POWER 0x00
thanks,
Takashi
--- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Disable broken PM setup for VIA codecs
The set_widgets_power_state_*() callbacks in patch_via.c are converted to evaluate spec->gen.indep_hp_enabled when the codec parser was switched to use the generic parser. However, the generic parser takes the headphone paths in a different way as the original VIA parser; it tries the paths with individual DACs as much as possible. This ended up with the incorrect check of the power status in the HP paths, resulting in the silent output from the headphones.
As a band-aid fix, temporarily disable the callback calls.
Reported-by: Alex Riesen raa.lkml@gmail.com Cc: stable@vger.kernel.org [v3.9+] Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/pci/hda/patch_via.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/sound/pci/hda/patch_via.c b/sound/pci/hda/patch_via.c index e0dadcf..7ee44a2 100644 --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -231,9 +231,11 @@ static void vt1708_update_hp_work(struct hda_codec *codec)
static void set_widgets_power_state(struct hda_codec *codec) { +#if 0 /* FIXME: mismatching with the mapping by the generic parser */ struct via_spec *spec = codec->spec; if (spec->set_widgets_power_state) spec->set_widgets_power_state(codec); +#endif }
static void update_power_state(struct hda_codec *codec, hda_nid_t nid,
On Thu, May 16, 2013 at 1:00 PM, Takashi Iwai tiwai@suse.de wrote:
So, we need to disable the widgets power control in patch_via.c completely as a quick workaround. Could you check whether the patch below is OK (except for the possible headphone mute issue)?
Well... It seems that something went unnoticed. This command seems to be essential for this (and the revised) patch to get the headphone output at all:
hda-verb /dev/snd/hwC0D0 0x25 SET_PIN_WID 0xc0
I also used to run the other command after unplugging and re-plugging (without it, the headphone is muted after re-plugging):
hda-verb /dev/snd/hwC0D0 0x25 SET_EAPD 0x02
But running
hda-verb /dev/snd/hwC0D0 0x24 SET_EAPD 0x03
also helps to restore the headphone output after re-plugging.
Regarding the headphone mute: after confirming the headphone itself is working with the patch, please give alsa-info.sh outputs again with and without the headphone plug.
Attached.
Then, at the headphone plugged (and the speaker is still audible wrongly), take a look at /proc/asound/card0/codec#0 file. Look for "Node 0x24", and check whether Pin-ctls item shows 0x00.
It does. And there is no output from the speakers.
In the former case (0x00), try to run like:
hda-verb /dev/snd/hwC0D0 0x24 SET_EAPD 0x01
Does it mute the speaker? If not, make it back via
The speaker is muted with this patch, when I plug the headphone.
hda-verb /dev/snd/hwC0D0 0x24 SET_EAPD 0x03
And this command will turn it on, but only if I also activate "Independent Headphone".
then turn to D3 via
hda-verb /dev/snd/hwC0D0 0x24 SET_POWER 0x03
Does this mute? In return, after unplug, it may still be muted.
These command seem to have no effect at all.
Regards, Alex
At Thu, 16 May 2013 22:10:47 +0200, Alex Riesen wrote:
On Thu, May 16, 2013 at 1:00 PM, Takashi Iwai tiwai@suse.de wrote:
So, we need to disable the widgets power control in patch_via.c completely as a quick workaround. Could you check whether the patch below is OK (except for the possible headphone mute issue)?
Well... It seems that something went unnoticed. This command seems to be essential for this (and the revised) patch to get the headphone output at all:
hda-verb /dev/snd/hwC0D0 0x25 SET_PIN_WID 0xc0
Do you mean that the headphone doesn't work without this even after the patch? It's weird that the alsa-info.sh output you attached below already contains it, i.e. 0x25 showing 0xc0.
Or, is the attached output the result after you ran hda-verb like the above?
I also used to run the other command after unplugging and re-plugging (without it, the headphone is muted after re-plugging):
hda-verb /dev/snd/hwC0D0 0x25 SET_EAPD 0x02But running
hda-verb /dev/snd/hwC0D0 0x24 SET_EAPD 0x03also helps to restore the headphone output after re-plugging.
Regarding the headphone mute: after confirming the headphone itself is working with the patch, please give alsa-info.sh outputs again with and without the headphone plug.
Attached.
Then, at the headphone plugged (and the speaker is still audible wrongly), take a look at /proc/asound/card0/codec#0 file. Look for "Node 0x24", and check whether Pin-ctls item shows 0x00.
It does. And there is no output from the speakers.
Hmm. I'm confused. I thought you mentioned that the speaker is unmuted?
- Use the patched kernel, play without headphone, confirm that the speaker works. Get alsa-info.sh output at this point.
- Plug the headphone, play, and check whether the headphone works and the speaker is muted. Again, get alsa-info.sh output at this point, no matter whether the headphone works or not.
If something is wrong at this point, try hda-verb things. Basically, giving some verbs to 0x25 is to work on the headphone, and 0x24 for the speaker. You can check the previous value by the corresponding GET_* verb. For example, if you want to change the pin control of 0x25 to 0xc0, check the current value by
hda-verb /dev/snd/hwC0D0 0x25 GET_PIN_WID 0
(the GET_* takes the last argument 0), then
hda-verb /dev/snd/hwC0D0 0x25 SET_PIN_WID 0xc0
I'm asking it because, in the case above, if the previous value shows 0xc0 and the headphone doesn't work, and if setting the same value again fixes the headphone output, it must be new behavior I've never seen.
In anyway, if you make things working, please give exactly what you did, and take again alsa-info.sh output, too.
thanks,
Takashi
Sorry for delayed replies. I have not much time for this lately.
On Fri, May 17, 2013 at 8:04 AM, Takashi Iwai tiwai@suse.de wrote:
Well... It seems that something went unnoticed. This command seems to be essential for this (and the revised) patch to get the headphone output at all:
hda-verb /dev/snd/hwC0D0 0x25 SET_PIN_WID 0xc0Do you mean that the headphone doesn't work without this even after the patch? It's weird that the alsa-info.sh output you attached below already contains it, i.e. 0x25 showing 0xc0.
Yes. It is after the latest patch.
Or, is the attached output the result after you ran hda-verb like the above?
Er, yes.
It does. And there is no output from the speakers.
Hmm. I'm confused. I thought you mentioned that the speaker is unmuted?
I think I am as confused as you, if not more. I redid the tests but recorded everything this time with script(1). It is without timing information (would be boring anyway, with me figuring the arguments), so just cat it. Just in case: it sets xterm title. The transcript is in headphone.gz.
- Use the patched kernel, play without headphone, confirm that the speaker works. Get alsa-info.sh output at this point.
That's 3.9.2-wo-headphone.alsa.gz
- Plug the headphone, play, and check whether the headphone works and the speaker is muted. Again, get alsa-info.sh output at this point, no matter whether the headphone works or not.
That's 3.9.2-w-headphone.alsa.gz. Headphone not working, speakers correctly muted.
In anyway, if you make things working, please give exactly what you did, and take again alsa-info.sh output, too.
3.9.2-w-headphone-working.alsa.gz. The working state is lost after unplugging and replugging the headphones. It is different to the case when the alternate channel is used (Independent HP): replugging does not break the output than.
Sorry for confusion and thanks!
Regards, Alex
Ping? Can I do something for you?
Regards, Alex
On Sat, May 18, 2013 at 10:29 PM, Alex Riesen raa.lkml@gmail.com wrote:
Sorry for delayed replies. I have not much time for this lately.
On Fri, May 17, 2013 at 8:04 AM, Takashi Iwai tiwai@suse.de wrote:
Well... It seems that something went unnoticed. This command seems to be essential for this (and the revised) patch to get the headphone output at all:
hda-verb /dev/snd/hwC0D0 0x25 SET_PIN_WID 0xc0Do you mean that the headphone doesn't work without this even after the patch? It's weird that the alsa-info.sh output you attached below already contains it, i.e. 0x25 showing 0xc0.
Yes. It is after the latest patch.
Or, is the attached output the result after you ran hda-verb like the above?
Er, yes.
It does. And there is no output from the speakers.
Hmm. I'm confused. I thought you mentioned that the speaker is unmuted?
I think I am as confused as you, if not more. I redid the tests but recorded everything this time with script(1). It is without timing information (would be boring anyway, with me figuring the arguments), so just cat it. Just in case: it sets xterm title. The transcript is in headphone.gz.
- Use the patched kernel, play without headphone, confirm that the speaker works. Get alsa-info.sh output at this point.
That's 3.9.2-wo-headphone.alsa.gz
- Plug the headphone, play, and check whether the headphone works and the speaker is muted. Again, get alsa-info.sh output at this point, no matter whether the headphone works or not.
That's 3.9.2-w-headphone.alsa.gz. Headphone not working, speakers correctly muted.
In anyway, if you make things working, please give exactly what you did, and take again alsa-info.sh output, too.
3.9.2-w-headphone-working.alsa.gz. The working state is lost after unplugging and replugging the headphones. It is different to the case when the alternate channel is used (Independent HP): replugging does not break the output than.
Sorry for confusion and thanks!
Regards, Alex
At Wed, 22 May 2013 23:06:53 +0200, Alex Riesen wrote:
Ping? Can I do something for you?
Sorry, no time for now. I'll take a look at this again tomorrow or in the next week.
Takashi
Regards, Alex
On Sat, May 18, 2013 at 10:29 PM, Alex Riesen raa.lkml@gmail.com wrote:
Sorry for delayed replies. I have not much time for this lately.
On Fri, May 17, 2013 at 8:04 AM, Takashi Iwai tiwai@suse.de wrote:
Well... It seems that something went unnoticed. This command seems to be essential for this (and the revised) patch to get the headphone output at all:
hda-verb /dev/snd/hwC0D0 0x25 SET_PIN_WID 0xc0Do you mean that the headphone doesn't work without this even after the patch? It's weird that the alsa-info.sh output you attached below already contains it, i.e. 0x25 showing 0xc0.
Yes. It is after the latest patch.
Or, is the attached output the result after you ran hda-verb like the above?
Er, yes.
It does. And there is no output from the speakers.
Hmm. I'm confused. I thought you mentioned that the speaker is unmuted?
I think I am as confused as you, if not more. I redid the tests but recorded everything this time with script(1). It is without timing information (would be boring anyway, with me figuring the arguments), so just cat it. Just in case: it sets xterm title. The transcript is in headphone.gz.
- Use the patched kernel, play without headphone, confirm that the speaker works. Get alsa-info.sh output at this point.
That's 3.9.2-wo-headphone.alsa.gz
- Plug the headphone, play, and check whether the headphone works and the speaker is muted. Again, get alsa-info.sh output at this point, no matter whether the headphone works or not.
That's 3.9.2-w-headphone.alsa.gz. Headphone not working, speakers correctly muted.
In anyway, if you make things working, please give exactly what you did, and take again alsa-info.sh output, too.
3.9.2-w-headphone-working.alsa.gz. The working state is lost after unplugging and replugging the headphones. It is different to the case when the alternate channel is used (Independent HP): replugging does not break the output than.
Sorry for confusion and thanks!
Regards, Alex
On Thu, May 23, 2013 at 6:34 PM, Takashi Iwai tiwai@suse.de wrote:
At Wed, 22 May 2013 23:06:53 +0200, Alex Riesen wrote:
Ping? Can I do something for you?
Sorry, no time for now. I'll take a look at this again tomorrow or in the next week.
Ah, ok. I can understand.
Regards, Alex
At Sat, 18 May 2013 22:29:57 +0200, Alex Riesen wrote:
Sorry for delayed replies. I have not much time for this lately.
On Fri, May 17, 2013 at 8:04 AM, Takashi Iwai tiwai@suse.de wrote:
Well... It seems that something went unnoticed. This command seems to be essential for this (and the revised) patch to get the headphone output at all:
hda-verb /dev/snd/hwC0D0 0x25 SET_PIN_WID 0xc0Do you mean that the headphone doesn't work without this even after the patch? It's weird that the alsa-info.sh output you attached below already contains it, i.e. 0x25 showing 0xc0.
Yes. It is after the latest patch.
Or, is the attached output the result after you ran hda-verb like the above?
Er, yes.
It does. And there is no output from the speakers.
Hmm. I'm confused. I thought you mentioned that the speaker is unmuted?
I think I am as confused as you, if not more. I redid the tests but recorded everything this time with script(1). It is without timing information (would be boring anyway, with me figuring the arguments), so just cat it. Just in case: it sets xterm title. The transcript is in headphone.gz.
- Use the patched kernel, play without headphone, confirm that the speaker works. Get alsa-info.sh output at this point.
That's 3.9.2-wo-headphone.alsa.gz
- Plug the headphone, play, and check whether the headphone works and the speaker is muted. Again, get alsa-info.sh output at this point, no matter whether the headphone works or not.
That's 3.9.2-w-headphone.alsa.gz. Headphone not working, speakers correctly muted.
In anyway, if you make things working, please give exactly what you did, and take again alsa-info.sh output, too.
3.9.2-w-headphone-working.alsa.gz. The working state is lost after unplugging and replugging the headphones. It is different to the case when the alternate channel is used (Independent HP): replugging does not break the output than.
Sorry for confusion and thanks!
Looking at the outputs above, it seems that turning on/off EAPD on VT codecs triggers the automatic power up/down of the pin, which leads to the unexpected result.
Could you try the patch below?
thanks,
Takashi
--- diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index ae85bbd2..ce5446b 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -788,6 +788,8 @@ static void set_pin_eapd(struct hda_codec *codec, hda_nid_t pin, bool enable) return; if (codec->inv_eapd) enable = !enable; + if (spec->keep_eapd_on && !enable) + return; snd_hda_codec_update_cache(codec, pin, 0, AC_VERB_SET_EAPD_BTLENABLE, enable ? 0x02 : 0x00); diff --git a/sound/pci/hda/hda_generic.h b/sound/pci/hda/hda_generic.h index 54e6651..7620031 100644 --- a/sound/pci/hda/hda_generic.h +++ b/sound/pci/hda/hda_generic.h @@ -222,6 +222,7 @@ struct hda_gen_spec { unsigned int multi_cap_vol:1; /* allow multiple capture xxx volumes */ unsigned int inv_dmic_split:1; /* inverted dmic w/a for conexant */ unsigned int own_eapd_ctl:1; /* set EAPD by own function */ + unsigned int keep_eapd_on:1; /* don't turn off EAPD automatically */ unsigned int vmaster_mute_enum:1; /* add vmaster mute mode enum */ unsigned int indep_hp:1; /* independent HP supported */ unsigned int prefer_hp_amp:1; /* enable HP amp for speaker if any */ diff --git a/sound/pci/hda/patch_via.c b/sound/pci/hda/patch_via.c index e0dadcf..33de744 100644 --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -136,6 +136,7 @@ static struct via_spec *via_new_spec(struct hda_codec *codec) spec->codec_type = VT1708S; spec->no_pin_power_ctl = 1; spec->gen.indep_hp = 1; + spec->gen.keep_eapd_on = 1; spec->gen.pcm_playback_hook = via_playback_pcm_hook; return spec; }
On Fri, May 24, 2013 at 3:29 PM, Takashi Iwai tiwai@suse.de wrote:
On Fri, May 17, 2013 at 8:04 AM, Takashi Iwai tiwai@suse.de wrote:
Well... It seems that something went unnoticed. This command seems to be essential for this (and the revised) patch to get the headphone output at all:
hda-verb /dev/snd/hwC0D0 0x25 SET_PIN_WID 0xc0Looking at the outputs above, it seems that turning on/off EAPD on VT codecs triggers the automatic power up/down of the pin, which leads to the unexpected result.
I may be wrong here, but why the patch touches EAPD handling, but not WID?
Could you try the patch below?
I did, it does not work. Transcript and alsa-info before and after hda-verb attached.
Regards, Alex
At Fri, 24 May 2013 18:36:14 +0200, Alex Riesen wrote:
On Fri, May 24, 2013 at 3:29 PM, Takashi Iwai tiwai@suse.de wrote:
On Fri, May 17, 2013 at 8:04 AM, Takashi Iwai tiwai@suse.de wrote:
Well... It seems that something went unnoticed. This command seems to be essential for this (and the revised) patch to get the headphone output at all:
hda-verb /dev/snd/hwC0D0 0x25 SET_PIN_WID 0xc0Looking at the outputs above, it seems that turning on/off EAPD on VT codecs triggers the automatic power up/down of the pin, which leads to the unexpected result.
I may be wrong here, but why the patch touches EAPD handling, but not WID?
Well, I assumed that the EAPD off triggers the pin widget off by the hardware, too. But it seems wrong. By some reason, the hardware clears the pin automatically. Hmm.
Could you try to trace the verbs while plugging the headphone? Check whether you have /sys/kernel/debug/tracing directory. If not, make sure that you enabled the kernel tracing capability.
Then, just before plugging the headphone, run below:
# echo 1 > /sys/kernel/debug/tracing/events/hda/enable
This will start the logging HD-audio verbs. Then plug the headphone, and get the trace via
# cat /sys/kernel/debug/tracing/trace > trace.log
then disable tracing again
# echo 0 > /sys/kernel/debug/tracing/events/hda/enable
And attach trace.log. Then we can see whether the driver touches the pin widget at all.
Could you try the patch below?
I did, it does not work. Transcript and alsa-info before and after hda-verb attached.
OK, I'll cook up the new patch later.
thanks,
Takashi
On Fri, May 24, 2013 at 7:22 PM, Takashi Iwai tiwai@suse.de wrote:
Well, I assumed that the EAPD off triggers the pin widget off by the hardware, too. But it seems wrong. By some reason, the hardware clears the pin automatically. Hmm.
Could you try to trace the verbs while plugging the headphone?
Attached, it's ~70k, so compressed again.
I did, it does not work. Transcript and alsa-info before and after hda-verb attached.
OK, I'll cook up the new patch later.
I'm sorry to say that I will not be able to test it in the next 8 or so days: I'll be traveling and without this particular laptop with me. I hope someone with similar model (Sytem76 Lemur lemu4, i7) can provide some testing in the meantime. Otherwise, I'll test it as soon as I get back.
At Fri, 24 May 2013 23:32:14 +0200, Alex Riesen wrote:
On Fri, May 24, 2013 at 7:22 PM, Takashi Iwai tiwai@suse.de wrote:
Well, I assumed that the EAPD off triggers the pin widget off by the hardware, too. But it seems wrong. By some reason, the hardware clears the pin automatically. Hmm.
Could you try to trace the verbs while plugging the headphone?
Attached, it's ~70k, so compressed again.
Thanks.
Looking at this, surprisingly there is a verb to set the pinctl to 0x00 indeed. This didn't happen on the emulator I checked. So we need to figure out from where this came.
I did, it does not work. Transcript and alsa-info before and after hda-verb attached.
OK, I'll cook up the new patch later.
I'm sorry to say that I will not be able to test it in the next 8 or so days: I'll be traveling and without this particular laptop with me. I hope someone with similar model (Sytem76 Lemur lemu4, i7) can provide some testing in the meantime. Otherwise, I'll test it as soon as I get back.
Don't worry, the bug is more difficult than I thought :) We can fix it quickly but it's no real fix. Better to know the real culprit.
When you back, could you try the following and give the outputs?
0. Build the kernel with the patch below. Discard previous patches. Also, make sure that your kernel has CONFIG_SND_HDA_HWDEP=y and CONFIG_SND_HDA_RECONFIG=y.
1. Blacklist snd-hda-intel module in /etc/modprobe.d/* file, and reboot to runlevel 3.
2. Load snd-hda-intel manually with probe_only=1 option # modprobe snd-hda-intel probe_only=1
3. Run "alsa-info.sh --no-upload" at this moment, and save it.
4. Enable the tracing. # echo 1 > /sys/kernel/debug/tracing/events/hda/enable
5. Configure the codec via below (don't plug in HP yet): # echo 1 > /sys/class/sound/hwC0D0/reconfig
Copy the tracing output to somewhere # cp /sys/kernel/debug/tracing/trace /tmp/init-trace
then clear the trace buffer. # echo > /sys/kernel/debug/tracing/trace
6. Now you should have the normal sound operation. Try to play something, and confirm the speaker output is working. Get alsa-info.sh output at this state.
Again copy the trace buffer and clear # cp /sys/kernel/debug/tracing/trace /tmp/speaker-trace # echo > /sys/kernel/debug/tracing/trace
7. Plug the headphone, and copy the trace.
# cp /sys/kernel/debug/tracing/trace /tmp/headphone-trace # echo > /sys/kernel/debug/tracing/trace
Check whether the playback doesn't work on the headphone at this moment. Get alsa-info.sh output again.
8. Run some hda-verb to enable EAPD and pin-control, confirm the headphone is working now, and get alsa-info.sh output.
So, you'll get 4 alsa-info.sh outputs (step 3, 6, 7 and 8), and 4 trace logs (step 5, 6 and 7).
thanks,
Takashi
--- diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index ae85bbd2..5ca6655 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -5092,7 +5092,7 @@ int snd_hda_gen_init(struct hda_codec *codec)
snd_hda_apply_verbs(codec);
- codec->cached_write = 1; + // codec->cached_write = 1;
init_multi_out(codec); init_extra_out(codec); diff --git a/sound/pci/hda/patch_via.c b/sound/pci/hda/patch_via.c index e0dadcf..8d861c3 100644 --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -231,9 +231,11 @@ static void vt1708_update_hp_work(struct hda_codec *codec)
static void set_widgets_power_state(struct hda_codec *codec) { +#if 0 struct via_spec *spec = codec->spec; if (spec->set_widgets_power_state) spec->set_widgets_power_state(codec); +#endif }
static void update_power_state(struct hda_codec *codec, hda_nid_t nid,
On Wed, May 29, 2013 at 5:42 PM, Takashi Iwai tiwai@suse.de wrote:
At Fri, 24 May 2013 23:32:14 +0200, Alex Riesen wrote:
I'm sorry to say that I will not be able to test it in the next 8 or so days: I'll be traveling and without this particular laptop with me. I hope someone with similar model (Sytem76 Lemur lemu4, i7) can provide some testing in the meantime. Otherwise, I'll test it as soon as I get back.
Don't worry, the bug is more difficult than I thought :)
I was afraid you will say that sooner or later :)
When you back, could you try the following and give the outputs? ... So, you'll get 4 alsa-info.sh outputs (step 3, 6, 7 and 8), and 4 trace logs (step 5, 6 and 7).
Done. That's a lot of data, so please download it from here:
http://familie-riesen.de/~raa/public/test/no-cached-write-test.tar.bz2
The system boot is in linuxrc-safemode, and the test itself in test.sh. The logs and transcript in report/.
Regards, Alex
At Fri, 31 May 2013 12:31:19 +0200, Alex Riesen wrote:
On Wed, May 29, 2013 at 5:42 PM, Takashi Iwai tiwai@suse.de wrote:
At Fri, 24 May 2013 23:32:14 +0200, Alex Riesen wrote:
I'm sorry to say that I will not be able to test it in the next 8 or so days: I'll be traveling and without this particular laptop with me. I hope someone with similar model (Sytem76 Lemur lemu4, i7) can provide some testing in the meantime. Otherwise, I'll test it as soon as I get back.
Don't worry, the bug is more difficult than I thought :)
I was afraid you will say that sooner or later :)
Better than too late, no? ;)
When you back, could you try the following and give the outputs? ... So, you'll get 4 alsa-info.sh outputs (step 3, 6, 7 and 8), and 4 trace logs (step 5, 6 and 7).
Done. That's a lot of data, so please download it from here:
http://familie-riesen.de/~raa/public/test/no-cached-write-test.tar.bz2
The system boot is in linuxrc-safemode, and the test itself in test.sh. The logs and transcript in report/.
Thanks a lot. Strangely, in these logs, I see no trace of setting the pin 0x25 with control 0x00. Also EAPD isn't changed. So, I have to conclude again that it's the hardware who resets these controls.
Below is a series of patches. For simplicity, I just attach them, not inlining to the mail. They should be applicable cleanly to 3.9.4 as well. Let me know if this works. If this still doesn't work, I need to rewrite the patch to correct the pin-ctl / EAPD of the headphone pin after changing the speaker pin.
Takashi
On Fri, May 31, 2013 at 3:05 PM, Takashi Iwai tiwai@suse.de wrote:
Below is a series of patches. For simplicity, I just attach them, not inlining to the mail. They should be applicable cleanly to 3.9.4 as well. Let me know if this works. If this still doesn't work, I need to rewrite the patch to correct the pin-ctl / EAPD of the headphone pin after changing the speaker pin.
Still does not work. The results are for 3.9.4 + patches:
http://familie-riesen.de/~raa/public/test/dpc-automute-vol-pinctl.tar.bz2
I tried patched 3.9.2, with the same result.
At Fri, 31 May 2013 17:32:16 +0200, Alex Riesen wrote:
On Fri, May 31, 2013 at 3:05 PM, Takashi Iwai tiwai@suse.de wrote:
Below is a series of patches. For simplicity, I just attach them, not inlining to the mail. They should be applicable cleanly to 3.9.4 as well. Let me know if this works. If this still doesn't work, I need to rewrite the patch to correct the pin-ctl / EAPD of the headphone pin after changing the speaker pin.
Still does not work. The results are for 3.9.4 + patches:
http://familie-riesen.de/~raa/public/test/dpc-automute-vol-pinctl.tar.bz2
I tried patched 3.9.2, with the same result.
Grrr, EAPD on 0x25 seems reset by EAPD on 0x24 being turned off. We need to apply the patch of the last week again in the end. The revised one is below. Please apply it on the top of the previous three patches.
thanks,
Takashi
--- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Add keep_eapd_on flag to generic parser
VT1802 codec seems to reset EAPD of other pins in the hardware level, and this was another reason of the silent headphone output on some machines. As a workaround, introduce a new flag indicating to keep the EPAD on to the generic parser, and set it in patch_via.c.
Reported-by: Alex Riesen raa.lkml@gmail.com Cc: stable@vger.kernel.org [v3.9] Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/pci/hda/hda_generic.c | 2 ++ sound/pci/hda/hda_generic.h | 1 + sound/pci/hda/patch_via.c | 1 + 3 files changed, 4 insertions(+)
diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index 396fcce..59fe077 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -799,6 +799,8 @@ static void set_pin_eapd(struct hda_codec *codec, hda_nid_t pin, bool enable) return; if (codec->inv_eapd) enable = !enable; + if (spec->keep_eapd_on && !enable) + return; update_pin_verb(codec, pin, AC_VERB_SET_EAPD_BTLENABLE, enable ? 0x02 : 0x00); } diff --git a/sound/pci/hda/hda_generic.h b/sound/pci/hda/hda_generic.h index 2d70a7d0..57f5ca4 100644 --- a/sound/pci/hda/hda_generic.h +++ b/sound/pci/hda/hda_generic.h @@ -223,6 +223,7 @@ struct hda_gen_spec { unsigned int inv_dmic_split:1; /* inverted dmic w/a for conexant */ unsigned int own_eapd_ctl:1; /* set EAPD by own function */ unsigned int volatile_pin_ctl:1; /* pin contrl&EAPDs are volatile */ + unsigned int keep_eapd_on:1; /* don't turn off EAPD automatically */ unsigned int vmaster_mute_enum:1; /* add vmaster mute mode enum */ unsigned int indep_hp:1; /* independent HP supported */ unsigned int prefer_hp_amp:1; /* enable HP amp for speaker if any */ diff --git a/sound/pci/hda/patch_via.c b/sound/pci/hda/patch_via.c index 4bbd4f3..924dad6 100644 --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -137,6 +137,7 @@ static struct via_spec *via_new_spec(struct hda_codec *codec) spec->no_pin_power_ctl = 1; spec->gen.indep_hp = 1; spec->gen.volatile_pin_ctl = 1; + spec->gen.keep_eapd_on = 1; spec->gen.pcm_playback_hook = via_playback_pcm_hook; return spec; }
On Fri, May 31, 2013 at 8:00 PM, Takashi Iwai tiwai@suse.de wrote:
At Fri, 31 May 2013 17:32:16 +0200, Alex Riesen wrote:
On Fri, May 31, 2013 at 3:05 PM, Takashi Iwai tiwai@suse.de wrote:
Below is a series of patches. For simplicity, I just attach them, not inlining to the mail. They should be applicable cleanly to 3.9.4 as well. Let me know if this works. If this still doesn't work, I need to rewrite the patch to correct the pin-ctl / EAPD of the headphone pin after changing the speaker pin.
Still does not work. The results are for 3.9.4 + patches:
http://familie-riesen.de/~raa/public/test/dpc-automute-vol-pinctl.tar.bz2
Grrr, EAPD on 0x25 seems reset by EAPD on 0x24 being turned off. We need to apply the patch of the last week again in the end. The revised one is below. Please apply it on the top of the previous three patches.
Nope. Logs:
http://familie-riesen.de/~raa/public/test/keep_eapd_on.tar.bz2
At Fri, 31 May 2013 21:36:45 +0200, Alex Riesen wrote:
On Fri, May 31, 2013 at 8:00 PM, Takashi Iwai tiwai@suse.de wrote:
At Fri, 31 May 2013 17:32:16 +0200, Alex Riesen wrote:
On Fri, May 31, 2013 at 3:05 PM, Takashi Iwai tiwai@suse.de wrote:
Below is a series of patches. For simplicity, I just attach them, not inlining to the mail. They should be applicable cleanly to 3.9.4 as well. Let me know if this works. If this still doesn't work, I need to rewrite the patch to correct the pin-ctl / EAPD of the headphone pin after changing the speaker pin.
Still does not work. The results are for 3.9.4 + patches:
http://familie-riesen.de/~raa/public/test/dpc-automute-vol-pinctl.tar.bz2
Grrr, EAPD on 0x25 seems reset by EAPD on 0x24 being turned off. We need to apply the patch of the last week again in the end. The revised one is below. Please apply it on the top of the previous three patches.
Nope. Logs:
http://familie-riesen.de/~raa/public/test/keep_eapd_on.tar.bz2
Thanks. I think I found the culprit of the problem with the pin ctl value now. This happens only when the power save is used or suspended, and it happens only on VT1802. That's why I couldn't reproduce the issue with the emulator, and it wasn't reported from users of other VIA codecs.
In anyway, the patch series below are the fixes. Scratch the whole previous patches and apply them on clean 3.9 (or 3.10-rc) tree. Hopefully we sorted out all issues now.
thanks,
Takashi
On Mon, Jun 3, 2013 at 12:05 PM, Takashi Iwai tiwai@suse.de wrote:
Thanks. I think I found the culprit of the problem with the pin ctl value now. This happens only when the power save is used or suspended, and it happens only on VT1802. That's why I couldn't reproduce the issue with the emulator, and it wasn't reported from users of other VIA codecs.
In anyway, the patch series below are the fixes. Scratch the whole previous patches and apply them on clean 3.9 (or 3.10-rc) tree. Hopefully we sorted out all issues now.
Bingo, it works! In case you want to review the test, logs:
http://familie-riesen.de/~raa/public/test/via-fix-cleared-pins.tar.bz2
I'm going to run this kernel from now on. I shall report if I see something else.
Thanks! Alex
At Mon, 3 Jun 2013 20:49:45 +0200, Alex Riesen wrote:
On Mon, Jun 3, 2013 at 12:05 PM, Takashi Iwai tiwai@suse.de wrote:
Thanks. I think I found the culprit of the problem with the pin ctl value now. This happens only when the power save is used or suspended, and it happens only on VT1802. That's why I couldn't reproduce the issue with the emulator, and it wasn't reported from users of other VIA codecs.
In anyway, the patch series below are the fixes. Scratch the whole previous patches and apply them on clean 3.9 (or 3.10-rc) tree. Hopefully we sorted out all issues now.
Bingo, it works! In case you want to review the test, logs:
http://familie-riesen.de/~raa/public/test/via-fix-cleared-pins.tar.bz2
I'm going to run this kernel from now on. I shall report if I see something else.
OK, I'll queue these fixes now. Thanks for your patient testing!
Takashi
On Tue, May 14, 2013 at 7:59 AM, Takashi Iwai tiwai@suse.de wrote:
Also, what happens if you apply the patch below?
spec->set_widgets_power_state = set_widgets_power_state_vt2002P;
//spec->set_widgets_power_state = set_widgets_power_state_vt2002P;This helps as well. Yay! Thanks :) Whatever the outcome, I have them back more or less (more, for me) properly.
OK, then we know the place to fix now. Try the patch below instead. Does it fix the problem as well?
Sadly, no. Now there is no headphone output at all. Not even to the alternate PCM.
Probably unrelated, but I better mention it anyway: the "Auto-Mute Mode" works strangely, it never mutes anything but headphones. It might work as designed, but it is useless in this case: one still has to mute the speaker manually when plugging headphones (or do something with input events, which I failed to get to work).
Does the problem still happen with the patch?
Well... Kind of no. As I said, there is no headphone output, BUT the laptop built-in speakers ARE muted when the headphones plugged in.
And "Independent HP" has absolutely no effect, which is probably as it should be on this laptop.
With the independent HP turned on, there should be no output to the headphone through the normal PCM. There is a secondary PCM device, and this is routed to the headphone when the independent HP is on.
Ah. I misunderstood (miscounted?) the playback PCMs: this card has three (VT1802 Analog, VT1802 Alt Analog and ID 2806 Digital), the last one being HDMI (just deconfigured, while I was trying to figure the headphones out). The first two named appropriately (if one looks at them), and when tried (hw:0,2. Strangely, there is no hw:0,1) it indeed works (with the revised patch. Not with this one).
Regards, Alex
participants (2)
-
Alex Riesen -
Takashi Iwai