summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMartin Pieuchot <mpi@cvs.openbsd.org>2016-07-20 09:48:08 +0000
committerMartin Pieuchot <mpi@cvs.openbsd.org>2016-07-20 09:48:08 +0000
commit1fd8ececb413a7b81e87d04c76b9ae66399445f3 (patch)
tree580d09a588f7a81af19e71a1a20dca6cbe86d6a3
parentae03de5b42a499a45ff116b87ba7e8b9e7144bab (diff)
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@
-rw-r--r--sys/dev/pci/ehci_pci.c10
-rw-r--r--sys/dev/usb/ehci.c12
2 files changed, 14 insertions, 8 deletions
diff --git a/sys/dev/pci/ehci_pci.c b/sys/dev/pci/ehci_pci.c
index b42ff972570..a0b9acfc48f 100644
--- 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 3c835095eaf..b15d873dd1e 100644
--- 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