Bug 196851 - Lenovo Yoga 3 Pro: rmi_reset_attn_mode() consumes 5seconds during resume
Summary: Lenovo Yoga 3 Pro: rmi_reset_attn_mode() consumes 5seconds during resume
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_input-devices
URL:
Keywords:
Depends on:
Blocks: 178231
  Show dependency tree
 
Reported: 2017-09-07 01:24 UTC by Lv Zheng
Modified: 2017-09-14 05:00 UTC (History)
4 users (show)

See Also:
Kernel Version: 4.11
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
4.8 analyze_suspend.py result w/o ftrace enabled (75.04 KB, application/x-gzip-compressed)
2017-09-07 01:37 UTC, Lv Zheng
Details
4.12 analyze_suspend.py result w/o ftrace enabled (80.73 KB, application/x-gzip-compressed)
2017-09-07 01:39 UTC, Lv Zheng
Details
4.11 analyze_suspend.py result w/o ftrace enabled (v1 applied) (74.64 KB, application/x-gzip-compressed)
2017-09-14 05:00 UTC, Lv Zheng
Details

Description Lv Zheng 2017-09-07 01:24:13 UTC
analyze_suspend.py running on Lenovo Yoga 3 Pro shows a regression in recent kernels.

In rmi_reset_attn_mode(), in the following code path:
i2c_hid_resume (drivers/hid/i2c-hid.c)
  rmi_post_resume (drivers/hid/hid-rmi.c)
    rmi_reset_attn_mode (drivers/hid/hid-rmi.c)
      rmi_driver_reset_handler (drivers/input/rmi4/rmi_driver.c)
        rmi_hid_read_block (drivers/hid/hid-rmi.c)
          ...
There are 5 retries of rmi_write_report() transaction invoked in rmi_hid_read_block(), each of which times out of 1 second on Lenovo Yoga 3 Pro.
Comment 1 Lv Zheng 2017-09-07 01:37:45 UTC
Created attachment 258233 [details]
4.8 analyze_suspend.py result w/o ftrace enabled

No 5 retries.
Comment 2 Lv Zheng 2017-09-07 01:39:05 UTC
Created attachment 258237 [details]
4.12 analyze_suspend.py result w/o ftrace enabled

5 retries, each of which consumes 1 second.
Comment 3 Andrew Duggan 2017-09-07 23:55:59 UTC
It sounds like this delay is the result of this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1431375

Once this issue is fixed there won't be a delay. A patch has been posted with a fix, but it looks like there hasn't been a v2 patch submitted yet.

https://www.spinics.net/lists/stable/msg182033.html

But, in the failure case we can definately reduce the timeout. One second is probably excessive. Also, we can probably get away with less retries.
Comment 4 Lv Zheng 2017-09-14 04:59:45 UTC
It looks the issue can be fixed by https://www.spinics.net/lists/stable/msg182033.html.
Let me paste new test results.
Comment 5 Lv Zheng 2017-09-14 05:00:55 UTC
Created attachment 258361 [details]
4.11 analyze_suspend.py result w/o ftrace enabled (v1 applied)

Note You need to log in before you can comment on or make changes to this bug.