New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unusable touchpad with kernel param `idle=nomwait` #24

Closed
ain101 opened this Issue Nov 26, 2016 · 17 comments

Comments

Projects
None yet
3 participants
@ain101
Collaborator

ain101 commented Nov 26, 2016

When I use the kernel param idle=nomwait and reboot 2-3 times the touchpad
gets into an unusable state.
It makes no difference whether this dkms driver is used or not.
4.8.0-27-generic
Kubuntu 16.10 (also works with live USB stick)
Asus rog g501vw

http://pastebin.com/Dm2HDs7X

[   20.970241] i2c_hid i2c-FTE1001:00: failed to reset device.
[   27.114228] i2c_hid i2c-FTE1001:00: failed to reset device.
[   28.138218] i2c_hid i2c-FTE1001:00: can't add hid device: -61
[   28.162203] i2c_hid: probe of i2c-FTE1001:00 failed with error -61

The only way getting it working again is to remove idle=nomwait or shutdown
completely.
I don't see an obvious way how idle=nomwait can cause this.
I think reseting the asus touchpad is quit fragile and some variations
introduced by idle=nomwait break the procedure.
This makes sense for me because the touchpad is working after a complete
shutdown and reboot which would be a perfect reset.
http://permalink.gmane.org/gmane.linux.kernel.commits.head/153381

@redmcg

This comment has been minimized.

Show comment
Hide comment
@redmcg

redmcg Nov 27, 2016

Collaborator

That's an interesting one. Can't say I understand why the nomwait would cause this issue - but there is definitely a problem with this device around the reset.

You might want to try my fork of this driver:
https://github.com/redmcg/hid-asus-dkms

I've made a change to the i2c-hid module (which is included in my version of the dkms package) to do the reset and request the HID report descriptor in parallel. I tried this after stumbling across this document:
https://msdn.microsoft.com/en-us/windows/hardware/drivers/hid/plug-and-play-support-and-power-management

The device seems to behave better with this.

My guess at the problem is that the device isn't raising its interrupt after completing the reset request - but then requesting the HID report descriptor seems to prompt it.

Collaborator

redmcg commented Nov 27, 2016

That's an interesting one. Can't say I understand why the nomwait would cause this issue - but there is definitely a problem with this device around the reset.

You might want to try my fork of this driver:
https://github.com/redmcg/hid-asus-dkms

I've made a change to the i2c-hid module (which is included in my version of the dkms package) to do the reset and request the HID report descriptor in parallel. I tried this after stumbling across this document:
https://msdn.microsoft.com/en-us/windows/hardware/drivers/hid/plug-and-play-support-and-power-management

The device seems to behave better with this.

My guess at the problem is that the device isn't raising its interrupt after completing the reset request - but then requesting the HID report descriptor seems to prompt it.

@redmcg

This comment has been minimized.

Show comment
Hide comment
@redmcg

redmcg Dec 1, 2016

Collaborator

@ain101 Did you get a chance to try the modified i2c-hid? I'm wondering if it made any difference

Collaborator

redmcg commented Dec 1, 2016

@ain101 Did you get a chance to try the modified i2c-hid? I'm wondering if it made any difference

@ain101

This comment has been minimized.

Show comment
Hide comment
@ain101

ain101 Dec 2, 2016

Collaborator

I tried your fork. It doesn't seem to perform much differently than without. (all logicdata containing "red" is with your fork)
I did more sniffing: https://github.com/ain101/drivers-input-touchscreen-FTS_driver/tree/master/doc/sniff/logic%20analyzer/nomwait%20problem

This picture shows the problem: https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/doc/sniff/logic%20analyzer/nomwait%20problem/3rd%20line%20problem.png

The thing in the middle is working. Notice the two channels on top. (this was a cold boot)
This seems to be a mechanism for the touchpad to signal its master when it has new data or reseted successfully?

