peterdelevoryas / rpms / qemu

Forked from rpms/qemu 2 years ago
Clone

Blame 0141-usb-ehci-frindex-always-is-a-14-bits-counter.patch

0fa3e5
From 9d604ddc4770f8f25de148e9b35687817a5d4110 Mon Sep 17 00:00:00 2001
0fa3e5
From: Hans de Goede <hdegoede@redhat.com>
0fa3e5
Date: Wed, 28 Mar 2012 20:31:32 +0200
0fa3e5
Subject: [PATCH 141/146] usb-ehci: frindex always is a 14 bits counter
0fa3e5
0fa3e5
frindex always is a 14 bits counter, and not a 13 bits one as we were
0fa3e5
emulating. There are some subtle hints to this in the spec, first of all
0fa3e5
"Table 2-12. FRINDEX - Frame Index Register" says:
0fa3e5
"Bit 13:0 Frame Index. The value in this register increments at the end of
0fa3e5
each time frame (e.g. micro-frame). Bits [N:3] are used for the Frame List
0fa3e5
current index. This means that each location of the frame list is accessed
0fa3e5
8 times (frames or micro-frames) before moving to the next index. The
0fa3e5
following illustrates values of N based on the value of the Frame List
0fa3e5
Size field in the USBCMD register.
0fa3e5
0fa3e5
USBCMD[Frame List Size]	Number Elements		 N
0fa3e5
00b				1024		12
0fa3e5
01b				 512		11
0fa3e5
10b				 256		10
0fa3e5
11b			    Reserved"
0fa3e5
0fa3e5
Notice how the text talks about "Bits [N:3]" are used ..., it does
0fa3e5
NOT say that when N == 12 (our case) the counter will wrap from 8191 to 0,
0fa3e5
or in otherwords that it is a 13 bits counter (bits 0 - 12).
0fa3e5
0fa3e5
The other hint is in "Table 2-10. USBSTS USB Status Register Bit Definitions":
0fa3e5
0fa3e5
"Bit 3 Frame List Rollover - R/WC. The Host Controller sets this bit to a one
0fa3e5
when the Frame List Index (see Section 2.3.4) rolls over from its maximum value
0fa3e5
to zero. The exact value at which the rollover occurs depends on the frame
0fa3e5
list size. For example, if the frame list size (as programmed in the Frame
0fa3e5
List Size field of the USBCMD register) is 1024, the Frame Index Register
0fa3e5
rolls over every time FRINDEX[13] toggles. Similarly, if the size is 512,
0fa3e5
the Host Controller sets this bit to a one every time FRINDEX[12] toggles."
0fa3e5
0fa3e5
Notice how this text talks about setting bit 3 when bit 13 of frindex toggles
0fa3e5
(when there are 1024 entries, so our case), so this indicates that frindex
0fa3e5
has a bit 13 making it a 14 bit counter.
0fa3e5
0fa3e5
Besides these clear hints the real proof is in the pudding. Before this
0fa3e5
patch I could not stream data from a USB2 webcam under Windows XP, after
0fa3e5
this cam using a USB2 webcam under Windows XP works fine, and no regressions
0fa3e5
with other operating systems were seen.
0fa3e5
0fa3e5
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
0fa3e5
---
0fa3e5
 hw/usb-ehci.c |    8 ++++++--
0fa3e5
 1 file changed, 6 insertions(+), 2 deletions(-)
0fa3e5
0fa3e5
diff --git a/hw/usb-ehci.c b/hw/usb-ehci.c
0fa3e5
index b5d7037..3934bf0 100644
0fa3e5
--- a/hw/usb-ehci.c
0fa3e5
+++ b/hw/usb-ehci.c
0fa3e5
@@ -2157,11 +2157,15 @@ static void ehci_frame_timer(void *opaque)
0fa3e5
         if ( !(ehci->usbsts & USBSTS_HALT)) {
0fa3e5
             ehci->frindex += 8;
0fa3e5
 
0fa3e5
-            if (ehci->frindex > 0x00001fff) {
0fa3e5
-                ehci->frindex = 0;
0fa3e5
+            if (ehci->frindex == 0x00002000) {
0fa3e5
                 ehci_set_interrupt(ehci, USBSTS_FLR);
0fa3e5
             }
0fa3e5
 
0fa3e5
+            if (ehci->frindex == 0x00004000) {
0fa3e5
+                ehci_set_interrupt(ehci, USBSTS_FLR);
0fa3e5
+                ehci->frindex = 0;
0fa3e5
+            }
0fa3e5
+
0fa3e5
             ehci->sofv = (ehci->frindex - 1) >> 3;
0fa3e5
             ehci->sofv &= 0x000003ff;
0fa3e5
         }
0fa3e5
-- 
0fa3e5
1.7.9.3
0fa3e5