dwc_otg: pay attention to qh->interval when rescheduling periodic queues #4617
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A regression introduced in raspberrypi#3887 meant that if the newly scheduled transfer immediately returned data, and the driver resubmitted a single URB after every transfer, then the effective polling interval would end up being approx 1ms. Use the larger of SCHEDULE_SLOP or the configured endpoint interval. Signed-off-by: Jonathan Bell <[email protected]>
|
That works for me. FYI, I've been testing on a Pi 2 (Pi 3 should also be affected) using a USB mouse and the following command: Start it without disturbing the mouse, move the mouse in circles for as close to 10 seconds as you can, then hit Ctrl-C. The number of records is the number of mouse events. A correct result is something close to 600, indicating 60Hz polling. |
popcornmix
added a commit
to raspberrypi/firmware
that referenced
this pull request
Oct 6, 2021
popcornmix
added a commit
to Hexxeh/rpi-firmware
that referenced
this pull request
Oct 6, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A regression introduced in #3887
meant that if the newly scheduled transfer immediately returned data, and
the driver resubmitted a single URB after every transfer, then the effective
polling interval would end up being approx 1ms.
Use the larger of SCHEDULE_SLOP or the configured endpoint interval.
--
This fixes the broken mousepoll behaviour on Pi 1.