diff options
author | Martin Pieuchot <mpi@cvs.openbsd.org> | 2016-07-20 09:48:08 +0000 |
---|---|---|
committer | Martin Pieuchot <mpi@cvs.openbsd.org> | 2016-07-20 09:48:08 +0000 |
commit | 1fd8ececb413a7b81e87d04c76b9ae66399445f3 (patch) | |
tree | 580d09a588f7a81af19e71a1a20dca6cbe86d6a3 | |
parent | ae03de5b42a499a45ff116b87ba7e8b9e7144bab (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.c | 10 | ||||
-rw-r--r-- | sys/dev/usb/ehci.c | 12 |
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 |