summaryrefslogtreecommitdiffstats
path: root/sys/dev/usb/xhcireg.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Add more flags to the debug bitmaskguenther2019-05-101-2/+3
| | | | ok mpi@
* HCCPARAMS1 register CFC and SEC values are 1 bit.mglocker2019-02-141-3/+3
| | | | ok mpi@
* Correct IST macro and add a new macro for setting Frame IDs.mpi2018-04-281-2/+4
|
* Introduce an helper function to extract endpoint's max burst value.mpi2018-04-271-4/+5
| | | | | | | | | Use this helper to calculate the Transfer Burst Count (TBC) and Transfer Last Burst Packet Count (TLBPC) required for isochronous support. Note that SS companion descriptors are still not read. While here print the ETE and IST values in debug mode.
* Add support for isochronous transfers to xhci(4).stsp2017-09-081-2/+7
| | | | | | | | | This is just a step forward which allows further progress to happen in-tree. The isochronous code path remains disabled for now. Playing audio over xhci(4) does not work properly yet, and I haven't even tested video input. Based on a work-in-progress diff by mpi@ from 2015. ok mpi@
* Do not trust the content of event TRBs coming from the hardware andmpi2015-01-181-4/+1
| | | | maintain a list of possibly submitted commands.
* Complete synchronous abort method modeled after the existing ones.mpi2015-01-181-2/+2
| | | | | | | | | | Because our USB stack wants the aborted xfer to be removed from the pipe during abort(), we have to sleep in the abort function. Regarding the xHCI process, when a TD is being aborted, we simply stop the endpoint and then move the dequeue pointer past its last TRB. This is fairly simple for the moment since only one xfer can be pending on a given pipe.
* When chaining TRBs, calculate the TD Size as described in sectionmpi2015-01-021-1/+2
| | | | | | | | | | 4.11.2.4 instead of using one TRB per packet. Also make sure that it is not greater than 31. While here be paranoid about xfer buffer crossing a 64k boundary and use a supplementary TRB in such case. Fix a problem with uplcom(4) on Intel xHCI reported by jasper@.
* Use a bitmask when dumping TRB flags. No change in !XHCI_DEBUG.mpi2014-12-211-1/+4
|
* Stop using usb_{alloc,free}mem() for the rings and internal structures.mpi2014-12-151-2/+15
| | | | | | | | | | | | 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.
* When resetting an endpoint do not purge the ring. Instead set thempi2014-12-081-2/+1
| | | | | dequeue pointer past the last enqueued TRB and let xhci_xfer_done() properly accounts free TRBs.
* Support USB 1.x devices below external hubs.mpi2014-11-101-5/+3
| | | | | This code is violating various layers of abstraction, just like ehci(4) does. Transaction translators need a bit more love.
* Do not mark the pipe as halted when the HC reports a (split) transactionmpi2014-10-051-2/+2
| | | | | error. Makes Intel Series 7 controllers happy and no longer report an illegal context state transition when detaching devices.
* Improve the logic to determine the maximum endpoint service interfacempi2014-08-081-15/+8
| | | | | time payload. Super speed companion descriptor are still not used but at least we can properly initialize super speed interrupt pipes.
* To enable Intel XHCI host controller, re-route all of usb port to xhciyuo2014-07-121-2/+5
| | | | | | instead of connected to ehci. ok mpi@
* Dumb xhci(4) implementation.mpi2014-03-081-0/+439
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 :)