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 <[email protected]> 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 <[email protected]> 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.
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 <[email protected]> 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.
>
> 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 <[email protected]>
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 <[email protected]>
Cc: <[email protected]> [v3.9+]
Signed-off-by: Takashi Iwai <[email protected]>
---
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) */
--
1.8.2.1
On Tue, May 14, 2013 at 7:59 AM, Takashi Iwai <[email protected]> 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
On Tue, May 14, 2013 at 12:58 PM, Takashi Iwai <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
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 <[email protected]>
Cc: <[email protected]> [v3.9+]
Signed-off-by: Takashi Iwai <[email protected]>
---
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,
--
1.8.2.1
On Thu, May 16, 2013 at 1:00 PM, Takashi Iwai <[email protected]> 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 <[email protected]> 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 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.
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 <[email protected]> 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 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.
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 <[email protected]> wrote:
> Sorry for delayed replies. I have not much time for this lately.
>
> On Fri, May 17, 2013 at 8:04 AM, Takashi Iwai <[email protected]> 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 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.
>
> 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 <[email protected]> wrote:
> > Sorry for delayed replies. I have not much time for this lately.
> >
> > On Fri, May 17, 2013 at 8:04 AM, Takashi Iwai <[email protected]> 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 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.
> >
> > 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 <[email protected]> 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 <[email protected]> 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 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.
>
> 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 <[email protected]> wrote:
>> On Fri, May 17, 2013 at 8:04 AM, Takashi Iwai <[email protected]> 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 0xc0
>> >
>
> 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.
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 <[email protected]> wrote:
> >> On Fri, May 17, 2013 at 8:04 AM, Takashi Iwai <[email protected]> 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 0xc0
> >> >
> >
> > 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.
>
> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
On Fri, May 31, 2013 at 3:05 PM, Takashi Iwai <[email protected]> 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 <[email protected]> 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 <[email protected]>
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 <[email protected]>
Cc: <[email protected]> [v3.9]
Signed-off-by: Takashi Iwai <[email protected]>
---
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;
}
--
1.8.3
On Fri, May 31, 2013 at 8:00 PM, Takashi Iwai <[email protected]> wrote:
> At Fri, 31 May 2013 17:32:16 +0200, Alex Riesen wrote:
>> On Fri, May 31, 2013 at 3:05 PM, Takashi Iwai <[email protected]> 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 <[email protected]> wrote:
> > At Fri, 31 May 2013 17:32:16 +0200, Alex Riesen wrote:
> >> On Fri, May 31, 2013 at 3:05 PM, Takashi Iwai <[email protected]> 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 <[email protected]> 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 <[email protected]> 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