From: mpi <mpi@openbsd.org>
Date: Wed, 20 Jul 2016 09:48:06 +0000 (+0000)
Subject: ATI controllers seem to need the same workaround as VIA controllers.
X-Git-Url: http://artulab.com/gitweb/?a=commitdiff_plain;h=098f599fea90d91f1242a90d13aa702e52929a62;p=openbsd

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 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