Add a flag to EHCIPCIInfo saying whenever the controller supports
companions or not.  Make sure we only allow registering companions for
ehci versions supporting that.  Enable pci hotplug for the ehci
variants not supporting companions.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

cleanup ehci controller resource, both pci and sysbus
if they're necessary.
Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

since hotunplug the ehci host adapter, we should
delete vm_change_state_handler also, so the
VMChangeStateEntry should be saved in EHCIState.
Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

imitate nearby code about using '!value' or 'value == NULL'
Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

So we can easily use them in tests.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

After previous Peter patch, they are redundant.  This way we don't
assign them except when needed.  Once there, there were lots of case
where the ".fields" indentation was wrong:

     .fields = (VMStateField []) {
and
     .fields =      (VMStateField []) {

Change all the combinations to:

     .fields = (VMStateField[]){

The biggest problem (appart from aesthetics) was that checkpatch complained
when we copy&pasted the code from one place to another.
Signed-off-by: NJuan Quintela <quintela@redhat.com>
Acked-by: NGerd Hoffmann <kraxel@redhat.com>

This reduces the dependencies on trace.h.
Only one source file which needs hcd-ehci.h also needs trace.h.
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Update portsc register and raise irq in case a suspended
port is woken up, so remote wakeup works on our ehci ports.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

We'll need a pointer to the actual pci/sysbus device,
stick a pointer to it into the EHCIState struct.

https://bugzilla.redhat.com/show_bug.cgi?id=1005495Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

To be passed to qbus_create_inplace().

Use DEVICE() cast to avoid a direct parent field access.
Reviewed-by: NWenchao Xia <xiawenc@linux.vnet.ibm.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This is an autogenerated patch using scripts/switch-timer-api.

Switch the entire code base to using the new timer API.

Note this patch may introduce some line length issues.
Signed-off-by: NAlex Bligh <alex@alex.org.uk>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

The macro g_assert_not_reached is a better self documenting replacement
for assert(0) or assert(false).
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Reviewed-by: NAnthony Liguori <aliguori@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Replace PORTSC macros with variables which could then be
configured in ehci_xxxx_class_init(...)
Signed-off-by: NKuo-Jung Su <dantesu@faraday-tech.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This makes the mem MemoryRegion available to derived instance_inits.

Keep the bus in realize for now since naming breaks in instance_init.
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The SysBus qdev initfn merely calls SysBusDeviceClass::init, so we can
replace it with a realizefn already. This avoids getting into any initfn
ambiguity with the upcoming Faraday EHCI implementation.

Rename internal usb_ehci_initfn() to usb_ehci_realize() to allow to
return Errors from common initialization code as well.
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The DMAContext is a simple pointer to an AddressSpace that is now always
already available.  Make everyone hold the address space directly,
and clean up the DMA API to use the AddressSpace directly.
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

With pipelining it is possible to encounter a finished packet when cleaning
the queue due to a halt. This happens when a non stall error happens while
talking to a real device. In this case the queue on the usb-host side will
continue processing packets, and we can have completed packets waiting in
the queue after an error condition packet causing a halt.

There are 2 reasons to discard the completed packets at this point, rather
then trying to writing them back to the guest:

1) The guest expect to be able to cancel and/or change packets after the
packet with the error without doing an unlink, so writing them back may
confuse the guest.

2) Since the queue does not advance when halted, the writing back of these
packets will fail anyways since p->qtdaddr != q->qtdaddr, so the
ehci_verify_qtd call in ehci_writeback_async_complete_packet will fail.

Note that 2) means that then only functional change this patch introduces
is the printing of a warning when this scenario happens.

Note that discarding these packets means that the guest driver and the device
will get out of sync! This is unfortunate, but should not be a problem since
with a non stall error (iow an io-error) the 2 are out of sync already anyways.
Still this patch adds a warning to signal this happening.

Note that sofar this has only been seen with a DVB-T receiver, which gives
of a MPEG-2 stream, which allows for recovering from lost packets, see:
https://bugzilla.redhat.com/show_bug.cgi?id=890320Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This patch adds support for usb3 streams to the usb subsystem core.
This is just adding a streams field / parameter in a number of places.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Coverity worries the EHCIQueue pointer could be null when we pass it
to functions that reference it.  The state machine ensures it can't be
null then.  Assert that, to hush the checker.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Some usb devices (host or network redirection) can benefit from knowing when
the guest stops using an endpoint. Redirection may involve submitting packets
independently from the guest (in combination with a fifo buffer between the
redirection code and the guest), to ensure that buffers of the real usb device
are timely emptied. This is done for example for isoc traffic and for interrupt
input endpoints. But when the (re)submission of packets is done by the device
code, then how does it know when to stop this?

