@@ -1341,6 +1341,9 @@ static void ehci_execute_complete(EHCIQueue *q)
if (tbytes) {
/* 4.15.1.2 must raise int on a short input packet */
ehci_raise_irq(q->ehci, USBSTS_INT);
+ if (q->async) {
+ q->ehci->int_req_by_async = true;
+ }
}
} else {
tbytes = 0;
@@ -2337,7 +2340,7 @@ static void ehci_frame_timer(void *opaque)
/* If we've raised int, we speed up the timer, so that we quickly
* notice any new packets queued up in response */
if (ehci->int_req_by_async && (ehci->usbsts & USBSTS_INT)) {
- expire_time = t_now + get_ticks_per_sec() / (FRAME_TIMER_FREQ * 2);
+ expire_time = t_now + get_ticks_per_sec() / (FRAME_TIMER_FREQ * 4);
ehci->int_req_by_async = false;
} else {
expire_time = t_now + (get_ticks_per_sec()
I tried lowering the time between raising an interrupt and rescanning the async schedule to see if the guest has queued a new transfer before, but that did not have any positive effect. I now believe the cause for this is that lowering this time made it more likely to hit the 1 ms interrupt threshold penalty for the next packet, as described in my "ehci: Use uframe precision for interrupt threshold checking" commit. Now that we do interrupt threshold handling with uframe precision, futher lowering this time from .5 to .25 ms gives an extra 15% improvement in speed (MB/s) reading from a simple USB-2.0 thumb-drive. While at it also properly set the int_req_by_async flag for short packet completions. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- hw/usb/hcd-ehci.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)