also interesting:
https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/doc/sniff/logic%20analyzer/nomwait%20problem/linux%20boot%20error%20finger%20drag%20between%20failed%20to%20reset.logicdata
While "i2c_hid i2c-FTE1001:00: failed to reset device." is performed several times I draged the finger 2 times across the pad. The data shows up but isn't interpreted by linux because the pad doesn't work like the driver expects. After the driver has given up with resetting no more data is sent for some reason?
I also captured working initializations where it took 1-2 resetting attempts, but then the lines go low and the pad is working. https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/doc/sniff/logic%20analyzer/nomwait%20problem/linux%20reboot%20working%20removed%20nomwait.logicdata
(reboot without nomwait)

Collaborator

ain101 commented Dec 2, 2016

I tried your fork. It doesn't seem to perform much differently than without. (all logicdata containing "red" is with your fork)
I did more sniffing: https://github.com/ain101/drivers-input-touchscreen-FTS_driver/tree/master/doc/sniff/logic%20analyzer/nomwait%20problem

This picture shows the problem: https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/doc/sniff/logic%20analyzer/nomwait%20problem/3rd%20line%20problem.png

The thing in the middle is working. Notice the two channels on top. (this was a cold boot)
This seems to be a mechanism for the touchpad to signal its master when it has new data or reseted successfully?

also interesting:
https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/doc/sniff/logic%20analyzer/nomwait%20problem/linux%20boot%20error%20finger%20drag%20between%20failed%20to%20reset.logicdata
While "i2c_hid i2c-FTE1001:00: failed to reset device." is performed several times I draged the finger 2 times across the pad. The data shows up but isn't interpreted by linux because the pad doesn't work like the driver expects. After the driver has given up with resetting no more data is sent for some reason?
I also captured working initializations where it took 1-2 resetting attempts, but then the lines go low and the pad is working. https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/doc/sniff/logic%20analyzer/nomwait%20problem/linux%20reboot%20working%20removed%20nomwait.logicdata
(reboot without nomwait)

@ain101

This comment has been minimized.

Show comment
Hide comment
@ain101

ain101 Dec 3, 2016

Collaborator

Maybe the long wires I attached for sniffing are messing with the pad. I will look at it with a scope.

Collaborator

ain101 commented Dec 3, 2016

Maybe the long wires I attached for sniffing are messing with the pad. I will look at it with a scope.

@redmcg

This comment has been minimized.

Show comment
Hide comment
@redmcg

redmcg Dec 3, 2016

Collaborator

Channel 3 appears to be the interrupt - and it is used by the Touchpad (which is an i2c client at address 0x15) to tell the i2c host that it has data. This prompts the i2c host to:

  1. start the clock signal; and
  2. send the "read to 0x15" (you need to set addresses to 7 bits in the analyser to get the correct addresses displayed).

After the Touchpad sees the "read to 0x15" it will send its data.

