[alsa-devel] [PATCH 1/2] ALSA: hda - Fix EAPD GPIO control for Sigmatel codecs
The EAPD GPIO is dynamically turned on/off for some machines with Sigmatel codecs, but this didn't work as expected, and it resulted in spontaneous lost of speaker outputs per HP plugging or power-saving.
This patch fixes the bug by simply including spec->eapd_mask into spec->gpio_mask and spec->gpio_data bits.
Reported-and-tested-by: Eric Shattow lucent@gmail.com Cc: stable@vger.kernel.org [v3.9+] Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/pci/hda/patch_sigmatel.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index e2f8359..766e567 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -417,9 +417,11 @@ static void stac_update_outputs(struct hda_codec *codec) val &= ~spec->eapd_mask; else val |= spec->eapd_mask; - if (spec->gpio_data != val) + if (spec->gpio_data != val) { + spec->gpio_data = val; stac_gpio_set(codec, spec->gpio_mask, spec->gpio_dir, val); + } } }
@@ -3612,20 +3614,18 @@ static int stac_parse_auto_config(struct hda_codec *codec) static int stac_init(struct hda_codec *codec) { struct sigmatel_spec *spec = codec->spec; - unsigned int gpio; int i;
/* override some hints */ stac_store_hints(codec);
/* set up GPIO */ - gpio = spec->gpio_data; /* turn on EAPD statically when spec->eapd_switch isn't set. * otherwise, unsol event will turn it on/off dynamically */ if (!spec->eapd_switch) - gpio |= spec->eapd_mask; - stac_gpio_set(codec, spec->gpio_mask, spec->gpio_dir, gpio); + spec->gpio_data |= spec->eapd_mask; + stac_gpio_set(codec, spec->gpio_mask, spec->gpio_dir, spec->gpio_data);
snd_hda_gen_init(codec);
@@ -3915,6 +3915,7 @@ static void stac_setup_gpio(struct hda_codec *codec) { struct sigmatel_spec *spec = codec->spec;
+ spec->gpio_mask |= spec->eapd_mask; if (spec->gpio_led) { if (!spec->vref_mute_led_nid) { spec->gpio_mask |= spec->gpio_led;
The quirk for Dell laptops with STAC9228 overrides the pin default config of NID 0x0f to the value with AC_DEFCFG_MISC_NO_PRESENCE bit on. I'm not quite sure why this was done so, but can guess that this was introduced for avoiding this to be muted by another headphone plug. Now, after transition to the generic parser, this workaround rather causes a problem (notably as unexpected speaker mutes) because the pin is seen as if it's always plugged in.
Since the generic parser can handle multiple headphone plugging gracefully, we can get rid of this override now.
Reported-and-tested-by: Eric Shattow lucent@gmail.com Cc: stable@vger.kernel.org [v3.9+] Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/pci/hda/patch_sigmatel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index 766e567..92b9b43 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -3233,7 +3233,7 @@ static const struct hda_fixup stac927x_fixups[] = { /* configure the analog microphone on some laptops */ { 0x0c, 0x90a79130 }, /* correct the front output jack as a hp out */ - { 0x0f, 0x0227011f }, + { 0x0f, 0x0221101f }, /* correct the front input jack as a mic */ { 0x0e, 0x02a79130 }, {}
The quirk for Dell laptops with STAC9228 overrides the pin default config of NID 0x0f to the value with AC_DEFCFG_MISC_NO_PRESENCE bit on. I'm not quite sure why this was done so, but can guess that this was introduced for avoiding this to be muted by another headphone plug. Now, after transition to the generic parser, this workaround rather causes a problem (notably as unexpected speaker mutes) because the pin is seen as if it's always plugged in.
Is there any side effect when the driver perform pin fixup on line out pin complex which pincap does not support HP to headphone phone complex
Refer to STAC9228 datasheet , port F does not support headphone out
• Ports A, B, and D support • Headphone Out • Line Out • Line In • Microphone with
Node 0x0f [Pin Complex] wcaps 0x400181: Stereo Control: name="Front Headphone Front Phantom Jack", index=0, device=0 Pincap 0x00001737: IN OUT Detect Trigger ImpSense Vref caps: HIZ 50 GRD 80 Pin Default 0x02011020: [Jack] Line Out at Ext Front Conn = 1/8, Color = Black DefAssociation = 0x2, Sequence = 0x0 Pin-ctls: 0x40: OUT VREF_HIZ Unsolicited: tag=00, enabled=0 Connection: 1 0x050
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index 766e567..92b9b43 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -3233,7 +3233,7 @@ static const struct hda_fixup stac927x_fixups[] = { /* configure the analog microphone on some laptops */ { 0x0c, 0x90a79130 }, /* correct the front output jack as a hp out */
{ 0x0f, 0x0227011f },
{ 0x0f, 0x0221101f }, /* correct the front input jack as a mic */ { 0x0e, 0x02a79130 }, {}
At Tue, 23 Jul 2013 15:50:29 +0800, Raymond Yau wrote:
The quirk for Dell laptops with STAC9228 overrides the pin default config of NID 0x0f to the value with AC_DEFCFG_MISC_NO_PRESENCE bit on. I'm not quite sure why this was done so, but can guess that this was introduced for avoiding this to be muted by another headphone plug. Now, after transition to the generic parser, this workaround rather causes a problem (notably as unexpected speaker mutes) because the pin is seen as if it's always plugged in.
Is there any side effect when the driver perform pin fixup on line out pin complex which pincap does not support HP to headphone phone complex
Refer to STAC9228 datasheet , port F does not support headphone out
Yes, but we checked that Windows show in the same way (the secondary headphone), so we just take it as is.
Takashi
• Ports A, B, and D support • Headphone Out • Line Out • Line In • Microphone with
Node 0x0f [Pin Complex] wcaps 0x400181: Stereo Control: name="Front Headphone Front Phantom Jack", index=0, device=0 Pincap 0x00001737: IN OUT Detect Trigger ImpSense Vref caps: HIZ 50 GRD 80 Pin Default 0x02011020: [Jack] Line Out at Ext Front Conn = 1/8, Color = Black DefAssociation = 0x2, Sequence = 0x0 Pin-ctls: 0x40: OUT VREF_HIZ Unsolicited: tag=00, enabled=0 Connection: 1 0x050
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index 766e567..92b9b43 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -3233,7 +3233,7 @@ static const struct hda_fixup stac927x_fixups[] = { /* configure the analog microphone on some laptops */ { 0x0c, 0x90a79130 }, /* correct the front output jack as a hp out */
{ 0x0f, 0x0227011f },
{ 0x0f, 0x0221101f }, /* correct the front input jack as a mic */ { 0x0e, 0x02a79130 }, {}
The quirk for Dell laptops with STAC9228 overrides the pin default config of NID 0x0f to the value with AC_DEFCFG_MISC_NO_PRESENCE bit on. I'm not quite sure why this was done so, but can guess that this was introduced for avoiding this to be muted by another headphone plug. Now, after transition to the generic parser, this workaround rather causes a problem (notably as unexpected speaker mutes) because the pin is seen as if it's always plugged in.
Is there any side effect when the driver perform pin fixup on line out
pin
complex which pincap does not support HP to headphone phone complex
Refer to STAC9228 datasheet , port F does not support headphone out
Yes, but we checked that Windows show in the same way (the secondary headphone), so we just take it as is.
Is this a regression since it surround 5.1 was supported ?
http://git.kernel.org/cgit/linux/kernel/git/tiwai/hda-emu.git/plain/codecs/s...
Simple mixer control 'Headphone as Line Out',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on]
Simple mixer control 'Mic as Output',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on]
Simple mixer control 'Swap Center/LFE',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [off]
At Wed, 24 Jul 2013 20:17:16 +0800, Raymond Yau wrote:
The quirk for Dell laptops with STAC9228 overrides the pin default config of NID 0x0f to the value with AC_DEFCFG_MISC_NO_PRESENCE bit on. I'm not quite sure why this was done so, but can guess that this was introduced for avoiding this to be muted by another headphone plug. Now, after transition to the generic parser, this workaround rather causes a problem (notably as unexpected speaker mutes) because the pin is seen as if it's always plugged in.
Is there any side effect when the driver perform pin fixup on line out
pin
complex which pincap does not support HP to headphone phone complex
Refer to STAC9228 datasheet , port F does not support headphone out
Yes, but we checked that Windows show in the same way (the secondary headphone), so we just take it as is.
Is this a regression since it surround 5.1 was supported ?
Sort of.
Takashi
http://git.kernel.org/cgit/linux/kernel/git/tiwai/hda-emu.git/plain/codecs/s...
Simple mixer control 'Headphone as Line Out',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on]
Simple mixer control 'Mic as Output',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on]
Simple mixer control 'Swap Center/LFE',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [off]
participants (2)
-
Raymond Yau -
Takashi Iwai