[alsa-devel] [PATCH] ALSA: hda: invert mute led polarity for HP laptops
At least two HP laptop models with the IDT 92HD81B1X5 codec have the polarity of the mute led inverted with respect to the current driver default. Change the polarity for these machines only.
Signed-off-by: Gustavo Maciel Dias Vieira gustavo@sagui.org --- sound/pci/hda/patch_sigmatel.c | 12 +++++++++++- 1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index d8d2f9d..c920a27 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -5601,6 +5601,16 @@ static void stac92hd8x_fill_auto_spec(struct hda_codec *codec) spec->num_dmics = spec->auto_dmic_cnt; }
+static int stac92hd8x_hp_mute_led_polarity(struct hda_codec *codec) +{ + switch (codec->subsystem_id) { + case 0x103c1650: + return 1; + } + return 0; +} + + static int patch_stac92hd83xxx(struct hda_codec *codec) { struct sigmatel_spec *spec; @@ -5642,7 +5652,7 @@ again:
codec->patch_ops = stac92xx_patch_ops;
- if (find_mute_led_gpio(codec, 0)) + if (find_mute_led_gpio(codec, stac92hd8x_hp_mute_led_polarity(codec))) snd_printd("mute LED gpio %d polarity %d\n", spec->gpio_led, spec->gpio_led_polarity);
At Sun, 04 Dec 2011 15:13:29 -0200, Gustavo Maciel Dias Vieira wrote:
At least two HP laptop models with the IDT 92HD81B1X5 codec have the polarity of the mute led inverted with respect to the current driver default. Change the polarity for these machines only.
Signed-off-by: Gustavo Maciel Dias Vieira gustavo@sagui.org
Don't these have really no proper DMI entries? The recent HP laptops should have the mute LED GPIO pin and polarity set in SMBIOS.
thanks,
Takashi
sound/pci/hda/patch_sigmatel.c | 12 +++++++++++- 1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index d8d2f9d..c920a27 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -5601,6 +5601,16 @@ static void stac92hd8x_fill_auto_spec(struct hda_codec *codec) spec->num_dmics = spec->auto_dmic_cnt; }
+static int stac92hd8x_hp_mute_led_polarity(struct hda_codec *codec) +{
- switch (codec->subsystem_id) {
- case 0x103c1650:
return 1;- }
- return 0;
+}
static int patch_stac92hd83xxx(struct hda_codec *codec) { struct sigmatel_spec *spec; @@ -5642,7 +5652,7 @@ again:
codec->patch_ops = stac92xx_patch_ops;
- if (find_mute_led_gpio(codec, 0))
- if (find_mute_led_gpio(codec, stac92hd8x_hp_mute_led_polarity(codec))) snd_printd("mute LED gpio %d polarity %d\n", spec->gpio_led, spec->gpio_led_polarity);
-- 1.7.7.3
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Em Seg, 2011-12-12 às 12:27 +0100, Takashi Iwai escreveu:
At Sun, 04 Dec 2011 15:13:29 -0200, Gustavo Maciel Dias Vieira wrote:
At least two HP laptop models with the IDT 92HD81B1X5 codec have the polarity of the mute led inverted with respect to the current driver default. Change the polarity for these machines only.
Signed-off-by: Gustavo Maciel Dias Vieira gustavo@sagui.org
Don't these have really no proper DMI entries? The recent HP laptops should have the mute LED GPIO pin and polarity set in SMBIOS.
Unfortunately no. Actually, it appears someone at HP is pulling a prank on us. In a Pavilion dm4 the BIOS string is "HP_Mute_LED_P_G", where P and G are not numbers, but the actual letters.
Abraços, Gustavo
At Mon, 12 Dec 2011 11:55:59 -0200, Gustavo Maciel Dias Vieira wrote:
Em Seg, 2011-12-12 às 12:27 +0100, Takashi Iwai escreveu:
At Sun, 04 Dec 2011 15:13:29 -0200, Gustavo Maciel Dias Vieira wrote:
At least two HP laptop models with the IDT 92HD81B1X5 codec have the polarity of the mute led inverted with respect to the current driver default. Change the polarity for these machines only.
Signed-off-by: Gustavo Maciel Dias Vieira gustavo@sagui.org
Don't these have really no proper DMI entries? The recent HP laptops should have the mute LED GPIO pin and polarity set in SMBIOS.
Unfortunately no. Actually, it appears someone at HP is pulling a prank on us. In a Pavilion dm4 the BIOS string is "HP_Mute_LED_P_G", where P and G are not numbers, but the actual letters.
Doh, they forgot to fill the right numbers there. Obviously a BIOS bug.
For such machines, the IDs should be explicitly checked instead of marking all machines with this codec. That is, the influence must be as small as possible. Or, just check "HP_Mute_LED_P_G" string as an identifier of bad machines, and apply a special handling.
BTW, now IDT guys and I are discussing about dropping the fallback case for 92HD83x codecs because it can break potentially the EAPD. Your patch won't work any more if that change is applied. So, a more solid fix would be needed anyway.
thanks,
Takashi
Em Seg, 2011-12-12 às 15:04 +0100, Takashi Iwai escreveu:
At Mon, 12 Dec 2011 11:55:59 -0200, Gustavo Maciel Dias Vieira wrote:
Unfortunately no. Actually, it appears someone at HP is pulling a
prank
on us. In a Pavilion dm4 the BIOS string is "HP_Mute_LED_P_G", where
P
and G are not numbers, but the actual letters.
Doh, they forgot to fill the right numbers there. Obviously a BIOS bug.
For such machines, the IDs should be explicitly checked instead of marking all machines with this codec. That is, the influence must be as small as possible. Or, just check "HP_Mute_LED_P_G" string as an identifier of bad machines, and apply a special handling.
I can do both, to be double sure. Just tell me which ID to use. I assumed that codec->subsystem_id was unique enough (by inspecting hp_blike_system(u32))
BTW, now IDT guys and I are discussing about dropping the fallback case for 92HD83x codecs because it can break potentially the EAPD. Your patch won't work any more if that change is applied. So, a more solid fix would be needed anyway.
It's a BIOS bug. Any fix is going to suck. :)
Abraços, Gustavo
At Mon, 12 Dec 2011 14:07:50 -0200, Gustavo Maciel Dias Vieira wrote:
Em Seg, 2011-12-12 às 15:04 +0100, Takashi Iwai escreveu:
At Mon, 12 Dec 2011 11:55:59 -0200, Gustavo Maciel Dias Vieira wrote:
Unfortunately no. Actually, it appears someone at HP is pulling a
prank
on us. In a Pavilion dm4 the BIOS string is "HP_Mute_LED_P_G", where
P
and G are not numbers, but the actual letters.
Doh, they forgot to fill the right numbers there. Obviously a BIOS bug.
For such machines, the IDs should be explicitly checked instead of marking all machines with this codec. That is, the influence must be as small as possible. Or, just check "HP_Mute_LED_P_G" string as an identifier of bad machines, and apply a special handling.
I can do both, to be double sure. Just tell me which ID to use. I assumed that codec->subsystem_id was unique enough (by inspecting hp_blike_system(u32))
Yes, subsytem_id can be used. OTOH, I guess HP_Mute_LED_P_G check would be easier and may cover more machines. So, I prefer the latter.
BTW, now IDT guys and I are discussing about dropping the fallback case for 92HD83x codecs because it can break potentially the EAPD. Your patch won't work any more if that change is applied. So, a more solid fix would be needed anyway.
It's a BIOS bug. Any fix is going to suck. :)
Yeah, but we try to keep less damage by the suck :)
thanks,
Takashi
Em Seg, 2011-12-12 às 15:04 +0100, Takashi Iwai escreveu:
Unfortunately no. Actually, it appears someone at HP is pulling a
prank
on us. In a Pavilion dm4 the BIOS string is "HP_Mute_LED_P_G", where
P
and G are not numbers, but the actual letters.
Doh, they forgot to fill the right numbers there. Obviously a BIOS bug.
For the record. I've upgraded the BIOS and the DMI entry was fixed.
Abraços, Gustavo
participants (2)
-
Gustavo Maciel Dias Vieira -
Takashi Iwai