aboutsummaryrefslogtreecommitdiff
path: root/hw/usb/hcd-ehci.c
AgeCommit message (Collapse)AuthorFilesLines
2012-04-26usb-ehci: Ensure frindex writes leave a valid frindex valueHans de Goede1-0/+4
frindex is a 14 bits counter, so bits 31-14 should always be 0, and after the commit titled "usb-ehci: frindex always is a 14 bits counter" we rely on frindex always being a multiple of 8. I've not seen this in practice, but theoretically a guest can write a value >= 0x4000 or a value which is not a multiple of 8 value to frindex, this patch ensures that things will still work when that happens. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-04-26usb-ehci: add missing usb_packet_init() callGerd Hoffmann1-0/+1
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-04-26usb-ehci: remove hackGerd Hoffmann1-18/+0
To answer the question in the comment removed by this patch: I think this was needed because several places in the ehci emulation did not check the T bit of link entries correctly and thus might have followed invalid references. See commit 2a5ff735dc1074171a0cbb1dc228d6d6e907f571 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-04-17usb-ehci: drop assert()Gerd Hoffmann1-1/+0
Not sure what the purpose of the assert() was, in any case it is bogous. We can arrive there if transfer descriptors passed to us from the guest failed to pass sanity checks, i.e. it is guest-triggerable. We deal with that case by resetting the host controller. Everything is ok, no need to throw a core dump here. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-04-17usb-ehci: Drop unused sofv valueHans de Goede1-8/+0
The sofv value only ever gets a value assigned and is never used (read) anywhere, so we can just drop it. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-04-17usb-ehci: frindex always is a 14 bits counterHans de Goede1-2/+6
frindex always is a 14 bits counter, and not a 13 bits one as we were emulating. There are some subtle hints to this in the spec, first of all "Table 2-12. FRINDEX - Frame Index Register" says: "Bit 13:0 Frame Index. The value in this register increments at the end of each time frame (e.g. micro-frame). Bits [N:3] are used for the Frame List current index. This means that each location of the frame list is accessed 8 times (frames or micro-frames) before moving to the next index. The following illustrates values of N based on the value of the Frame List Size field in the USBCMD register. USBCMD[Frame List Size] Number Elements N 00b 1024 12 01b 512 11 10b 256 10 11b Reserved" Notice how the text talks about "Bits [N:3]" are used ..., it does NOT say that when N == 12 (our case) the counter will wrap from 8191 to 0, or in otherwords that it is a 13 bits counter (bits 0 - 12). The other hint is in "Table 2-10. USBSTS USB Status Register Bit Definitions": "Bit 3 Frame List Rollover - R/WC. The Host Controller sets this bit to a one when the Frame List Index (see Section 2.3.4) rolls over from its maximum value to zero. The exact value at which the rollover occurs depends on the frame list size. For example, if the frame list size (as programmed in the Frame List Size field of the USBCMD register) is 1024, the Frame Index Register rolls over every time FRINDEX[13] toggles. Similarly, if the size is 512, the Host Controller sets this bit to a one every time FRINDEX[12] toggles." Notice how this text talks about setting bit 3 when bit 13 of frindex toggles (when there are 1024 entries, so our case), so this indicates that frindex has a bit 13 making it a 14 bit counter. Besides these clear hints the real proof is in the pudding. Before this patch I could not stream data from a USB2 webcam under Windows XP, after this cam using a USB2 webcam under Windows XP works fine, and no regressions with other operating systems were seen. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-04-17usb-ehci: fix ehci_child_detachGerd Hoffmann1-1/+0
Looks like a cut+paste bug from ehci_detach. When the device itself is detached from a ehci port (ehci_detach op) we have to clear the device pointer for the companion port too. When a device gets removed from a downstream port of a usb hub (ehci_child_detach op) the ehci port where the usb hub is plugged in is not affected. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-03-13usb-ehci: drop unused isoch_pause variableHans de Goede1-5/+1
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-03-13usb: the big renameGerd Hoffmann1-0/+2345
Reorganize usb source files. Create a new hw/usb/ directory and move all usb source code to that place. Also make filenames a bit more descriptive. Host adapters are prefixed with "hch-" now, usb device emulations are prefixed with "dev-". Fixup paths Makefile and include paths to make it compile. No code changes. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>