On 2019/4/9 下午11:42, Benjamin Tissoires wrote:
On Tue, Apr 9, 2019 at 3:32 PM hwang4 <hui.wang@xxxxxxxxxxxxx> wrote:
On 2019/4/8 下午11:44, Benjamin Tissoires wrote:
Hi,
On Mon, Apr 8, 2019 at 6:07 AM Hui Wang <hui.wang@xxxxxxxxxxxxx> wrote:
We disabled the runtime PM for the synaptics touchpad (06cb:7e7e),
then it worked, but after S3, the touchpad didn't work again.
After more investigation, we found if we don't disable RT PM and only
apply I2C_HID_QUIRK_DELAY_AFTER_SLEEP, we can get the interrupt and
data report from touchpad, but the data report is invalid to the
driver hid-multitouch (this touchpad has HID_GROUP_MULTITOUCH_WIN_8,
so the driver hid-multitouch is loaded), if we rmmod hid-multitouch,
then the hid-generic is the driver and the data report is valid to
this driver, the touchpad work again.
The data report is valid to hid-generic while is invalid to
hid-multitouch, that is because the hid-multitouch set the specific
mode to touchpad and let it report data in a specific format.
After we enable runtime PM, the touchpad will be PWR_SLEEP via RT
PM, this will make the working mode lost on this touchpad, then it
will report data in a different format from the hid-multitouch needed.
Let the driver set the working mode in the runtime resume just like
the system resume does, this can fix this problem. But on this
touchpad, besides the issue of "working mode lost after PWR_SLEEP", it
also has one more issue, it needs to wait for 100 ms between PWR_ON
and setting mode, otherwise the mode can't be set correctly.
Since both system resume and RT resume will call reset_resume, i put
the related code in a function, no behaviour change for system resume.
Thanks for your comment, today I discussed with Kai-Heng Feng who is the
author of commit 77ae0d8e401f ("HID: i2c-hid: Disable runtime PM on
Goodix touchpad"), it looks like I applied the quirk to the wrong
vid:pid, the synaptics touchpad (06cb:7e7e) has no any problem with the
existing i2c-hid driver, and we should revert 74e7c6c877f6 ("HID:
i2c-hid: Disable runtime PM on Synaptics touchpad"). It looks like
Hai-Heng and I worked on the same hardware touchpad, but he got the id
(27c6:01f0) while I got the id (06cb:7e7e)
Not sure I followed everything. Is the following correct?
- Synaptics 06cb:7e7e is working fine without the runtime PM patch
(74e7c6c877f6) and has no issues with suspend/resume
Correct.
- Goodix 27c6:01f0 is the one having trouble with runtime PM *and*
suspend resume
It has the trouble with runtime PM, and I thought it also has the
trouble with suspend and resume, but today I tested the touchpad
(27c6:01f0), it has no problem with suspend and resume. So it only has
the trouble with runtime PM.
And today I got the whole story, The touchpad (06cb:7e7e) on my two
laptops are engineering samples, in fact they are not synaptics
touchpads, we can call them Gen-1 (generation one) samples, they have
trouble with runtime PM and suspend/resume (" Our IC needs about 60 ms
to resume from sleep state, so we hope system can extend the command
delay time to avoid potential risk."). The touchpad (27c6:01f0) is
gen-2 sample, it reports different vid:pid from gen-1, and for the
gen-2 sample, it has no 60ms delay requirement, so gen-2 only needs
NO_RUNTIME_PM quirk and since gen-1 is not real synaptics touchpad and
gen-1 is replaced by gen-2 already, we need to revert the commit
74e7c6c877f6 ("HID: i2c-hid: Disable runtime PM on Synaptics touchpad")
This patch should be applied to Goodix touchpad (27c6:01f0) if the
touchpad on Kai-Heng's machine doesn't work after s3. I need to verify
if that touchpad still work or not after s3, but I guess it will not
work since in the system resume it set the touchpad to be
I2C_HID_PWR_ON, then immediately it set the working mode via
hid->driver->reset_resume(hid), there is no delay between POW_ON and
setting work mode. At least on my machine, if there is no delay, the
working mode can't be set successfully and hid-multitouch can't parse
the data report.
I set the delay to 100ms based on my testing result. On my machine, I
originally set the delay to 10/20/30/40ms but the touchpad can't report
the data that hid-multitouch needed, After I set the delay to 50ms, the
driver works occasionally. Then to be safe, I set the delay to 100ms in
the patch. And this afternoon, I found this comment from Goodix " Our IC
needs about 60 ms to resume from sleep state, so we hope system can
extend the command delay time to avoid potential risk."
So if I understand correctly, the Goodix touchpad needs:
- to wait 60ms after a SET_POWER on
No need for gen-2. I tested it today.
- to switch back to multitouch mode after a SET_POWER sleep and back on
Needed for gen-2, but disable RUNTIME_PM can workaround it.
Thanks for the patch.
However, I have the impression we are totally wrong under Linux and
i2c-hid. This is yet an other quirk for a driver that should not have
any.
I definitively not want to maintain an endless list of quirks, but I'd
rather mimic what Windows is doing or this is going to never end.
I have been told a few times that the Windows driver was much less
aggressive than us regarding the POWER command. And from what I
remember from the spec, it actually makes no tsense to control runtime
PM on the touchpads by sending those POWER commands. I2C is a bus that
should not drain any power when not in use. And the touchpad has
enough information when to go into low power.
So I am going to install Windows on a i2c-hid laptop, and try to see
when these commands are sent, and which timing is used (should we
delay any command by 100ms after a POWER?).
I have two different laptops with the same touchpad hardware, one is
Are those 2 Synaptics or Goodix?
All of them are Gen-1 samples, they are Goodix samples but report
Synaptics id.
installed Linux, the touchpad can't work unless we apply this patch or
disable runtime in the i2c-hid-core.c, the other is installed windows10,
the touchapd can't work too after installation, after a upgrade online,
What do you mean by "after a upgrade online, the touchpad can work"?
Windows10 upgrade, it will search and install the drivers for hardware.
After installing the touchpad driver from the internet, the touchpad can
work.
the touchpad can work. I am willing to test commands and timing under
windows, but I don't know how to do that, is there a guide?
I am using https://github.com/bentiss/SimplePeripheralBusProbe
It's quite complex to set up, but it's better than having to crack
open the laptop and put physical probes in it.
OK, I will try to setup it and catch the commands on my gen-1 touchpad.
So on my side, I have been checking on a Dell XPS 13 how Windows
handled the touchpad.
In term of features retrievals, we are similar to what Windows does.
There is a significant difference in how many times we switch the
device on and off during probe.
Windows basically switches it on once, and done.
Under Linux we tend to switch it off and on quite a lot, and this is
what I must have been told. This has a tendency to confuse some
hardware, so we better fix that.
Yes, I also observed many times of SLEEP and ON under Linux.
In terms of timing, I do not see any special sleep after a wake up. So
I guess this must be a goodix limitation.
Last, on S3 suspend of the touchpad, I see:
set feature latency low
SET_POWER sleep
then on resume:
SET_POWER on
set feature latency normal
set feature latency normal
set feature button on, surface on
I have an almost similar sequence on runtime pm (screen going black):
suspend:
SET_POWER sleep
then on resume:
SET_POWER on
set feature latency normal
set feature latency normal
set feature button on, surface on
The only difference is that when the system is in S3, the touchpad is
set in the low latency mode.
Are they got from Linux? if "set feature xxxx" are from
hid->driver->reset_resume(), the existing runtime resume in linux
doesn't call "set feature xxx" at all, in current i2c-hid-core.c of
linux, the runtime resume is different from system resume, it doesn't
call hid->driver->reset_resume().
So unless you have such data, which would save me some time, I'll put
this patch on hold because this feels really wrong to have to quirk
such a device.
After I confirm that the touchpad Goodix (27c6:01f0) doesn't work after
S3, I will send a revert patch for 74e7c6c877f6 ("HID: i2c-hid: Disable
runtime PM on Synaptics touchpad") and a new patch to improve
77ae0d8e401f ("HID: i2c-hid: Disable runtime PM on Goodix touchpad").
Thanks for that.
Cheers,
Benjamin
