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
Created attachment 27080 [details]
System information
The relevant fix will be in 3.13-rc1. Hello! Unfortunately, issue is still reproducible for me on 3.13rc3. 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. > 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. 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 .... 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. Still reproducible with 3.13rc5.
> NEEDINFO
What additional info I need to provide?
(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. > 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. (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. Created attachment 121541 [details]
Patch to add LED support
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.)
> 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. (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. 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? 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. 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'?) Anatoly, thanks for heads up!
> in an inverted state
I also tested 3.17.1 kernel today on Y550-4CWI and get same result.
OK, then we need to flip the bit flag, it's easy to fix (attached below). Created attachment 154261 [details]
Fix patch
I have tested this patch (154261) applied on top of the stable 3.17.1 kernel and it fixes the inversion issue. OK, the patch was merged to sound git tree and will be included in the next pull request for 3.18-rc2. Thank you for fix! Thank you very much! |