Created attachment 274645 [details] Output from alsa-info.sh With Linux 4.15.x, the mute LED on this HP laptop (Pavilion 15 ab253cl) stopped working. When the driver loads, the LED gets stuck either ON or OFF, and muting/unmuting the Master channel does not change the LED. In 4.14.x the LED worked fine. Output of alsa-info.sh is attached. Please let me know if there is any other info I can provide.
In alsamixer, the card shows up as HDA Intel PCH - Realtek ALC3241. There is a "Mute-LED Mode" switch which can be set to "On", "Off", or "Follow Master", but with no effect (the LED is still stuck ON or OFF).
Could you get alsa-info.sh output also from the working kernel, at both mute-LED on and off? Then we can compare in more details.
Created attachment 274653 [details] alsa-info with 4.14, unmuted
Created attachment 274655 [details] alsa-info with 4.14, muted
Thanks. It shows that NID 0x18 VREF is the mute LED. Could you check the same for non-working 4.15 kernel, with mute LED on and off?
Also, try to adjust NID 0x18 VREF dynamically via hda-verb program, hda-verb /dev/snd/hwC0D0 0x18 SET_PIN_WID 0x04 and hda-verb /dev/snd/hwC0D0 0x18 SET_PIN_WID 0x00 to see whether the mute LED is turned on/off or vice-versa.
Okay, with 4.15, the weirdest thing (which I didn't notice until now) is that the mere act of running alsa-info.sh causes the LED to update to its correct state. So: fresh boot, unmuted, LED stuck ON -> run alsa-info.sh, LED turns off press button to mute, LED stays OFF -> run alsa-info.sh, LED turns on The also-info output shows the same "Pin-ctls" line as with 4.14, but I will attach it anyway.
Created attachment 274657 [details] alsa-info with 4.15, unmuted
Created attachment 274659 [details] alsa-info with 4.15, muted
I can confirm that the LED is turned on by this command: sudo hda-verb /dev/snd/hwC0D0 0x18 SET_PIN_WID 0x04 And off by this one: sudo hda-verb /dev/snd/hwC0D0 0x18 SET_PIN_WID 0x00 So it seems that ALSA knows how to control the LED all right, it is just missing some kind of trigger when the audio is muted/unmuted.
By pressing the mute button, is the mixer mute status really changed? Check the output of "amixer -c0 contents" before and after the mute button toggle. If the lack of the sync is the cause, it's possibly something about the runtime PM. But I don't remember of any crucial changes between 4.14 and 4.15. A git bisection would be required to spot it, I'm afraid.
The mixer mute status is changed immediately (amixer -c0 contents shows that the value of 'Master Playback Switch' changes between 'on' and 'off'). If audio is playing, the mute LED does change right away. It's only when no audio is playing that the problem appears.
If so, it's likely about the runtime PM. And now I'm seeing the difference in power_save option of snd-hda-intel module. It's zero in 4.14 while it's -1 in 4.15. The value -1 was introduced recently as the "default" value considering the blacklist. But it might be that this confuses the user-space. Try to set the value 1 to /sys/module/snd_hda_intel/parameters/power_save on 4.14 kernel: echo 1 > /sys/module/snd_hda_intel/parameters/power_save And try to play and stop. After one second, this will bring to the similar behavior as 4.15 kernel, I suppose. If so, the lack of mute LED during power-save is basically a long-standing problem, although the "regression" was brought by power_save parameter change...
The patch below should fix the mute LED issue. But it means that the machine can't reach to the lowest power saving.
Created attachment 274663 [details] Fix patch
Unfortunately the patch does not fix the problem for me. However, adding "options snd_hda_intel power_save=0" to /etc/modprobe.d does fix the problem.
OK, the previous patch was incomplete. Try the patch below instead.
Created attachment 274665 [details] Fix patch (revised)
... or this might not work, either. And it also sucks to prevent the runtime PM, so it wouldn't be a good fix, in anyway. Below is another attempt: it partially reverts the power_save option behavior, and no longer set to -1 as default. Instead a new option is added for controlling the blacklist. This should make 4.15 back to 4.14-compatible.
Created attachment 274671 [details] Partial revert of power_save option behavior
Just to be sure: the patch in comment 20 should make 4.15 behaving compatible as 4.14. That is, user-space will set power_save to 0 properly again, so you won't see the mute LED issue after that. This is indeed a regression, and the patch in comment 20 was now merged into my tree, and will be included in the next Linus / stable tree. So far, so good. However, the real problem is that the mute LED is gone after the power-saving (aka runtime PM) is enabled. This has to be addressed. The patch in comment 18 was considered to cover, but it won't, I guess. The patch below should work better, hopefully. Please test it with power_save=1.
Created attachment 274687 [details] Fix mute-LED during power-saving
Unfortunately, the patch in comment 22 still doesn't fix the problem for me, with power_save=1. > However, the real problem is that the mute LED is gone after the power-saving > (aka runtime PM) is enabled. This has to be addressed. I'm not sure, but there might be some misunderstanding here between us. Just to be clear, the mute LED doesn't necessarily turn off when power-saving kicks in. It can get stuck in the "on" state also. That is, I can turn it on or off at will while audio is playing, and then it will remain stuck in that same state after the audio stops and power-save takes effect. The patch in comment 22 looks like it's trying to keep some part of the hardware powered when mute is active, to keep the LED on. This may not be necessary, since apparently the LED is already able to remain on during power-save. Rather it seems to me that the trigger that ought to be changing the state of the LED, when muted/unmuted, is somehow missed or inhibited during power-save. I don't really know much about the HW or the driver, so please pardon me if you've already considered this; I just don't want you to be spending time trying to fix something other than the real problem due to my poor communication.
Aha, indeed it's a big misunderstanding. So the LED gets just stuck without changing the actual value during the power save. Then the fix should be easy. Try the patch below instead. It's simpler, just forcibly power up/down at changing the LED status.
Created attachment 274747 [details] Another fix patch
The patch in comment #25 apparently causes the driver to hang. Any program trying to access the audio device also hangs in an "uninterruptible" state.
Sorry, mea culpa, it must be snd_hda_power_up_pm() instead of snd_hda_power_up(). Below is the corrected patch.
Created attachment 274793 [details] Corrected fix patch
Created attachment 274795 [details] Corrected fix patch The previous one was an incomplete one, sorry, scratch that.
This one (comment 29) works, thank you!
The patch was queued to sound.git tree and will be included in the next pull request to Linus.