- 07 6月, 2012 15 次提交
-
-
由 Gerd Hoffmann 提交于
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
When the enable bits for controller / async schedule / periodic schedule change just make sure we kick the frame timer and let ehci_advance_periodic_state and ehci_advance_async_state handle the controller state changes. This will make ehci set USBSTS_HALT when the controller shutdown is actually done, once both schedules are in inactive state and the USBSTS_PSS and USBSTS_ASS bits are clear. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
Update the status register in the ehci_set_state function, to make sure the guest-visible register is in sync with our internal schedule state. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
Add helper functions to query whenever the async / periodic schedule is enabled or not. Put them into use too. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
Check for the reset bit first when processing USBCMD register writes. Also break out of the switch, there is no need to check the other bits. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
Kick async schedule when we get a wakeup notification from a usb device. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
When a packet completes which happens to be part of the async schedule kick the async bottom half for processing, Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
This way we can kick the async schedule independant from the periodic frame timer. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
Keep track whenever a EHCIQueue is part of the async or periodic schedule. This way we don't have to pass around the async flag everywhere but can look it up from the EHCIQueue struct when needed. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
Little tweak for the queue initialization, set the QH address in the allocation function. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
Add packet queuing. Follow the qTD chain to see if there are more packets we can submit. Improves performance on larger transfers, especially with usb-host, as we don't have to wait for a packet to finish before sending the next one to the host for processing. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
Move ehci_flush_qh() function up in the source code. No code change. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
Keep a USBDevice pointer in EHCIQueue so we don't have to lookup the device on each usb packet submission. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
This way it is possible to use ehci_execute to submit others than the first EHCIPacket of the EHCIQueue. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
Add a separate EHCIPacket struct and move fields over from EHCIQueue. Preparing for supporting multiple packets per queue being in flight at the same time. No functional changes yet. Fix some codestyle issues along the way. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
- 14 5月, 2012 1 次提交
-
-
由 Jim Meyering 提交于
These were identified using: http://github.com/lyda/misspell-check and run like this to create a bourne shell script using GNU sed's -i option: git ls-files|grep -vF .bin | misspellings -f - |grep -v '^ERROR:' |perl \ -pe 's/^(.*?)\[(\d+)\]: (\w+) -> "(.*?)"$/sed -i '\''${2}s!$3!$4!'\'' $1/' Manually eliding the FP, "rela->real" and resolving "addres" to address (not "adders") we get this: sed -i '450s!thru!through!' Changelog sed -i '260s!neccessary!necessary!' coroutine-sigaltstack.c sed -i '54s!miniscule!minuscule!' disas.c sed -i '1094s!thru!through!' hw/usb/hcd-ehci.c sed -i '1095s!thru!through!' hw/usb/hcd-ehci.c sed -i '21s!unecessary!unnecessary!' qapi-schema-guest.json sed -i '307s!explictly!explicitly!' qemu-ga.c sed -i '490s!preceeding!preceding!' qga/commands-posix.c sed -i '792s!addres!address!' qga/commands-posix.c sed -i '6s!beeing!being!' tests/tcg/test-mmap.c Also, manually fix "arithmentic", spotted by Peter Maydell: sed -i 's!arithmentic!arithmetic!' coroutine-sigaltstack.c Signed-off-by: NJim Meyering <meyering@redhat.com> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 26 4月, 2012 3 次提交
-
-
由 Hans de Goede 提交于
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: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
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 2a5ff735Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
- 17 4月, 2012 4 次提交
-
-
由 Gerd Hoffmann 提交于
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: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
The sofv value only ever gets a value assigned and is never used (read) anywhere, so we can just drop it. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
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: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
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: NGerd Hoffmann <kraxel@redhat.com>
-
- 13 3月, 2012 2 次提交
-
-
由 Hans de Goede 提交于
Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
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: NGerd Hoffmann <kraxel@redhat.com>
-
- 07 3月, 2012 11 次提交
-
-
由 Hans de Goede 提交于
We already have USB_RET_NAK, but that means that a device does not want to send/receive right now. But with host / network redirection we can actually have a transaction fail due to some io error, rather then ie the device just not having any data atm. This patch adds a new error code named USB_RET_IOERROR for this, and uses it were appropriate. Notes: -Currently all usb-controllers handle this the same as NODEV, but that may change in the future, OHCI could indicate a CRC error instead for example. -This patch does not touch hw/usb-musb.c, that is because the code in there handles STALL and NAK specially and has a if status < 0 generic catch all for all other errors Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
All error statuses except for NAK are handled in a switch case, move the handling of NAK into the same switch case. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
The nakcnt code in ehci_execute_complete() marked transactions as finished when a packet completed with a result of USB_RET_NAK, but USB_RET_NAK means that the device cannot receive / send data at that time and that the transaction should be retried later, which is also what the usb-uhci and usb-ohci code does. Note that there already was some special code in place to handle this for interrupt endpoints in the form of doing a return from ehci_execute_complete() when reload == 0, but that for bulk transactions this was not handled correctly (where as for example the usb-ccid device does return USB_RET_NAK for bulk packets). Besides that the code in ehci_execute_complete() decrement nakcnt by 1 on a packet result of USB_RET_NAK, but -since the transaction got marked as finished, nakcnt would never be decremented again -there is no code checking for nakcnt becoming 0 -there is no use in re-trying the transaction within the same usb frame / usb-ehci frame-timer call, since the status of emulated devices won't change as long as the usb-ehci frame-timer is running So we should simply set the nakcnt to 0 when we get a USB_RET_NAK, thus claiming that we've tried reload times (or as many times as possible if reload is 0). Besides the code in ehci_execute_complete() handling USB_RET_NAK there was also code handling it in ehci_state_executing(), which calls ehci_execute_complete(), and then does its own handling on top of the handling in ehci_execute_complete(), this code would decrement nakcnt *again* (if not already 0), or restore the reload value (which was never changed) on success. Since the double decrement was wrong to begin with, and is no longer needed now that we set nakcnt directly to 0 on USB_RET_NAK, and the restore of reload is not needed either, this patch simply removes all nakcnt handling from ehci_state_executing(). Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
This patch removes 2 bits of dead nakcnt code: 1) usb_ehci_execute calls ehci_qh_do_overlay which does: nakcnt = reload; and then has a block of code which is conditional on: if (reload && !nakcnt) { which ofcourse is never true now as nakcnt == reload. 2) ehci_state_fetchqh does: nakcnt = reload; but before nakcnt is ever used ehci_state_fetchqh is always followed by a ehci_qh_do_overlay call which also does: nakcnt = reload; So doing this from ehci_state_fetchqh is redundant. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
cerr should only be decremented on errors which cause XactErr to be set, and when that happens the failing transaction should be retried until cerr reaches 0 and only then should USBSTS_ERRINT be set (and inactive cleared and USBSTS_INT set if requested). Since we don't have any hardware level errors (and in case of redirection the real hardware has already retried), re-trying makes no sense, so immediately set cerr to 0 on errors which set XactErr. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
As clearly stated in the 2.3.2 of the EHCI spec, any time USBERRINT get sets then if the td has its IOC bit set USBINT should be set as well. This means that for any status except for USB_RET_NAK we should set USBINT if the IOC bit is set. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
The purpose of the IAAD bit / the doorbell is to make the ehci controller forget about cached qhs, this is mainly used when cancelling transactions, the qh is unlinked from the async schedule and then the doorbell gets rung, once the doorbell is acked by the controller the hcd knows that the qh is no longer in use and that it can do something else with the memory, such as re-use it for a new qh! But we keep our struct representing this qh around for circa 250 ms. This allows for a (mightily large) race window where the following could happen: -hcd submits a qh at address 0xdeadbeef -our ehci code sees the qh, sends a request to a usb-device, gets a result of USB_RET_ASYNC, sets the async_state of the qh to EHCI_ASYNC_INFLIGHT -hcd unlinks the qh at address 0xdeadbeef -hcd rings the doorbell, wait for us to ack it -hcd re-uses the qh at address 0xdeadbeef -our ehci code sees the qh, looks in the async_queue, sees there already is a qh at address 0xdeadbeef there with async_state of EHCI_ASYNC_INFLIGHT, does nothing -the *original* (which the hcd thinks it has cancelled) transaction finishes -our ehci code sees the qh on yet another pass through the async list, looks in the async_queue, sees there already is a qh at address 0xdeadbeef there with async_state of EHCI_ASYNC_COMPLETED, and finished the transaction with the results of the *original* transaction. Not good (tm), this patch fixes this race by removing all qhs which have not been seen during the last cycle through the async list immidiately when the doorbell is rung. Note this patch does not fix any actually observed problem, but upon reading of the EHCI spec it became apparent to me that the above race could happen and the usb-ehci behavior from before this patch is not good. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
Before this patch USB 2 devices with interrupt endpoints were not working properly. The problem is that to avoid loops we stop processing as soon as we encounter a queue-head (qh) we've already seen since qhs can be linked in a circular fashion, this is tracked by the seen flag in our qh struct. The resetting of the seen flag is done from ehci_queues_rip_unused which before this patch was only called when executing the statemachine for the async schedule. But packets for interrupt endpoints are part of the periodic schedule! So what would happen is that when there were no ctrl or bulk packets for a USB 2 device with an interrupt endpoint, the async schedule would become non active, then ehci_queues_rip_unused would no longer get called and when processing the qhs for the interrupt endpoints from the periodic schedule their seen bit would still be 1 and they would be skipped. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
qhs can be part of both the async and the periodic schedule, as is shown in later patches in this series it is useful to keep track of the qhs on a per schedule basis. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
Before this patch the T-bit was not checked in 2 places, while it should be. Once we properly check the T-bit everywhere we no longer need the weird entry < 0x1000 and entry > 0x1000 checks, so this patch removes them. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
- 27 2月, 2012 4 次提交
-
-
由 Gerd Hoffmann 提交于
Drop the "ehci under development" banner. Drop unused & inactive (#if 0) code. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
Before this patch the ehci code was not checking for any other errors other then USB_RET_NAK. This causes 2 problems: 1) Other errors are not reported to the guest. 2) When transactions with the ITD_XACT_IOC bit set completing with another error would not result in USBSTS_INT getting set. I hit this problem when unplugging devices while iso data was streaming from the device to the guest. When this happens it takes a while for the guest to process the unplugging and remove ISO transactions from the ehci schedule, in the mean time these transactions would complete with a result of USB_RET_NODEV, which was not handled. This lead to the Linux guest's usb subsystem "hanging", that is it would no longer see new usb devices getting plugged in and running for example lsusb would lead to a stuck (D state) lsusb process. This patch fixes this. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
This patch adds a sanity check to itd processing to make sure the endpoint addressed by the guest is actually an iso endpoint. Also verify that usb drivers don't return USB_RET_ASYNC which is illegal for iso xfers. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
Two reset fixes: * pick up s->usbcmd value after ehci_reset call to make sure it keeps the reset value and doesn't get rubbish filled in when val is written back to the mmio register array later on. * make sure the frame timer is zapped on reset. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-