1. 31 Aug, 2012 7 commits
    • Hans de Goede's avatar
      ehci: simplify ehci_state_executing · 574ef171
      Hans de Goede authored
      ehci_state_executing does not need to check for p->usb_status == USB_RET_ASYNC
      or USB_RET_PROCERR, since ehci_execute_complete already does a similar check
      and will trigger an assert if either value is encountered.
      
      USB_RET_ASYNC should never be the packet status when execute_complete runs
      for obvious reasons, and USB_RET_PROCERR is only used by ehci_state_execute /
      ehci_execute not by ehci_state_executing / ehci_execute_complete.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      574ef171
    • Hans de Goede's avatar
      ehci: Remove unnecessary ehci_flush_qh call · 53dd6f70
      Hans de Goede authored
      ehci_qh_do_overlay() already calls ehci_flush_qh() before it returns, calling
      it twice is useless.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      53dd6f70
    • Hans de Goede's avatar
      ehci: Schedule async-bh when IAAD bit gets set · a1c3e4b8
      Hans de Goede authored
      After the "ehci: Print a warning when a queue unexpectedly contains packets
      on cancel" commit. Under certain reproducable conditions I was getting the
      following message: "EHCI: Warning queue not empty on queue reset".
      
      After aprox. 8 hours of debugging I've finally found the cause. The Linux EHCI
      driver has an IAAD watchdog, to work around certain EHCI hardware sometimes
      not acknowledging the doorbell at all. This watchdog has a timeout of 10 ms,
      which is less then the time between 2 runs through the async schedule when
      async_stepdown is at its highest value.
      
      Thus the watchdog can trigger, after which Linux clears the IAAD bit and
      re-uses the QH. IOW we were not properly detecting the unlink of the qh, due
      to us missing (ignoring for more then 10 ms) the IAAD command, which triggered
      the warning.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      a1c3e4b8
    • Hans de Goede's avatar
    • Gerd Hoffmann's avatar
      usb: unique packet ids · e983395d
      Gerd Hoffmann authored
      This patch adds IDs to usb packets.  Those IDs are (a) supposed to be
      unique for the lifecycle of a packet (from packet setup until the packet
      is either completed or canceled) and (b) stable across migration.
      
      uhci, ohci, ehci and xhci use the guest physical address of the transfer
      descriptor for this.
      
      musb needs a different approach because there is no transfer descriptor.
      But musb also doesn't support pipelining, so we have never more than one
      packet per endpoint in flight.  So we go create an ID based on endpoint
      and device address.
      Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      e983395d
    • Hans de Goede's avatar
      usb: Halt ep queue en cancel pending packets on a packet error · 0132b4b6
      Hans de Goede authored
      For controllers which queue up more then 1 packet at a time, we must halt the
      ep queue, and inside the controller code cancel all pending packets on an
      error.
      
      There are multiple reasons for this:
      1) Guests expect the controllers to halt ep queues on error, so that they
      get the opportunity to cancel transfers which the scheduled after the failing
      one, before processing continues
      
      2) Not cancelling queued up packets after a failed transfer also messes up
      the controller state machine, in the case of EHCI causing the following
      assert to trigger: "assert(p->qtdaddr == q->qtdaddr)" at hcd-ehci.c:2075
      
      3) For bulk endpoints with pipelining enabled (redirection to a real USB
      device), we must cancel all the transfers after this a failed one so that:
      a) If they've completed already, they are not processed further causing more
         stalls to be reported, originating from the same failed transfer
      b) If still in flight, they are cancelled before the guest does
         a clear stall, otherwise the guest and device can loose sync!
      
      Note this patch only touches the ehci and uhci controller changes, since AFAIK
      no other controllers actually queue up multiple transfer. If I'm wrong on this
      other controllers need to be updated too!
      
      Also note that this patch was heavily tested with the ehci code, where I had
      a reproducer for a device causing a transfer to fail. The uhci code is not
      tested with actually failing transfers and could do with a thorough review!
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      0132b4b6
    • Gerd Hoffmann's avatar
      fix info qtree indention · da9fbe76
      Gerd Hoffmann authored
      Without the patch bus properties are are not in line with the other
      properties:
      
      [ ... ]
        dev: fw_cfg, id ""
          ctl_iobase = 0x510
          data_iobase = 0x511
            irq 0
            mmio ffffffffffffffff/0000000000000002
            mmio ffffffffffffffff/0000000000000001
      [ ... ]
      
      With the patch applied everything is lined up properly:
      
      [ ... ]
        dev: fw_cfg, id ""
          ctl_iobase = 0x510
          data_iobase = 0x511
          irq 0
          mmio ffffffffffffffff/0000000000000002
          mmio ffffffffffffffff/0000000000000001
      [ ... ]
      
      Needed to make the autotest qtree parser happy.
      Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      da9fbe76
  2. 30 Aug, 2012 2 commits
  3. 29 Aug, 2012 12 commits
  4. 28 Aug, 2012 8 commits
  5. 27 Aug, 2012 11 commits