Re: Half second spend in i8042 during suspend on TUXEDO BU1406

On Wed, Feb 08, 2017 at 02:12:44PM +0100, Paul Menzel wrote:

On the TUXEDO BU1406 [1] the Linux kernel (tested with 4.10-rc{6,7})
takes over a second to get into suspend [2]. For whatever reason
around 550 ms are spent in `i8042_set_mux_mode()` (cf. attached
/*
 * Internal loopback test - send three bytes, they should come back
from the
 * mouse interface, the last should be version.
 */

        param = val = 0xf0;
        if (i8042_command(&param, I8042_CMD_AUX_LOOP) || param != val)
                return -1;
        param = val = multiplex ? 0x56 : 0xf6;
        if (i8042_command(&param, I8042_CMD_AUX_LOOP) || param != val)
                return -1;
        param = val = multiplex ? 0xa4 : 0xa5;
        if (i8042_command(&param, I8042_CMD_AUX_LOOP) || param == val)
                return -1;

Is that a hardware limitation, or even an error as such long delays
are not allowed according to some standard?

It looks like an EC firmware bug not handling the CMD_AUX_LOOP command
correctly.

Is there anything, that can be done about this, to get into S3 state faster?

Does it still happen if you specify i8042.nomux=1 on the kernel command
line?

If that helps, it can be added to a blacklist based on DMI.

Vojtech