For isoc endpoints this is handled by detecting a set interface (change alt
setting) command, which works well for isoc endpoints. But for interrupt
endpoints currently the redirection code never stops receiving data from
the device, which is less then ideal.

However the controller emulation is aware when a guest looses interest, as
then the qh for the endpoint gets unlinked (ehci, ohci, uhci) or the endpoint
is explicitly stopped (xhci). This patch adds a new ep_stopped USBDevice
method and modifies the hcd code to call this on queue unlink / ep stop.

This makes it possible for the redirection code to properly stop receiving
interrupt input (*) data when the guest no longer has interest in it.

*) And in the future also buffered bulk input.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

ehci_raise_irq(s, USBSTS_PCD), gets applied immediately so there is no need
to call commit_irq after it.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Before this patch, the following could happen:
1) Transfer completes, raises interrupt
2) .5 ms later we check if the guest has queued up any new transfers
3) We find and execute a new transfer
4) .2 ms later the new transfer completes
5) We re-run our frame_timer to write back the completion, but less then
   1 ms has passed since our last run, so frindex is not changed, so the
   interrupt threshold code delays the interrupt
6) 1 ms from the re-run our frame-timer runs again and finally delivers
   the interrupt

This leads to unnecessary large delays of interrupts, this code fixes this
by changing frindex to uframe precision and using that for interrupt threshold
control, making the interrupt fire at step 5 for guest which have low interrupt
threshold settings (like Linux).

Note that the guest still sees the frindex move in steps of 8 for migration
compatibility.

This boosts Linux read speed of a simple cheap USB thumb drive by 6 %.

Changes in v2:
-Make the guest see frindex move in steps of 8 by modifying ehci_opreg_read,
 rather then using a shadow variable
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

ehci_fill_queue assumes that there is a one on one relationship between an ep
and 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
the guest might do while working on other stuff. The only way this check can
trigger is if a guest mixes in and out qtd-s in a single qh for a non
control ep.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Remove the short-circuiting of fetchqtd in fetchqh, so that the
qtd gets properly verified before completing the transaction.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

No other changes.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This is not allowed, except for clearing active on cancellation, so don't
warn when the new token does not have its active bit set.

This unifies the cancellation path for modified qtd-s, and prepares
ehci_verify_qtd to be used ad an extra check inside
ehci_writeback_async_complete_packet().
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Also drop the warning printf, which was there mainly because this was an
untested code path (as the previous bug fixes to it show), but that no
longer is the case now :)
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Lower the timer freq if no iso schedule packets complete for 64 frames in
a row.

We can safely do this, without adding latency, because:
1) If there is isoc traffic this will never trigger
2) For async handled interrupt packets (only usb-host), the completion handler
   will immediately schedule the frame_timer from a bh
3) All devices using NAK to signal no data for interrupt endpoints now use
   wakeup, which will immediately schedule the frame_timer from a bh

The advantage of this is that when we only have interrupt packets in the
periodic schedule, async_stepdown can do its work and significantly lower
the frequency at which the frame_timer runs.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Starting with commit 1c380f94 dma
transfers can actually fail.  This patch makes ehci keep track
of the busmaster bit in pci config space, by setting/clearing the
dma_context pointer.  Attempts to dma without context will result
in raising HSE (Host System Error) interrupt and stopping the host
controller.

This patch fixes WinXP not booting with a usb stick attached to ehci.
Root cause is seabios activating ehci so you can boot from the stick,
and WinXP clearing the busmaster bit before resetting the host
controller, leading to ehci actually trying dma while it is disabled.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

While testing the move to async packet handling for interrupt endpoints I
noticed that Windows-XP likes to play tricks with the next pointer for
periodic qh-s, so we should not fail qh / qtd verification when it changes.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Windows links interrupt qtd-s in circles, which means that when interrupt
endpoints return USB_RET_ASYNC, combined with the recent
"ehci: Retry to fill the queue while waiting for td completion" patch,
we keep adding the tds to the queue over and over again, as we detect the
circle from fill_queue, but we call it over and over again ...

This patch fixes this by changing the circle detection to also detect
circling into tds already queued up previously.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>