ATI controllers seem to need the same workaround as VIA controllers.

This should hopefully help people reporting errors with SB700.

From FreeBSD, ok kettenis@, krw@

diff --git a/sys/dev/pci/ehci_pci.c b/sys/dev/pci/ehci_pci.c
index b42ff97..a0b9acf 100644 (file)
--- a/sys/dev/pci/ehci_pci.c
+++ b/sys/dev/pci/ehci_pci.c
@@ -1,4 +1,4 @@
-/*     $OpenBSD: ehci_pci.c,v 1.29 2015/11/09 10:01:17 mpi Exp $ */
+/*     $OpenBSD: ehci_pci.c,v 1.30 2016/07/20 09:48:06 mpi Exp $ */
 /*     $NetBSD: ehci_pci.c,v 1.15 2004/04/23 21:13:06 itojun Exp $     */
 
 /*
@@ -207,8 +207,14 @@ ehci_pci_attach(struct device *parent, struct device *self, void *aux)
                    "vendor 0x%04x", PCI_VENDOR(pa->pa_id));
 
        /* Enable workaround for dropped interrupts as required */
-       if (sc->sc.sc_id_vendor == PCI_VENDOR_VIATECH)
+       switch (sc->sc.sc_id_vendor) {
+       case PCI_VENDOR_ATI:
+       case PCI_VENDOR_VIATECH:
                sc->sc.sc_flags |= EHCIF_DROPPED_INTR_WORKAROUND;
+               break;
+       default:
+               break;
+       }
 
        ehci_pci_takecontroller(sc, 0);
        r = ehci_init(&sc->sc);

diff --git a/sys/dev/usb/ehci.c b/sys/dev/usb/ehci.c
index 3c83509..b15d873 100644 (file)
--- a/sys/dev/usb/ehci.c
+++ b/sys/dev/usb/ehci.c
@@ -1,4 +1,4 @@
-/*     $OpenBSD: ehci.c,v 1.190 2015/12/11 12:23:09 mpi Exp $ */
+/*     $OpenBSD: ehci.c,v 1.191 2016/07/20 09:48:07 mpi Exp $ */
 /*     $NetBSD: ehci.c,v 1.66 2004/06/30 03:11:56 mycroft Exp $        */
 
 /*
@@ -2825,11 +2825,11 @@ ehci_timeout_task(void *addr)
 }
 
 /*
- * Some EHCI chips from VIA seem to trigger interrupts before writing back the
- * qTD status, or miss signalling occasionally under heavy load.  If the host
- * machine is too fast, we we can miss transaction completion - when we scan
- * the active list the transaction still seems to be active.  This generally
- * exhibits itself as a umass stall that never recovers.
+ * Some EHCI chips from VIA / ATI seem to trigger interrupts before writing
+ * back the qTD status, or miss signalling occasionally under heavy load.
+ * If the host machine is too fast, we can miss transaction completion - when
+ * we scan the active list the transaction still seems to be active. This
+ * generally exhibits itself as a umass stall that never recovers.
  *
  * We work around this behaviour by setting up this callback after any softintr
  * that completes with transactions still pending, giving us another chance to