uhci: Fix 1 ms delay in interrupt reporting to the guest
Re-arrange how we process frames / increase frnum / report pending interrupts,to avoid a 1 ms delay in interrupt reporting to the guest. This increasesthe packet throughput for cases where the guest submits a single packet,...
uhci: Fix pending interrupts getting lost on migration
Signed-off-by: Hans de Goede <hdegoede@redhat.com>Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
uhci: Add a QH_VALID define
Rather then using the magic 32 value in various places.
uhci: Limit amount of frames processed in one go
Before this patch uhci would process an unlimited amount of frames whenbehind on schedule, by setting the timer to a time already past, causing thetimer subsys to immediately recall the frame_timer function gain....
ehci: Verify qtd for async completed packets
Remove the short-circuiting of fetchqtd in fetchqh, so that theqtd gets properly verified before completing the transaction.
ehci: Add an ehci_get_pid helper function
ehci: Verify a queue's ep direction does not change
ehci_fill_queue assumes that there is a one on one relationship between an epand a qh, this patch adds a check to ensure this.
Note I don't expect this to ever trigger, this is just something I noticed...
ehci: Use uframe precision for interrupt threshold checking (v2)
Before this patch, the following could happen:1) Transfer completes, raises interrupt2) .5 ms later we check if the guest has queued up any new transfers3) We find and execute a new transfer...
ehci: Further speedup rescanning if async schedule after raising an interrupt
I tried lowering the time between raising an interrupt and rescanning theasync schedule to see if the guest has queued a new transfer before, butthat did not have any positive effect. I now believe the cause for this is...
ehci: Don't call commit_irq after raising PCD
ehci_raise_irq(s, USBSTS_PCD), gets applied immediately so there is no needto call commit_irq after it.
View revisions
Also available in: Atom