Bug 16373

Summary: Lenovo Yxx0 mute indicator not work
Product: Drivers Reporter: RussianNeuroMancer (russianneuromancer)
Component: Sound(ALSA)Assignee: Jaroslav Kysela (perex)
Status: RESOLVED CODE_FIX    
Severity: normal CC: anatoly.trosinenko, tiwai
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.32 Subsystem:
Regression: No Bisected commit-id:
Attachments: System information
dmidecode
Patch to add LED support
Revised patch to add LED support
Fix patch

Description RussianNeuroMancer 2010-07-12 16:13:46 UTC
I have Lenovo Y550-4CWI laptop but as I know this issue releated to all Lenovo
Yxx0 laptops.
My "disable sound" hardware button have a led-indicator. This idicator work in
Windows, but always not light in Linux.
Photo of this button: http://img16.imageshack.us/img16/6642/76496975.jpg
What hardware information I must probide?
Comment 1 RussianNeuroMancer 2010-07-12 23:12:20 UTC
Created attachment 27080 [details]
System information
Comment 2 Takashi Iwai 2013-11-15 14:52:48 UTC
The relevant fix will be in 3.13-rc1.
Comment 3 RussianNeuroMancer 2013-12-17 08:58:32 UTC
Hello!
Unfortunately, issue is still reproducible for me on 3.13rc3.
Comment 4 Takashi Iwai 2013-12-17 09:42:58 UTC
Can you turn on/off LED via sysfs?  There must be something in /sys/class/leds/*, and you can change it by writing to "brightness" entry of the corresponding LED object.

If this doesn't work, it's an issue of thinkpad_acpi support.

OTOH, if it works, we need to check the binding from hd-audio driver at next.  In that case, the possible culprit is the lacok of ACPI device entry.
Comment 5 RussianNeuroMancer 2013-12-18 16:14:33 UTC
> Can you turn on/off LED via sysfs?
No, there is only one led (that also visible with 3.12 kernel) and judging by /sys/class/leds/phy0-led/device/net/wlan0 folder it's looks like WiFi led.

> If this doesn't work, it's an issue of thinkpad_acpi support.
Yxx0 is IdeaPad series. It's using thinkpad_acpi? I can't find mentions of thinkpad in dmesg and lsmod.
Comment 6 Takashi Iwai 2013-12-18 16:21:57 UTC
OK, then it might be same and it might be different.  You need to test.
Please give dmidecode output for checking whether the DMI string is compatible, at least.

Also, another thing you can try is to test GPIO pin of HD-audio codec.
For example,
   hda-verb /dev/snd/hwC0D2 0x01 SET_GPIO_MASK 0x01
   hda-verb /dev/snd/hwC0D2 0x01 SET_GPIO_DIR 0x01
   hda-verb /dev/snd/hwC0D2 0x01 SET_GPIO_DATA 0x01

will set the GPIO pin 0.  For GPIO pin 1, replace the second 0x01 with 0x02,
   hda-verb /dev/snd/hwC0D2 0x01 SET_GPIO_MASK 0x02
   ....
Comment 7 RussianNeuroMancer 2013-12-18 19:38:22 UTC
Created attachment 118951 [details]
dmidecode

> Please give dmidecode output for checking whether the DMI string is
> compatible, at least.
Attached.

> hda-verb /dev/snd/hwC0D2 0x01 SET_GPIO_MASK 0x01
Nothing happens.
> hda-verb /dev/snd/hwC0D2 0x01 SET_GPIO_DIR 0x01
Led lights up for one second.
> hda-verb /dev/snd/hwC0D2 0x01 SET_GPIO_DATA 0x01
Led again lights up for one second.
Comment 8 RussianNeuroMancer 2013-12-24 01:41:11 UTC
Still reproducible with 3.13rc5.

> NEEDINFO
What additional info I need to provide?
Comment 9 Takashi Iwai 2013-12-24 14:17:35 UTC
(In reply to RussianNeuroMancer from comment #8)
> Still reproducible with 3.13rc5.
> 
> > NEEDINFO
> What additional info I need to provide?

The reporter is supposed to change the state after providing the information.

But, still another question: is the power saving enabled on your system?
Changing back after 1 second sounds like that the power-saving is kicked off and it resets GPIO.  Check /sys/module/snd_hda_intel/parameters/power_save.  Disable it by writing 0 if it was enabled.

Also, check the GPIO states after the LED is turned off via
  hda-verb /dev/snd/hwC0D2 0x01 GET_GPIO_MASK
  hda-verb /dev/snd/hwC0D2 0x01 GET_GPIO_DIR
  hda-verb /dev/snd/hwC0D2 0x01 GET_GPIO_DATA

See whether the values you've set are retained there.
Comment 10 RussianNeuroMancer 2014-01-09 18:58:33 UTC
> The reporter is supposed to change the state after providing the information.
List of available bug status: resolved, verified, rejected, deferred, needinfo, closed. Which one I supposed to choice?

> Check /sys/module/snd_hda_intel/parameters/power_save.  Disable it by writing
> 0 if it was enabled.
It was enabled. I disable it so this time LED keep shining after "hda-verb /dev/snd/hwC0D2 0x01 GET_GPIO_DIR".

> Also, check the GPIO states after the LED is turned off
You mean "value" in hda-verb output. right? There is complete output:
~$ hda-verb /dev/snd/hwC0D2 0x01 SET_GPIO_MASK 0x01
nid = 0x1, verb = 0x716, param = 0x1
value = 0x0
~$ hda-verb /dev/snd/hwC0D2 0x01 SET_GPIO_DIR 0x01
nid = 0x1, verb = 0x717, param = 0x1
value = 0x0
~$ hda-verb /dev/snd/hwC0D2 0x01 SET_GPIO_DATA 0x01
nid = 0x1, verb = 0x715, param = 0x1
value = 0x0

After last command led get turned off any doesn't lights up anymore.
Comment 11 Takashi Iwai 2014-01-10 16:55:20 UTC
(In reply to RussianNeuroMancer from comment #10)
> > The reporter is supposed to change the state after providing the
> information.
> List of available bug status: resolved, verified, rejected, deferred,
> needinfo, closed. Which one I supposed to choice?

Hm, so user can't reset to ASSIGNED?  That's a bad interface...
 
> > Check /sys/module/snd_hda_intel/parameters/power_save.  Disable it by
> writing 0 if it was enabled.
> It was enabled. I disable it so this time LED keep shining after "hda-verb
> /dev/snd/hwC0D2 0x01 GET_GPIO_DIR".

OK.  So, powering to D3 seems resetting the GPIO line on this machine, unfortunately.  But let's check it at first with the patch.

The patch below adds a hook for controlling the GPIO1 pin.  But this doesn't influence on any D3 management by power saving, so if the power-saving is enabled, the LED might be turned off.  If so, please let me know.  I'll cook up another patch on the top.
Comment 12 Takashi Iwai 2014-01-10 16:55:57 UTC
Created attachment 121541 [details]
Patch to add LED support
Comment 13 Takashi Iwai 2014-01-13 15:28:25 UTC
Created attachment 121861 [details]
Revised patch to add LED support

Use this one instead.  The previous patch might have set on/off wrongly.
(OTOH, if the mute LED is wrongly on at non-mute time, let me know; the previous patch should work correctly instead.)
Comment 14 RussianNeuroMancer 2014-03-24 04:05:49 UTC
> Hm, so user can't reset to ASSIGNED?
Yes.

> But let's check it at first with the patch.
Sorry, I'm not developer, I can't check this.
Comment 15 Takashi Iwai 2014-03-24 09:05:01 UTC
(In reply to RussianNeuroMancer from comment #14)
> > Hm, so user can't reset to ASSIGNED?
> Yes.
> 
> > But let's check it at first with the patch.
> Sorry, I'm not developer, I can't check this.

You should be able to compile the kernel by yourself, no?  Otherwise we can't debug.  If you can't test it, tell us so.  Then we'll close this bug as undebuggable.
Comment 16 RussianNeuroMancer 2014-03-24 09:37:39 UTC
I can test available packages from http://kernel.ubuntu.com/~kernel-ppa/mainline/ (that how I test first implementation of Yxx0 mute indicator support on Y550-4CWI) but I can't compile.

> Then we'll close this bug as undebuggable.
You imply if one Yxx0 owner can't test patch then other Yxx0 owners can't test it too, so report should be closed?
Comment 17 Takashi Iwai 2014-03-24 09:58:45 UTC
Without testing, we can't debug.  Without compiling, we can't test.  Period.
It depends purely on the test, how it's compiled.  You can ask someone else.  You can pay something to do such a job.  Whatever.  But, it's not a job of the developers, sorry.
Comment 18 Anatoly Trosinenko 2014-10-19 12:24:44 UTC
I have Lenovo IdeaPad Y550P. Is some patch from this thread already integrated into 3.17.1? I have tested Ubuntu 14.10 with the mainline kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.17.1-utopic/ :

$ uname -a
Linux test 3.17.1-031701-generic #201410150735 SMP Wed Oct 15 11:36:31 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

and mute LED toggles on/off, but it is in an inverted state: it is on when the *sound* is on and when *mute* is on the LED is off.

What additional information should I provide about my hardware or what kernel patches should I test? (What patches and on top of what kernel versions should be applied? Is it enough to use configuration produced by 'make localmodconfig'?)
Comment 19 RussianNeuroMancer 2014-10-19 13:10:22 UTC
Anatoly, thanks for heads up!

> in an inverted state
I also tested 3.17.1 kernel today on Y550-4CWI and get same result.
Comment 20 Takashi Iwai 2014-10-20 09:28:52 UTC
OK, then we need to flip the bit flag, it's easy to fix (attached below).
Comment 21 Takashi Iwai 2014-10-20 09:29:14 UTC
Created attachment 154261 [details]
Fix patch
Comment 22 Anatoly Trosinenko 2014-10-21 10:50:20 UTC
I have tested this patch (154261) applied on top of the stable 3.17.1 kernel and it fixes the inversion issue.
Comment 23 Takashi Iwai 2014-10-21 11:54:25 UTC
OK, the patch was merged to sound git tree and will be included in the next pull request for 3.18-rc2.
Comment 24 RussianNeuroMancer 2014-10-21 15:01:28 UTC
Thank you for fix!
Comment 25 Anatoly Trosinenko 2014-10-23 09:58:03 UTC
Thank you very much!