At Mon, 27 Apr 2015 11:52:52 -0600, Glenn Golden wrote:

Takashi Iwai tiwai@suse.de [2015-04-27 19:12:21 +0200]:

...

I see no such warning in the log you attached, so it's not the issue, as it seems.

Below is a debug patch, and now you should see messages like "XXX ..." in kernel log at loading the driver. If there is no such a message, it means that the thinkpad hook isn't built in at all. Please check the kernel log again with the patch.

Actually, before adding your debug patch, a question about something that may be relevant here: I noticed just now that the kernel build, which I performed in accordance with the instructions from the Archlinux Wiki:

https://wiki.archlinux.org/index.php/Kernels/Compilation/Traditional

did not result in a /lib/modules/extramodules-3.19-ARCH-gdg01 directory being created ("ARCH-gdg01" being the suffix used for the custom-built kernel).

The only extant modules directories are /lib/modules/3.19.3-ARCH-gdg01 and of course the extramodules dir /lib/modules/extramodules-3.19-ARCH that already existed from the previously installed ARCH distro kernel.

I suspect this may be a problem vis a vis ACPI, because with the new kernel loaded, the battery level indicator is stuck at zero. :)

What's the magic incantation to build the extramodules? I did look through this:

https://www.kernel.org/doc/Documentation/kbuild/modules.txt

but it did not seem to address this question that I could tell.

I have no idea about Arch, but in general, an easy way to build a module externally is to copy the kernel source tree (or a part of it), build it with M=xxx make arguments and install with INSTALL_MOD_DIR override.

% mkdir -p /somewhere/kernel/sound/pci % cp -a /usr/src/linux-xxx/sound/pci/hda /somewhere/kernel/sound/pci/ % cd /somewhere/kernel/linux-xxx % patch -p1 < /somewhere/somefix.patch % cd sound/pci/hda % make -C /lib/modules/$(uname -r)/build M=$(pwd) % su # export INSTALL_MOD_DIR=updates # make -C /lib/modules/$(uname -r)/build M=$(pwd) modules_install

But better to consult anyone familiar with Arch.

Takashi

Takashi Iwai tiwai@suse.de [2015-04-28 08:06:50 +0200]:

It's the call: led_set_func(TPACPI_LED_MUTE, false) and this returns an error. led_set_func is a function pointer to tpacpi_led_set: led_set_func = symbol_request(tpacpi_led_set);

So the above indicates that the call in thinkpad_acpi.c failed.

Could you check what value is returned from led_set_func(TPACPI_LED_MUTE, false)?

My wild guess is that it's -ENODEV.

Yep:

[ 13.379016] sound hdaudioC0D0: XXX hda_fixup_thinkpad_acpi init... [ 13.392760] sound hdaudioC0D0: XXX ok, this is thinkpad [ 13.404553] sound hdaudioC0D0: XXX mute LED NOT WORKING! [ 13.416106] XXX led_set_func(TPACPI_LED_MUTE, false) returned -19 [ 13.427719] sound hdaudioC0D0: XXX ok, mic LED is hooked

Question: To simplify/speed debugging going forward: Is there some straightforward way to unload/reload all the relevant sound modules as an alternative to rebooting? I came across some 'recipes', but none looked straightforward; lots of conditionality on the particular subset of modules being patched/debugged, but alas I've not enough knowledge to guess at exactly what that subset should be for what we're doing here.) Thx.

Takashi Iwai tiwai@suse.de [2015-04-28 12:30:19 +0200]:

Then it's likely an issue in thinkpad_acpi.c. It implies that the driver couldn't get SSMS acpi handle.

Raymond had pointed this out earlier as a (the?) patch that brought the static tp_led_table led_tables[] into existence:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/driver...

To my eyes, the table appears to be as it was in that patch:

--------------------------------------------------------------------------- static struct tp_led_table led_tables[] = { [TPACPI_LED_MUTE] = { .name = "SSMS", .on_value = 1, .off_value = 0, }, [TPACPI_LED_MICMUTE] = { .name = "MMTS", .on_value = 2, .off_value = 0, }, }; ---------------------------------------------------------------------------

thinkpad_acpi.h defines this enum and func:

--------------------------------------------------------------------------- /* These two functions return 0 if success, or negative error code (e g -ENODEV if no led present) */

enum { TPACPI_LED_MUTE, TPACPI_LED_MICMUTE, TPACPI_LED_MAX, };

int tpacpi_led_set(int whichled, bool on); ---------------------------------------------------------------------------

although I don't understand why the comment says "these TWO functions..." since there's only one.

How to learn more about the source of LED_MUTE's evident non-existence in my build? I guess I don't understand how the above "SSMS" entry in the table is non-existent? Is there a function-pointer table/hash in which "SSMS" is further used as a key?

For HD-audio, you need to unload the codec drivers at first, e.g. [ ... ]

Thanks, that will help a lot, as the machine is in constant use and reboots are painful.

Takashi Iwai tiwai@suse.de [2015-04-28 13:50:21 +0200]:

At Tue, 28 Apr 2015 05:39:48 -0600, Glenn Golden wrote:

...