To acknowledge a reset instruction (which is 0x05 0x00 0x00 0x01 in hex) the Touchpad should pull the interrupt and send two bytes of 0x00 0x00 (actually I can see in the working traces that it sends a lot more than two bytes of 0x00 - but more than two doesn't hurt).

The following screenshot compares a working reset vs a failed one:
working vs not working

So you can see in the failed reset the interrupt is never pulled. It just stays high the whole time.

In my fork - I changed the i2c-hid module to send a request for a "report descriptor" (0x02 0x00 in hex) before even looking for the reset response - but I don't see this in your trace. It could be the DKMS module wasn't in the initrd and therefore the old one was still being used.

But I just made some changes to the i2c-hid module in my fork. In addition to fixing a couple of issues with it - I changed the reset error messages. This will help us be sure that it is the DKMS module being used.

So if you want to try it - do a git pull from my fork and reinstall with ./dkms-add.sh. I haven't had a chance to test it yet though - so if you try it and it causes any issues - you might need to go back one commit (with git reset --hard HEAD^).

Edit: I've tested now and it seems to be OK

Collaborator

redmcg commented Dec 3, 2016

Channel 3 appears to be the interrupt - and it is used by the Touchpad (which is an i2c client at address 0x15) to tell the i2c host that it has data. This prompts the i2c host to:

  1. start the clock signal; and
  2. send the "read to 0x15" (you need to set addresses to 7 bits in the analyser to get the correct addresses displayed).

After the Touchpad sees the "read to 0x15" it will send its data.

To acknowledge a reset instruction (which is 0x05 0x00 0x00 0x01 in hex) the Touchpad should pull the interrupt and send two bytes of 0x00 0x00 (actually I can see in the working traces that it sends a lot more than two bytes of 0x00 - but more than two doesn't hurt).

The following screenshot compares a working reset vs a failed one:
working vs not working

So you can see in the failed reset the interrupt is never pulled. It just stays high the whole time.

In my fork - I changed the i2c-hid module to send a request for a "report descriptor" (0x02 0x00 in hex) before even looking for the reset response - but I don't see this in your trace. It could be the DKMS module wasn't in the initrd and therefore the old one was still being used.

But I just made some changes to the i2c-hid module in my fork. In addition to fixing a couple of issues with it - I changed the reset error messages. This will help us be sure that it is the DKMS module being used.

So if you want to try it - do a git pull from my fork and reinstall with ./dkms-add.sh. I haven't had a chance to test it yet though - so if you try it and it causes any issues - you might need to go back one commit (with git reset --hard HEAD^).

Edit: I've tested now and it seems to be OK

@redmcg

This comment has been minimized.

Show comment
Hide comment
@redmcg

redmcg Dec 3, 2016

Collaborator

After the driver has given up with resetting no more data is sent for some reason?

This is because the driver instructs the Touchpad to go to sleep (0x05 0x00 0x01 0x08 in hex).

Maybe the long wires I attached for sniffing are messing with the pad. I will look at it with a scope.

Could be - but both Victor and I have seen the "failed to reset device." error message. I haven't had it completely fail yet (which happens after 3 retries). But I haven't seen that error since using my version of the i2c-hid module. My guess is that the request for the "report descriptor" prompts the Touchpad to pull its interrupt. It'll be interesting to see a trace as that will confirm.

Collaborator

redmcg commented Dec 3, 2016

After the driver has given up with resetting no more data is sent for some reason?

This is because the driver instructs the Touchpad to go to sleep (0x05 0x00 0x01 0x08 in hex).

Maybe the long wires I attached for sniffing are messing with the pad. I will look at it with a scope.

Could be - but both Victor and I have seen the "failed to reset device." error message. I haven't had it completely fail yet (which happens after 3 retries). But I haven't seen that error since using my version of the i2c-hid module. My guess is that the request for the "report descriptor" prompts the Touchpad to pull its interrupt. It'll be interesting to see a trace as that will confirm.

@vlasenko

This comment has been minimized.

Show comment
Hide comment
@vlasenko

vlasenko Dec 3, 2016

Owner

@redmcg I would like to throw an idea, but it can be completely wrong or misleading. The thing is we didn't see the same behavior in Windows driver, i.e. that it tries to force interrupt on reset somehow. Because TouchPad is behind i2c_designware bus, maybe there is some problem in Linux designware driver?

Owner

vlasenko commented Dec 3, 2016

@redmcg I would like to throw an idea, but it can be completely wrong or misleading. The thing is we didn't see the same behavior in Windows driver, i.e. that it tries to force interrupt on reset somehow. Because TouchPad is behind i2c_designware bus, maybe there is some problem in Linux designware driver?

@redmcg

This comment has been minimized.

Show comment
Hide comment
@redmcg

redmcg Dec 4, 2016

Collaborator

@vlasenko It's possible. The trace that @ain101 is taking is between the i2c controller and the TouchPad - so it's intra board (i.e. whilst waiting for the interrupt - there's no interaction with the CPU/drivers). But it could be that the i2c_designware driver is setting up the bus clock or voltages or is responsible for some other electronic interaction (like maybe it's suppose to pull another wire to wake the TouchPad up). But I don't see anything different happening in the Logicdata between a successful and failed interaction. The TouchPad is ACKing every byte of the reset request too - so it seems to have received it OK.

According to section 7.2.1.2 of the I2C HID spec, once the TouchPad receives the reset request, its job is to:

  1. reset its config;
  2. send two bytes of 0x00; and
  3. assert the interrupt

But we don't see this happening, so it seems the problem is with the TouchPad. I'm thinking it could be a firmware issue and that maybe sending the request for the report descriptor in parallel (like the Windows spec says it does) prompts the firmware to complete the reset activity.

We'll know better if @ain101 can reproduce the issue with my version of the i2c-hid driver (showing the report descriptor request [0x02 0x00] with still no interrupt).

Collaborator

redmcg commented Dec 4, 2016

@vlasenko It's possible. The trace that @ain101 is taking is between the i2c controller and the TouchPad - so it's intra board (i.e. whilst waiting for the interrupt - there's no interaction with the CPU/drivers). But it could be that the i2c_designware driver is setting up the bus clock or voltages or is responsible for some other electronic interaction (like maybe it's suppose to pull another wire to wake the TouchPad up). But I don't see anything different happening in the Logicdata between a successful and failed interaction. The TouchPad is ACKing every byte of the reset request too - so it seems to have received it OK.

According to section 7.2.1.2 of the I2C HID spec, once the TouchPad receives the reset request, its job is to:

  1. reset its config;
  2. send two bytes of 0x00; and
  3. assert the interrupt

But we don't see this happening, so it seems the problem is with the TouchPad. I'm thinking it could be a firmware issue and that maybe sending the request for the report descriptor in parallel (like the Windows spec says it does) prompts the firmware to complete the reset activity.

We'll know better if @ain101 can reproduce the issue with my version of the i2c-hid driver (showing the report descriptor request [0x02 0x00] with still no interrupt).

@ain101

This comment has been minimized.

Show comment
Hide comment
@ain101

ain101 Dec 5, 2016

Collaborator

I can not reproduce the issue with the changed i2c-hid driver.
I have come up with 4 solutions now:
don't use kernel param idle=nomwait
use new i2c-hid
no rebooting
do something unknown (I am currently not able to reproduce this bug on the ubuntu 16.10 which I mainly use on this laptop.)

New driver reads report descriptor without waiting for interrupt line. 56ms later the interupt line is pulled and zeros are sent.
https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/doc/sniff/logic%20analyzer/nomwait%20problem/linux%20reboot%20redmcg.logicdata

But it could be that the i2c_designware driver is setting up the bus clock or voltages or is responsible
for some other electronic interaction (like maybe it's suppose to pull another wire to wake the
TouchPad up).

I think this is possible: page 11 (INT/E8/15) https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/doc/FT5x46.pdf
I am sniffing every connection between touchpad and motherboard except power.
In normal operation this line clearly is used for signaling that new data is available.
first trace:
https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/doc/sniff/logic%20analyzer/nomwait%20problem/3rd%20line%20problem.png
logicdata:
https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/doc/sniff/logic%20analyzer/linux%20multitouch%20swipe.logicdata

I should have looked at this pdf sooner.
There is also an UART connected to a testpoint. Maybe Asus left some debugging strings.
Neither Linux nor Windows seem to pull the RSTN line. It is alwayse high.
When I pull RSTN the touchpad switches back to mouse mode.

Collaborator

ain101 commented Dec 5, 2016

I can not reproduce the issue with the changed i2c-hid driver.
I have come up with 4 solutions now:
don't use kernel param idle=nomwait
use new i2c-hid
no rebooting
do something unknown (I am currently not able to reproduce this bug on the ubuntu 16.10 which I mainly use on this laptop.)

New driver reads report descriptor without waiting for interrupt line. 56ms later the interupt line is pulled and zeros are sent.
https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/doc/sniff/logic%20analyzer/nomwait%20problem/linux%20reboot%20redmcg.logicdata

But it could be that the i2c_designware driver is setting up the bus clock or voltages or is responsible
for some other electronic interaction (like maybe it's suppose to pull another wire to wake the
TouchPad up).

I think this is possible: page 11 (INT/E8/15) https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/doc/FT5x46.pdf
I am sniffing every connection between touchpad and motherboard except power.
In normal operation this line clearly is used for signaling that new data is available.
first trace:
https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/doc/sniff/logic%20analyzer/nomwait%20problem/3rd%20line%20problem.png
logicdata:
https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/doc/sniff/logic%20analyzer/linux%20multitouch%20swipe.logicdata

I should have looked at this pdf sooner.
There is also an UART connected to a testpoint. Maybe Asus left some debugging strings.
Neither Linux nor Windows seem to pull the RSTN line. It is alwayse high.
When I pull RSTN the touchpad switches back to mouse mode.

@redmcg

This comment has been minimized.

Show comment
Hide comment
@redmcg

redmcg Dec 5, 2016

Collaborator

OK - I think a firmware problem is the best explanation for why the new i2c-hid fixes the issue - but Windows doesn't appear to do this (and that was the reason I made my change in the first place - because I thought it did!).

The screenshot below shows Windows working on top and Linux working (without the new i2c-hid) on the bottom.

image

The biggest difference that I can see is that Windows provides a 1ms pause between the wake-up and reset commands. Linux provides 35 µs. You can also see on Linux that the interrupt is pulled before the reset command is finished being sent - which shouldn't happen. It could just be a lucky coincidence that it worked on Linux under this circumstance.

So another possible issue is timing. But I can't see in the Logictrace any timing difference between using mwait and nomwait. And I also can't explain how the same Kernel version on Ubuntu vs. Kubuntu could make a difference. So there's still a bit of mystery there.

I'll work on another i2c-hid version which adds a 1ms pause before sending the reset and see if that fixes the issue on Linux as well.

Collaborator

redmcg commented Dec 5, 2016

OK - I think a firmware problem is the best explanation for why the new i2c-hid fixes the issue - but Windows doesn't appear to do this (and that was the reason I made my change in the first place - because I thought it did!).

The screenshot below shows Windows working on top and Linux working (without the new i2c-hid) on the bottom.

image

The biggest difference that I can see is that Windows provides a 1ms pause between the wake-up and reset commands. Linux provides 35 µs. You can also see on Linux that the interrupt is pulled before the reset command is finished being sent - which shouldn't happen. It could just be a lucky coincidence that it worked on Linux under this circumstance.

So another possible issue is timing. But I can't see in the Logictrace any timing difference between using mwait and nomwait. And I also can't explain how the same Kernel version on Ubuntu vs. Kubuntu could make a difference. So there's still a bit of mystery there.

I'll work on another i2c-hid version which adds a 1ms pause before sending the reset and see if that fixes the issue on Linux as well.

@redmcg

This comment has been minimized.

Show comment
Hide comment
@redmcg

redmcg Dec 6, 2016

Collaborator

I've made an update to my fork. I reverted my previous changes to i2c-hid and added just a single line:
usleep_range(750, 5000);

This means the i2c-hid driver will now sleep for between 750 and 5000 nanoseconds in-between sending the power on [0x05 0x00 0x00 0x08] and reset [0x05 0x00 0x00 0x01] commands.

I rebooted my system a handful of times to test it and it seems to be working.

I'd be curious to see if it fixes the issues with nomwait and Kubuntu too.

Collaborator

redmcg commented Dec 6, 2016

I've made an update to my fork. I reverted my previous changes to i2c-hid and added just a single line:
usleep_range(750, 5000);

This means the i2c-hid driver will now sleep for between 750 and 5000 nanoseconds in-between sending the power on [0x05 0x00 0x00 0x08] and reset [0x05 0x00 0x00 0x01] commands.

I rebooted my system a handful of times to test it and it seems to be working.

I'd be curious to see if it fixes the issues with nomwait and Kubuntu too.

@ain101

This comment has been minimized.

Show comment
Hide comment
@ain101

ain101 Dec 7, 2016

Collaborator

I think more time between power on and reset is the solution for this issue.
When I remove nomwait the delay between this packets also gets bigger a little bit.
In the past I sniffed data where it took up to 3 reset tries. The last one had the biggest delay.

I think the device needs some time after power on and overheard our reset packed. (100us minium)
i2c_hid spec speaks of 1 sek!

The DEVICE must ensure that it transitions to the HOST specified Power State in under 1 second. All HID DEVICES must support this command...

There should be some kind of response, but the spec says:

The DEVICE shall not respond back after receiving the command. The DEVICE is mandated to enter that power state imminently.

SET_POWER(ON) seems to be special. No 1 sec rule. Our Asus touchpad violates this.

Once the host issues a SET_POWER(ON) command, the DEVICE must transition to the ON state immediately...

One last mystery is that the interrupt is pulled before the reset command is finished. Something different must have triggered it.

Collaborator

ain101 commented Dec 7, 2016

I think more time between power on and reset is the solution for this issue.
When I remove nomwait the delay between this packets also gets bigger a little bit.
In the past I sniffed data where it took up to 3 reset tries. The last one had the biggest delay.

I think the device needs some time after power on and overheard our reset packed. (100us minium)
i2c_hid spec speaks of 1 sek!

The DEVICE must ensure that it transitions to the HOST specified Power State in under 1 second. All HID DEVICES must support this command...

There should be some kind of response, but the spec says:

The DEVICE shall not respond back after receiving the command. The DEVICE is mandated to enter that power state imminently.

SET_POWER(ON) seems to be special. No 1 sec rule. Our Asus touchpad violates this.

Once the host issues a SET_POWER(ON) command, the DEVICE must transition to the ON state immediately...

One last mystery is that the interrupt is pulled before the reset command is finished. Something different must have triggered it.

@redmcg

This comment has been minimized.

Show comment
Hide comment
@redmcg

redmcg Dec 7, 2016

Collaborator

i2c_hid spec speaks of 1 sek!

Geez! I hadn't noticed that part before.

One last mystery is that the interrupt is pulled before the reset command is finished. Something different must have triggered it.

Yeah could be. Or another firmware issue.

When I remove nomwait the delay between this packets also gets bigger a little bit.
In the past I sniffed data where it took up to 3 reset tries. The last one had the biggest delay.

It does sound more and more like a timing issue. Let me know how the new i2c-hid driver goes. If it fixes the problems with nomwait and Xubuntu - I might make raise it with the mailing list. We might need to add a new quirk to i2c-hid.

Collaborator

redmcg commented Dec 7, 2016

i2c_hid spec speaks of 1 sek!

Geez! I hadn't noticed that part before.

One last mystery is that the interrupt is pulled before the reset command is finished. Something different must have triggered it.

Yeah could be. Or another firmware issue.

When I remove nomwait the delay between this packets also gets bigger a little bit.
In the past I sniffed data where it took up to 3 reset tries. The last one had the biggest delay.

It does sound more and more like a timing issue. Let me know how the new i2c-hid driver goes. If it fixes the problems with nomwait and Xubuntu - I might make raise it with the mailing list. We might need to add a new quirk to i2c-hid.

@redmcg

This comment has been minimized.

Show comment
Hide comment
@redmcg

redmcg Dec 7, 2016

Collaborator

The DEVICE must ensure that it transitions to the HOST specified Power State in under 1 second. All HID DEVICES must support this command...

There should be some kind of response

Agreed. Looks like the i2c hid protocol was designed by Microsoft though... 😒

Collaborator

redmcg commented Dec 7, 2016

The DEVICE must ensure that it transitions to the HOST specified Power State in under 1 second. All HID DEVICES must support this command...

There should be some kind of response

Agreed. Looks like the i2c hid protocol was designed by Microsoft though... 😒

@redmcg

This comment has been minimized.

Show comment
Hide comment
@redmcg

redmcg Dec 30, 2016

Collaborator

@ain101 Have you had any issues since I added the short sleep prior to the reset command? If it's working well I might close this issue and make another kernel submission.

Collaborator

redmcg commented Dec 30, 2016

@ain101 Have you had any issues since I added the short sleep prior to the reset command? If it's working well I might close this issue and make another kernel submission.

@ain101

This comment has been minimized.

Show comment
Hide comment
@ain101

ain101 Dec 31, 2016

Collaborator

@redmcg The short sleep work for me.
It should work for everyone. Issue #33 seems to prove me wrong though.
As this issue covers my specific problem with kernel params I think it can be closed.

Collaborator

ain101 commented Dec 31, 2016

@redmcg The short sleep work for me.
It should work for everyone. Issue #33 seems to prove me wrong though.
As this issue covers my specific problem with kernel params I think it can be closed.

@vlasenko vlasenko closed this Jan 2, 2017

fengguang added a commit to 0day-ci/linux that referenced this issue Jan 5, 2017

HID: i2c-hid: Add quirk for sleep before reset
Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch adds a new QUIRK to the i2c-hid module that
allows a device to specify a specific sleep inbetween the POWER ON and
RESET commands.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>

fengguang added a commit to 0day-ci/linux that referenced this issue Jan 6, 2017

HID: i2c-hid: Add sleep between POWER ON and RESET
Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
@redmcg

This comment has been minimized.

Show comment
Hide comment
@redmcg

redmcg Jan 6, 2017

Collaborator

Just for posterity - I thought I would note that I did find that there is a way for the i2c DEVICE to tell the HOST it is ready after receiving a POWER ON command. 7.2.8.4 of the i2c_hid specification states:

Once the host issues a SET_POWER(ON) command, the DEVICE must transition to the ON state immediately. Clock stretching can be employed (up to the maximum defined limit in the “Sizes and Constants” section) if needed.

So the DEVICE can pull (and hold) the CLOCK signal low until it is ready to receive its next command. The maximum time specified is 10ms. The disadvantage here is that the whole i2c bus is held up during this period (i.e. other devices would not be able to communicate).

But it looks like the Touchpad doesn't implement this and instead relies on the 1ms pause provided by the Windows driver.

Collaborator

redmcg commented Jan 6, 2017

Just for posterity - I thought I would note that I did find that there is a way for the i2c DEVICE to tell the HOST it is ready after receiving a POWER ON command. 7.2.8.4 of the i2c_hid specification states:

Once the host issues a SET_POWER(ON) command, the DEVICE must transition to the ON state immediately. Clock stretching can be employed (up to the maximum defined limit in the “Sizes and Constants” section) if needed.

So the DEVICE can pull (and hold) the CLOCK signal low until it is ready to receive its next command. The maximum time specified is 10ms. The disadvantage here is that the whole i2c bus is held up during this period (i.e. other devices would not be able to communicate).

But it looks like the Touchpad doesn't implement this and instead relies on the 1ms pause provided by the Windows driver.

fengguang added a commit to 0day-ci/linux that referenced this issue Jan 7, 2017

HID: i2c-hid: Add sleep between POWER ON and RESET
Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>

sudipm-mukherjee pushed a commit to sudipm-mukherjee/parport that referenced this issue Jan 12, 2017

Brendan McGrath Jiri Kosina
HID: i2c-hid: Add sleep between POWER ON and RESET
Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

evan-a-a added a commit to evan-a-a/linux-braswell that referenced this issue Feb 6, 2017

HID: i2c-hid: Add sleep between POWER ON and RESET
Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

Whissi pushed a commit to Whissi/linux-stable that referenced this issue Apr 13, 2017

Brendan McGrath Jiri Slaby
HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4a upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>

nathanchance added a commit to nathanchance/angler that referenced this issue Apr 15, 2017

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4a upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>

nathanchance added a commit to nathanchance/angler that referenced this issue Apr 16, 2017

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4a upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>

Aerotinge added a commit to Aerotinge/android_kernel_mlt_mt6735 that referenced this issue Mar 31, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

Aerotinge added a commit to Aerotinge/android_kernel_mlt_mt6735 that referenced this issue Mar 31, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

Aerotinge added a commit to Aerotinge/android_kernel_mlt_mt6735 that referenced this issue Apr 1, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

Aerotinge added a commit to Aerotinge/android_kernel_mlt_mt6735 that referenced this issue Apr 1, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

Aerotinge added a commit to Aerotinge/android_kernel_mlt_mt6735 that referenced this issue Apr 1, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

Parthib24 added a commit to Parthib24/android_kernel_samsung_j23g that referenced this issue Apr 5, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

Shoaib0597 added a commit to Shoaib0597/Velocity-Lenovo_MSM8916 that referenced this issue Apr 14, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

Shoaib0597 added a commit to Shoaib0597/Velocity-Lenovo_MSM8916 that referenced this issue Apr 14, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

Thunderoar added a commit to Thunderoar/latest_goyave_kernel that referenced this issue May 12, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

EdgardMcQueen added a commit to EdgardMcQueen/android_kernel_lenovo_msm8992-1 that referenced this issue May 12, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

scafroglia93 added a commit to HardcoreKernel/angler that referenced this issue May 18, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

scafroglia93 added a commit to HardcoreKernel/bullhead that referenced this issue May 19, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

armandopartida0 added a commit to Lonelyoneskatter/android_kernel_zte_urd that referenced this issue May 20, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

kevintm78 added a commit to kevintm78/H-Vitamin that referenced this issue May 26, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

BitOBSessiOn added a commit to BitOBSessiOn/android_kernel_nvidia_shieldtablet that referenced this issue May 28, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

nutcasev15 added a commit to nutcasev15/Holo-N that referenced this issue Jun 2, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

shayankewl added a commit to shayankewl/lenovo_kernel_msm8992 that referenced this issue Jul 4, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

camcory added a commit to camcory/android_kernel_moto_shamu that referenced this issue Jul 9, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

camcory added a commit to camcory/android_kernel_moto_shamu that referenced this issue Jul 11, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

FacuM pushed a commit to FacuM/kernel_harpia that referenced this issue Jul 25, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

Sekilsgs2 added a commit to Exynos7580/android_kernel_samsung_a3xeltexx that referenced this issue Jul 29, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

Ahmed-Hady added a commit to Ahmed-Hady/android_kernel_motorola_msm8916 that referenced this issue Aug 15, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

audahadi added a commit to kernel-hut/android_kernel_xiaomi_msm8956 that referenced this issue Aug 16, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

Lonelyoneskatter added a commit to Lonelyoneskatter/android_kernel_zte_urd that referenced this issue Aug 21, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

NeonDragon1909 added a commit to Dil3mm4/labyrinth_kernel_prague that referenced this issue Aug 23, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
[ Upstream commit a89af4abdf9b353cdd6f61afc0eaaac403304873 ]

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

JBolho added a commit to JBolho/Proto that referenced this issue Aug 31, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
[ Upstream commit a89af4abdf9b353cdd6f61afc0eaaac403304873 ]

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ThePiGuy0 added a commit to ThePiGuy0/android_kernel_lge_msm8992 that referenced this issue Sep 11, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

FacuM added a commit to FacuM/android_kernel_motorola_msm8916-2 that referenced this issue Sep 14, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
commit a89af4abdf9b353cdd6f61afc0eaaac403304873 upstream.

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>

Ante0 pushed a commit to Ante0/BKL_OREO_EMUI8 that referenced this issue Sep 22, 2018

Brendan McGrath ante0
HID: i2c-hid: Add sleep between POWER ON and RESET
[ Upstream commit a89af4abdf9b353cdd6f61afc0eaaac403304873 ]

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

hackslashX added a commit to hackslashX/android_kernel_hisi_hi3650 that referenced this issue Sep 23, 2018

HID: i2c-hid: Add sleep between POWER ON and RESET
[ Upstream commit a89af4abdf9b353cdd6f61afc0eaaac403304873 ]

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See vlasenko/hid-asus-dkms#24 for further
details.

Signed-off-by: Brendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment