[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <33355407b8d74575bab0c36e442141ea@ausx13mpc120.AMER.DELL.COM>
Date: Thu, 15 Feb 2018 15:22:25 +0000
From: <Mario.Limonciello@...l.com>
To: <pmenzel+linux-input@...gen.mpg.de>, <dmitry.torokhov@...il.com>
CC: <linux-input@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<it+linux-input@...gen.mpg.de>, <linux@...mhuis.info>
Subject: RE: i8042 AUX port [serio1] suspend takes a second on Dell XPS 13
9360
> -----Original Message-----
> From: Paul Menzel [mailto:pmenzel+linux-input@...gen.mpg.de]
> Sent: Thursday, February 15, 2018 2:26 AM
> To: Limonciello, Mario <Mario_Limonciello@...l.com>; Dmitry Torokhov
> <dmitry.torokhov@...il.com>
> Cc: linux-input@...r.kernel.org; linux-kernel@...r.kernel.org; it+linux-
> input@...gen.mpg.de; linux@...mhuis.info
> Subject: Re: i8042 AUX port [serio1] suspend takes a second on Dell XPS 13 9360
>
> Dear Mario, dear Dmitry,
>
>
> On 02/14/18 18:11, Mario.Limonciello@...l.com wrote:
> >
> >
> >> -----Original Message-----
> >> From: Paul Menzel [mailto:pmenzel+linux-input@...gen.mpg.de]
> >> Sent: Wednesday, February 14, 2018 10:41 AM
> >> To: Dmitry Torokhov <dmitry.torokhov@...il.com>
> >> Cc: linux-input@...r.kernel.org; linux-kernel@...r.kernel.org; it+linux-
> >> input@...gen.mpg.de; Limonciello, Mario <Mario_Limonciello@...l.com>;
> >> Thorsten Leemhuis <linux@...mhuis.info>
> >> Subject: Re: i8042 AUX port [serio1] suspend takes a second on Dell XPS 13 9360
>
> >> On 01/30/18 19:07, Dmitry Torokhov wrote:
> >>> On Tue, Jan 30, 2018 at 09:52:45AM -0800, Dmitry Torokhov wrote:
> >>
> >>>> On Tue, Jan 30, 2018 at 06:36:34PM +0100, Paul Menzel wrote:
> >>
> >>>>> I do not know, when it started, but with Linux 4.14-rc8 and 4.15,
> >>>>> benchmarking suspend and resume time with `sleepgraph.py` [1][2], there is
> a
> >>>>> regression, that i8042 AUX port [serio1] suspend takes a second on Dell XPS
> >>>>> 13 9360 and TUXEDO Book 1406.
> >>>>
> >>>> It would be really helpful to know when the regression started.
> >>>
> >>> So the reason it takes longer is because the touchpad does not want to
> >>> talk to us for some reason and we wait until commands time out:
> >>>
> >>> [ 94.591636] calling serio1+ @ 2299, parent: i8042
> >>> [ 94.794292] psmouse serio1: Failed to disable mouse on isa0060/serio1
> >>> [ 95.593303] call serio1+ returned 0 after 974280 usecs
> >>>
> >>> but it is not clear why it happens, I do not think we changed anything
> >>> in that path for a while, so it might be some other change affecting
> >>> things indirectly. I'm afraid you'll have to narrow the scope, and
> >>> ideally bisect.
> >
> > Please keep in mind the XPS 9360 has a touchpad that can operate in I2C
> > or PS2 modes. It's connected to both buses and with the right initialization
> > sequence will come up in I2C mode.
> >
> > Assuming Paul M. has compiled and used hid-multitouch and i2c-hid the
> > touchpad should be operating in I2C mode.
> >
> > When this happens I expect that the touchpad shouldn't be responding
> > to PS2 commands.
> >
> > As a debugging tactic, you may consider to unload psmouse before
> > suspend and still see the touchpad operational.
>
> Thank you! Unloading *psmouse* with `sudo modprobe -r psmouse` indeed
> worked on the Dell XPS 13 9360, that means, the cursor is still functioning.
>
> >> Thank you for your replies. First of all, it looks like *only* the Dell
> >> system is effected as I was unable to reproduce it on the TUXEDO Book
> >> 1406. I have to verify that by finding old log files.
> >
> > Does this other laptop you are drawing a comparison to also have a
> > touchpad that can operate in multiple modes?
> >
> > To make an accurate comparison you should determine what mode it's in.
>
> Yeah, removing the module *psmouse*, the cursor didn’t work there
> anymore. I was really sure, that I saw that problem once on the TUXEDO
> device too, but must have been mistaken, that’s why I corrected it.
> Sorry for the misunderstanding.
>
> So, why does *psmouse* get loaded on the Dell XPS 13 9360 since at least
> Linux 4.13? Or where the modules added causing the touchpad to operate
> in I2C mode, which causes PS2 to stop to work?
>
It was like that before this laptop even launched to the market.
It's been like that since way before 4.13. I want to say maybe 3.13ish is when
I2C mode would come up instead.
The order of events goes something like this:
1) Touchpad is initially in PS2 mode
2) psmouse loads
3) It reports that it may be supportable by a different bus
4) The sequence to switch to I2C mode happens
5) i2c-hid and hid-multitouch get loaded
6) psmouse is no longer functional
Dmitry is there a way that we can connect the two events? When i2c-hid finds
the touchpad notify psmouse to unload or at least stop trying to access it to prevent
the problem Paul is talking about with suspend?
Powered by blists - more mailing lists