Re: regression: from 3.8 to 3.9: headphones output no sound on Intel HDA, codec VIA VT1802

[Takashi Iwai]

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@xxxxxxx> 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;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/