summaryrefslogtreecommitdiffstats
path: root/sys/dev/usb/ehci.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* When an endpoint stalls, we usually try to reset it by callingmglocker2021-01-111-2/+2
| | | | | | | | | | | | usbd_clear_endpoint_stall(), which in turn will call usbd_clear_endpoint_toggle(). It can be a common situation that when this happens, there is still a transfer in the stalled queue being in progress. The ehci(4) clear toggle function is currently doing a panic() in the diagnostic code in this situation, which is a bit of an overkill. The device still can be recovered by detaching/attaching it. Therefore change the panic() in to a printf(). ok mpi@
* Unleash curlen check from DIAGNOSTIC block, and change the related printf'smglocker2020-11-271-7/+7
| | | | | | to DPRINTF's. From Mikolaj Kucharski <mikolaj AT kucharski DOT name>
* Don't panic on curlen == 0. This DIAGNOSTIC code should have been removedmglocker2020-10-231-5/+1
| | | | | | already in revision 1.57 IMO. From Mikolaj Kucharski <mikolaj AT kucharski DOT name>
* Remove duplicate comment.mglocker2020-08-061-5/+1
| | | | ok mpi@
* Move the responsibility of syncing the data buffers from the USBpatrick2020-04-031-7/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | stack into the USB controller driver, since not all of the xfers actually use DMA and some invalidations might even be harmful. The important part is to sync before handing the buffer to the controller, and to sync on a successful transfer before handing it back to the USB stack. For isoc transfers it's easier to sync the complete length of the transfer, since the buffer to flush is not filled in a contiguous fashion. For dwc2 there's a common point which takes care of the start of transfers from or to devices, where we can make sure that our buffers are synced. On completion, there's a common point before handing it off to the USB stack. For ehci there are three places which take care of the start of transfers from or to devices, where one already does the sync, while the two other places still need the sync. There are two completion handler (isoc and non-isoc), where one already has a comment asking for the need of a sync. The done handler for intr xfers does a sync that is not needed anymore after adding the sync in the completion handler. For ohci there are three places which take care of the start of transfers from or to devices, where all of them were still in need of the sync. For completion, there is one place for isoc xfers and two places for handling successful generic xfers. For uhci there are two places which take care of the start of transfers from or to device, where all of them were still in need of the sync. For completion, there is one handler for both isoc and non-isoc xfers where syncs need to occur. For xhci there are three places which take care of the start of transfers from or to device, where all of them were still in need of the sync. For completion, there is one handler for isoc and one for non-isoc xfers where syncs need to occur. With this we can revert the workaround that implicitly allocated buffers are COHERENT, since now control transfers fulfilled by the driver code (instead of the controller doing DMA) are not flushed into oblivion anymore. Tested by Janne Johansson with dwc2 (octeon) Tested by kettenis@ with xhci(4) (octeon) Tested by patrick@ with ehci(4) on a Cubox-i (armv7) Tested by patrick@ with xhci(4) on an i.MX8MQ (arm64) Tested by tobhe@ with dwc2 on a rPi 3b (arm64) ok kettenis@
* No point in checking the loop variable for NULL inside a LIST_FOREACH.krw2020-03-301-3/+1
| | | | CID 980279
* Instead of passing the flags as part of a struct that's supposed to bepatrick2020-03-211-11/+6
| | | | | | | filled by the callee, change the usb_allocmem() API to take another argument for the flags. ok mpi@
* Switch USB to use non-coherent buffers for data transfers. Sincepatrick2020-03-191-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the import in '99 all buffers allocated using usb_allocmem() have been mapped COHERENT. On some ARM SoCs, where the USB controller is not coherent with the caches, this means the buffers were mapped uncached. This drastically reduces the performance, especially on reads. We already added cache syncs before and after USB transfers, but so far those have essentially been no-ops. Since other drivers make use of the same allocation code, and those haven't been proven to have correct syncs, we can't just remove the COHERENT flag. This splits the allocation into coherent and non-coherent blocks. All drivers who call usb_allocmem() themselves now pass a flag to show they require coherent blocks. Onced verified that they also work fine without coherent, or once they have been refactored, we can remove this again. On a ure(4) connected to an i.MX8MQ, the receive performance is 10x as fast as before. The Raspberry Pi's ethernet receive speed doubled. Debugged using dt(4) Original diff from Marius Strobl Feedback from kettenis@ Tested on an i.MX8MQ (arm64) by patrick@ Tested on a Raspberry Pi (arm64) by tobhe@ Tested on an ERL (octeon) by Janne Johansson ok mpi@ gerhard@ tobhe@
* use the UE_GET_XFERTYPE macro where applicablejasper2020-02-221-3/+3
| | | | ok mpi@
* Convert tsleep(9) to tsleep_nsec(9).mpi2019-10-081-5/+6
| | | | ok visa@, kn@, cheloha@
* Fix comment typo: 'trasnfer' -> 'transfer'.mglocker2019-03-311-2/+2
|
* Add missing bus powered bit, from aalm@mpi2019-03-111-2/+2
|
* Change transfer schedule of split interrupt transfer,uaa2019-01-191-3/+18
| | | | | | to avoid confilicting with split isochronous transfer which use same TT. ok mpi@
* RL (NAK count reload) field in QH should be zero when using periodicuaa2019-01-081-2/+7
| | | | | | | | | (interrupt) transfer. When RL is not zero, interrupt transfer cannot work correctly. It causes USB2.0 hub cannot detect device attach/detach. ok by mpi@
* Replace remaining SPLUSBCHECK by a splsoftassert(IPL_SOFTUSB).mpi2017-05-151-3/+3
| | | | USB is the last real user of IPL_SOFTNET.
* A pile of sizes to free(9). In test for a few days in snapshots.deraadt2017-04-081-3/+5
| | | | | Errors will result in nice clean panic messages so we know what's wrong. Reviewed by dhill visa natano jsg.
* these free() size choices appear to be wrong. joel has a diff that fixesderaadt2017-03-301-3/+3
| | | | them, but for release let's be conservative and use 0.
* Fix a use-after-free when sending root hub control transfers.mpi2017-03-101-2/+2
| | | | | | | | | | | *_root_ctrl_start() routines are synchronous and all end up calling usb_transfer_complete() in the non-error case. After calling this function it is unsafe to dereference ``xfer'' since the transfer callback has been called. So returning USBD_IN_PROGRESS is wrong in this case since transfers are always completed at this point. So return USBD_NORMAL_COMPLETION or the corresponding error code if something wrong happen.
* Move per HC polling code to the stack.mpi2017-03-101-42/+1
| | | | | | | | | This code contains a use-after-free which be addressed in an upcoming diff. This fix xhci(4) polling mode. ok kettenis@
* Remove superfluous DMA synchronization now that the stack is doing it formpi2016-11-081-7/+1
| | | | | | all HCs. ok patrick@
* Save and restore the (non-standard) USBMODE register around a reset of thekettenis2016-10-021-2/+8
| | | | | | | | | | | | | controller. This register controls whether the controller is in device or host mode on many dual role controllers and gets reset during a reset of the controller, placing the controller in (non-functional) idle mode. By saving and restoring it, we keep the controller in host mode. Since this is a non-standard register, add a new EHCIF_USBMODE flag and only do the save and restore if it has been set. Makes the upper "OTG" port of the Cubox-i work. ok mpi@, jsg@
* all pools have their ipl set via pool_setipl, so fold it into pool_init.dlg2016-09-151-4/+3
| | | | | | | | | | | | | | | | | | | | | | the ioff argument to pool_init() is unused and has been for many years, so this replaces it with an ipl argument. because the ipl will be set on init we no longer need pool_setipl. most of these changes have been done with coccinelle using the spatch below. cocci sucks at formatting code though, so i fixed that by hand. the manpage and subr_pool.c bits i did myself. ok tedu@ jmatthew@ @ipl@ expression pp; expression ipl; expression s, a, o, f, m, p; @@ -pool_init(pp, s, a, o, f, m, p); -pool_setipl(pp, ipl); +pool_init(pp, s, a, ipl, f, m, p);
* add a missing splx in an error pathjsg2016-08-181-2/+4
| | | | ok millert@ stsp@
* ATI controllers seem to need the same workaround as VIA controllers.mpi2016-07-201-6/+6
| | | | | | This should hopefully help people reporting errors with SB700. From FreeBSD, ok kettenis@, krw@
* Work around Nvidia EHCI controllers bugs.mpi2015-12-111-6/+10
| | | | | | | | | | | Do not set the "Port Number", "Hub Address" and "Split Completion Mask" fields in Isochronous Queue Heads for high-speed devices. These fields should be ignored by the host controller unless the EPS field indicates a full- or low-speed device, but that's not the case with Nvidia controllers. From NetBSD via miod@
* Add missing header found while removing <sys/srp.h> from <sys/param.h>mpi2015-11-141-1/+2
|
* Delay root hub interrupt processing to the soft-interrupt path in ordermpi2015-11-021-6/+9
| | | | | | to mark ehci_intr() as IPL_MPSAFE. Earlier version tested by ratchov@, ok visa@
* Revert previous. uvideo checks the transfered length of every frame andmpi2015-06-261-1/+3
| | | | | | this break some devices. As found the hardway by Hugo Sastre via sobrado@
* Do not update frame lengths to reflect what has really been transferedmpi2015-06-221-3/+1
| | | | | | | | when an isochronous transfer is done. Frame lengths are just input values and no driver mess with them. ok ratchov@, jmatthew@
* Make sure LLVM static analyzer do not report a false positive,mpi2015-04-161-5/+3
| | | | found by and fix confirmed by jsg@.
* I did quite some changes to this driver, so add copyright.mpi2015-04-101-1/+16
|
* Full-speed isochronous transfers support with opportunistic micro-framesmpi2015-04-101-328/+386
| | | | | | | | | | | | scheduling. More work is required to properly budget and schedule micro-frames, most of it at the HUB level. But this let people use USB1.1 uaudio(4) devices on ehci(4)-only systems. Thanks to all the testers! ok ratchov@, sthen@, naddy@
* Expand ehci_{add,del}_intr_list() macros.mpi2015-03-251-17/+12
| | | | | | | | | | ehci(4) is using a TAILQ_* to keep track of the pending transfers. In this context "pending" means submitted to the hardware. Now that we are no longer fiddling with the internal of the TAILQ_* there's no good reason to keep these macro, but more importantly this will let us reuse the 'inext' field to get rid of the other hand-rolled lists of xfers. No functional change.
* Merge ehci_device_request() into ehci_device_ctrl_start() to matchmpi2015-03-251-52/+35
| | | | what's done with other transfer types. No functional change.
* Remove more DPRINTFs, this file is almost in a readable state now.mpi2015-03-251-53/+3
|
* Use KASSERT() to check when/if URQ_REQUEST is correctly set just likempi2015-03-251-31/+9
| | | | xhci(4) does.
* Remove EHCI_DEBUG chunks that make things harder to understand.mpi2015-03-251-159/+2
| | | | | | Over the years I understood that debugging USB HCD problems without hardware access do not work and even in this case it's easier to write a specific debug/prinf diff.
* Prevent a race resulting in an infinite loop printing "ehci_idone" messages.mpi2015-03-171-20/+28
| | | | | | | | As soon as a transfer is being cancelled, remove it from the list of pending xfers. This way the soft interrupt routine won't try to process it before ehci_abort() gives it back to the stack. Problem analysed by and previous diff ok stsp@
* Revert previous, the fix is not right and causes a regression asmpi2015-03-061-15/+17
| | | | | | reported by Remi Locherer on bugs@. ok deraadt@
* Prevent a race resulting in an infinite loop printing "ehci_idone" messages.mpi2015-02-281-17/+15
| | | | | | | | As soon as a transfer is being cancelled, remove it from the list of pending xfers. This way the soft interrupt routine won't try to process it before ehci_abort() gives it back to the stack. Problem analysed by and ok stsp@
* Whitespace.uebayasi2015-02-091-4/+4
|
* Use <sys/endian.h> instead of <machine/endian.h>guenther2014-12-191-2/+2
| | | | ok dlg@ mpi@ bcook@ millert@ miod@
* Avoid premature masking in the interrupt handler code that checks for removedkettenis2014-12-171-2/+3
| | | | | | hardware. ok mpi@, deraadt@
* More malloc() -> mallocarray() in the kernel.doug2014-12-091-3/+3
| | | | ok deraadt@ tedu@
* move arc4random prototype to systm.h. more appropriate for most codetedu2014-11-181-3/+1
| | | | to include that than rdnvar.h. ok deraadt dlg
* Do not re-establish the default pipe twice for every controller. Movempi2014-10-051-2/+37
| | | | | | this hack in the drivers that need it. Tested by many, thanks! ok pirofti@, kettenis@
* Revert previous, it puts too much pressure on memory allocation asmpi2014-09-011-208/+286
| | | | reported by Bryan Linton on bugs@.
* Rewrite how queue heads are inserted and removed from the asynchronousmpi2014-08-301-286/+208
| | | | | | | | list. Use a queue head per xfer and no longer per pipe. Since queue heads are now setup when a transfer is submited we do not need to open the control pipe more than once. This also simplify transfer abortion. Tested by many, thanks!
* Since USB xfer pools are accessed in interrupt context, initialize themmpi2014-08-101-1/+2
| | | | with the correct ipl to prevent your CPU from locking against itself.
* Set and check for XFER_BUSY in the common methods instead of doing itmpi2014-08-101-9/+2
| | | | in every HC driver.
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.