Takashi Iwai tiwai@suse.de [2015-04-28 12:30:19 +0200]:

...

Then it's likely an issue in thinkpad_acpi.c. It implies that the driver couldn't get SSMS acpi handle.

Raymond had pointed this out earlier as a (the?) patch that brought the static tp_led_table led_tables[] into existence:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/platform/x86/thinkpad_acpi.c?id=420f9739a62cdb027f5580d25c813501ff93aa6f

This change was in 3.13 kernel, nothing new.

OK.

What's next on the menu for my end? Any further experiments that can be useful to try?

...

What's next on the menu for my end? Any further experiments that can be useful to try?

Better to ask thinkpad_acpi people :)

OK.

Wasn't sure exactly what side you were on, so to speak. In any case, big Tip o' the Hat to you for all your time on this Takashi, sincerely appreciated.

I'll remove you from Cc list going forward (unless you wish to remain on it, just let me know.)

Henrique - should this thread be moved to some TP ACPI list?

Henrique de Moraes Holschuh hmh@hmh.eng.br [2015-04-29 10:09:04 -0300]:

...

Henrique - should this thread be moved to some TP ACPI list?

There's ibm-acpi-devel@lists.sourceforge.net. We can also use the kernel bugzilla.

OK. Since there's already a ticket on the kernel tracker, let's just use that.

https://bugzilla.kernel.org/show_bug.cgi?id=96171

When you have time, let me know what the next step is for me to try here, and I'll post any results to the above ticket.

Thanks.

Raymond Yau superquad.vortex2@gmail.com [2015-05-01 22:22:15 +0800]:

...

Here are the XXX messages:

[   13.722755] sound hdaudioC0D0: XXX hda_fixup_thinkpad_acpi init...
[   13.724366] sound hdaudioC0D0: XXX ok, this is thinkpad
[   13.724373] sound hdaudioC0D0: XXX mute LED NOT WORKING!

This mean that your thinkpad does not support SSMS interface

Yes, this was confirmed by an experiment later in the PA thread suggested by Takashi, in which attempted access to the SSMS device yielded ENODEV.

Seems to me the next step then is to try to determine the difference between the following two possibilities:

a. The SSMS interface is truly not available on the T-510.

b. There is a bug in thinkpad_acpi (or elsewhere?) which is preventing the SSMS interface from being visible, hence leading to ENODEV upon attempted access.

Henrique: Can you comment on how best to proceed further here? Let me know if there's any experiments I can do on my end to narrow this down as either (a) or (b).

...

[   13.724374] sound hdaudioC0D0: XXX ok, mic LED is hooked

This mean that your thinkpad support MMTS interface

Yes, as stated in the original report, there is no issue at all with the MIC MUTE LED.

Do T420 support SSMS interface ?

Good question. I have no access to T-420. Does anyone know for sure?

Henrique de Moraes Holschuh hmh@hmh.eng.br [2015-05-04 07:37:08 -0300]:

On Sat, May 2, 2015, at 13:00, Glenn Golden wrote:

...

Henrique: Can you comment on how best to proceed further here?

Please attach the full acpidump (use a recent enough acpidump utility, please) to the bugzilla report and reply to this thread after you did so. Also attach the output of dmidecode.

Done:

https://bugzilla.kernel.org/attachment.cgi?id=175781 https://bugzilla.kernel.org/attachment.cgi?id=175771

Dmidump was invoked with no options. Acpidump was invoked with "-z" (verbose).

Acpidump reports version string "20150204-64 [May 3 2015]". That's the most recent packaged version available for Arch Linux.

FYI, in case it may be relevant: Both dumps were generated under kernel 4.0.1, not 3.19, because the machine is in heavy use with the new kernel and could not conveniently be rebooted to 3.19. I assumed -- perhaps wrongly -- that the output of these dumps should be independent on kernel version, but if this is wrong, and you need the dumps as taken under the 3.19 kernel, just let me know, I will repost them the next time I reboot.

Thanks for your time on this.

Glenn

Henrique de Moraes Holschuh hmh@hmh.eng.br [2015-05-04 10:16:21 -0300]:

Well, your firmware does not have SSMS, at all. It is not that thinkpad-acpi can't find it due to some change in the acpi core, it simply isn't there to be found.

OK, thanks for the detective work, Henrique.

In the interest of documenting what's been learned here (at least by me), what follows is an attempt at a detailed summary/guide to ThinkPad mute key and mute LED behavior when transitioning from 3.18 to 3.19 kernels. Perhaps it may be useful to others who are also head-scratching about this issue, since it involves quite a few moving parts.

It would be great if you could look it over when you have a chance, and correct or bless it as you see fit. I'll also pass it by the PA folks and then post the result to both the original PA ML thread and to the ThinkPad ACPI ML as well (if you want).

Thanks again for your time and assistance on this. (H/T also to David, Raymond, and Takashi).

Glenn

============================================================================= For TP models like the T-510 (and others without the SSMS mute LED interface):

0. If you want your mute LED to do anything (other than be permanently off) you have no choice but to set acpi.software_mute=0 at boot time, which reverts to 3.18 behavior. If you do this, then 1-3 below apply. If you don't care whether your mute LED works, then 4-8 further below apply.

