summaryrefslogtreecommitdiffstats
path: root/sys/dev/usb/xhcivar.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Do proper accounting of zero length TDs. Currently a specific numbermglocker2020-12-241-1/+2
| | | | | | | | | | | | of zero length TDs can cause our free TRBs to run out, causing xhci(4) to return USBD_NOMEM to the USB stack. The issue was reported by Jonathon Fletcher <jonathon.fletcher () gmail ! com> -- Thanks! Reviewed/suggestions by patrick@. ok mpi@
* Use MSEC_TO_NSEC() to define XHCI_CMD_TIMEOUT & use it w/ tsleep_nsec(9).mpi2019-10-061-2/+2
| | | | ok visa@, kn@
* Serialize synchronous commands with a rwlock.mpi2018-09-051-1/+2
| | | | | | | Prevent triggering an assert if two drivers try to submit a command at the same time. Issue reported by Tom Murphy.
* Print xHCI revision in dmesg.mpi2018-05-081-1/+2
| | | | ok patrick@, kettenis@
* Do not trust the content of event TRBs coming from the hardware andmpi2015-01-181-1/+4
| | | | maintain a list of possibly submitted commands.
* Since we are no longer resetting rings when a Babble or Stall conditionmpi2015-01-181-2/+2
| | | | | | | | | is detected, simply keep track of the faulty xfer instead of completing all the pending ones. Fix a race condition where we could end up aborting a freshly enqueued xfer when two different threads are submitting control transfers (i.e. usbdevs(8) and a kernel driver).
* Stop using usb_{alloc,free}mem() for the rings and internal structures.mpi2014-12-151-15/+21
| | | | | | | | | | | | Since xhci(4) does not allocate memory for its rings in interrupt context, it has no use for the free lists offered by the USB memory allocator. Using bus_dmamem_alloc(9) and friends also allows us to respect the boundary requirement for the various structures specified in Table 54. While here make use of defines for every alignment and boundary requirements which are different than a page size.
* Do not enable interrupts before attaching usb(4), fix a panic when anmpi2014-10-301-1/+2
| | | | | | | Express Card is plugged with USB devices on it. While here do not print an unitialized error value if xhci_init() fails, from Patrick Wildt.
* Get rid of the per-softc freelist of transfer descriptors and use ampi2014-04-291-3/+1
| | | | | | per-driver pool(9) instead. With inputs from mikeb@
* Instead of matching root hubs with a custom address, that only worksmpi2014-03-251-2/+1
| | | | | | | because USB_START_ADDR is defined to 0 and the softc is M_ZERO'd, assume that root hubs are the only devices with a depth of 0. Root hubs can now happily be detached and reattached.
* Upon resume do a full reset of the HC, including the command and eventmpi2014-03-251-3/+2
| | | | | | | rings, and rewrite all the addresses in the registers. While here don't keep a copy of our usb(4) child device, autoconf(9) knows how to reach our children.
* Dumb xhci(4) implementation.mpi2014-03-081-0/+142
This driver does not handle isochronous endpoint (yet) and has no logical TD representation. Each transfer is linked to the raw TRB of its related endpoint. Most of the transfer error completion codes are not handled, even with all the cheese provided by miod@ I couldn't find a proper way to reset an endpoint asynchronously when a device babbles. Or maybe it was the wine? Anyway this will come soon. In general the endpoint configuration and reset code is really crude and requires some love, but our stack should be fixed to properly open only once the default pipe of every new USB device first. This means this driver wont work as it is, our stack needs other changes first. Suspend/resume works but ports are not suspended for the moment. But even with these problems, interrupt devices: ukbd(4), ums(4) and sensors like ugold(4) work properly and USB 3.0 umass(4) devices give me a reasonnable read/write speed. Timeouts to cancel USB transfers are not enabled *on purpose*, to be able to track down potential timing issues. I'm committing now so that others can help fixing my bugs (8 All this work has been done on an ExpressCard with a NEC xHCI 0.96, other implementations/versions might trigger more bugs :)