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.
Created attachment 258233 [details] 4.8 analyze_suspend.py result w/o ftrace enabled No 5 retries.
Created attachment 258237 [details] 4.12 analyze_suspend.py result w/o ftrace enabled 5 retries, each of which consumes 1 second.
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.
It looks the issue can be fixed by https://www.spinics.net/lists/stable/msg182033.html. Let me paste new test results.
Created attachment 258361 [details] 4.11 analyze_suspend.py result w/o ftrace enabled (v1 applied)