1. The embedded controller (EC) fields mute key events directly, and in response, toggles both the hardware speaker mute gate and the mute LED (if you have one). The kernel is not involved in these actions at all.

2. "Mute LED on" means, unequivocally, that the hardware mute gate is clamped, i.e. no sound can emit from the speaker, period. The hardware mute gate has no effect on headphone mute state.

3. If you happen to already have the mute key mapped via userspace event to do something with the mixer mute state (e.g. via amixer/pactl/pacmd, etc.) you should probably disable that mapping in order to avoid unintended conflicts and/or mild insanity.

For ThinkPad models having the SSMS interface, the behavior in 3.18 is just as described in 1-3 above: The EC controls hardware speaker-mute gate and LED. If you're happy with that behavior, then when transitioning to 3.19 just set acpi.software_mute=0 at boot time, and you'll still have it.

Otoh, if you would like to have softkey control over mute action via mixer mute (in contrast to the hardware speaker-mute in 3.18) then don't supply the acpi.softkey=0 boot option, and the following apply:

4. Hardware speaker-mute is completely disabled: The EC does not field mute key events, nor does it touch the hardware mute gate control. The HW mute gate is permanently unclamped and inaccessible via kernel or userspace.

5. The mute key becomes a softkey, and muting must be performed via the mixer. The kernel autonomously takes care of synching the mute LED with the mixer "Playback Master" mute setting.

6. If you want your mute key to do anything, you have to set up an event handler to do whatever it is you want it to do.

7. If you elect to have the mute key toggle the Playback Master mute via an event which invokes pactl/pacmd/amixer/[insert fave mixer control tool] then the mute LED will automatically follow the Playback Mute state as mentioned above, thus no explicit action is required to make the LED work. But! ...

8. ...because [Alsa? Pulseaudio?] maintains two independent mixer mute state variables -- one for headphone port, one for speaker port -- the semantics of both the mute key and the mute LED become less straightforward than with the hardware-based mute in 3.18. Specifically:

* The mute key (via your userspace mixer control event handler) will toggle whichever port (HPH or SPKR) happens to be active at that time, and will have no effect on the mute state of the other port.

* The mute LED will likewise follow the mute state of the active port via kernel auto-synch (as described above).

Taken together, these imply that no unequivocal semantic can be attached to "mute LED on", as it was with hardware-based mute: All you can say is that if the LED is on, then the active port is muted via the mixer; the LED gives no information about the inactive port's mute state. One consequence of this is that the mute LED may (or may not) change state simply by the action of inserting or removing the headphone plug. =============================================================================

Raymond Yau superquad.vortex2@gmail.com [2015-05-07 09:03:53 +0800]:

Do your volume up/down key still work with soft_mute=1 ?

Yes. But just to be clear, they are soft keys that just invoke amixer to perform the action. No behavioral change noticed from 3.18 to 3.19 (the latter with default boot opts, i.e. soft_mute=1)

David Henningsson david.henningsson@canonical.com [2015-05-11 14:56:45 +0200]:

On 2015-05-07 02:15, Glenn Golden wrote:

...

8. ...because [Alsa? Pulseaudio?] maintains two independent mixer mute state variables -- one for headphone port, one for speaker port -- the semantics of both the mute key and the mute LED become less straightforward than with the hardware-based mute in 3.18.

The mute LED follows the state of ALSA's "Master Playback Switch". When that one is off, neither 3.5 mm headphone nor internal speakers have output - they're both muted.

PulseAudio's abstraction layer sets "Master Playback Switch" according to its active port's mute state. PulseAudio's active port (here speaker or headphone) will, by default, change automatically as headphones are plugged in or unplugged.

Thanks, David. I updated #7 and #8 per your comments above:

============================================================================= 7. If you elect to have the mute key toggle the Master Playback mute via an event which invokes pactl/pacmd/amixer/[insert fave mixer control tool] then the mute LED will automatically follow the Master Playback mute state as mentioned above, thus no explicit action is required to make the LED work. But! ...

8. ...if you also use PulseAudio, then the situation becomes a little more complicated, because PA maintains two independent mixer mute state variables, one for the headphone port, one for the speaker port, and the following caveats apply:

* The mute key (via your userspace mixer control event handler) will toggle only the port (HPH or SPKR) that happens to be active at that time, and will have no effect on the mute state of the other port.

* PulseAudio forces the Master Playback mute state to follow the mute state of its curently active port, hence...

* ...the mute LED will likewise follow the mute state of PA's active port via kernel auto-synch (as described in (5) above).

Taken together, these imply that when PulseAudio is in the picture, no unequivocal semantic can be attached to "mute LED on", as it was with hardware-based mute in 3.18: All you can say is that if the LED is on, then PulseAudio's active port is muted via the mixer; the LED gives no information about the inactive port's mute state. One possibly surprising consequence of this is that if the ALSA 'auto-mute' feature is enabled, then the mute LED may (or may not) change state simply by the action of plugging or unplugging the headphones, since doing so automatically switches the active port. =============================================================================