wireguard-openbsd/sys/dev/usb/dwc2, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sys/dev/usb/dwc2?h=jd%2Fqueueboosts2020-04-03T20:11:47ZMove the responsibility of syncing the data buffers from the USB2020-04-03T20:11:47Zpatrickpatrick@openbsd.org2020-04-03T20:11:47Zurn:sha1:5343ff5a5a41d5607b3d4d0d97daef3e39985e88
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@
Instead of passing the flags as part of a struct that's supposed to be2020-03-21T12:08:31Zpatrickpatrick@openbsd.org2020-03-21T12:08:31Zurn:sha1:c28d999fb593957e511be1c7c486eed1cb0f077b
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. Since2020-03-19T14:18:38Zpatrickpatrick@openbsd.org2020-03-19T14:18:38Zurn:sha1:59570397f2e04b30da50053b0a2c74a27dcf8a5a
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@
Convert infinite sleeps to tsleep_nsec(9).2019-11-27T11:16:59Zmpimpi@openbsd.org2019-11-27T11:16:59Zurn:sha1:a2ef69b7ee99d76987da372682a33ac0eae2f47e
ok bluhm@
Use non-blocking allocation in dwc2_allocx() to make2019-03-14T04:28:10Zvisavisa@openbsd.org2019-03-14T04:28:10Zurn:sha1:cafbef77ae3998aaae205254d1dbb9676bdcfecf
the routine safe to use in soft interrupt context.
This fixes an assertwaitok() panic reported by
Abel Abraham Camarillo Ojeda.
OK mpi@
Add missing bus powered bit, from aalm@2019-03-11T17:50:08Zmpimpi@openbsd.org2019-03-11T17:50:08Zurn:sha1:3a3b7daefe5e3754ccdc36c3408cb1017c71d643If you use sys/param.h, you don't need sys/types.h2017-09-08T05:36:51Zderaadtderaadt@openbsd.org2017-09-08T05:36:51Zurn:sha1:b27348b2082c02cb5227e0e4933400ad6739ec5aEPROTO is now in sys/errno.h2017-09-05T14:01:03Zottootto@openbsd.org2017-09-05T14:01:03Zurn:sha1:9c5ea3c1375ebe1fcc2291577681db0eb9d60f06kill RCSID macros; discussed with millert2017-06-29T17:36:16Zderaadtderaadt@openbsd.org2017-06-29T17:36:16Zurn:sha1:6b1c761624a3c231abac6489bc4decd8452d1ba8Check the validity of the `qtd' pointer after each interrupt case2017-06-20T15:49:00Zvisavisa@openbsd.org2017-06-20T15:49:00Zurn:sha1:bd38a9bdcd5e888bff7de4d3a7713580f6a52c14
and bail out if the pointer has become invalid. This prevents
use-after-free memory accesses that corrupted the dwc2qtd pool.
This fix improves stability on the Raspberry Pi 3.
From Linux commit dc8730846948e517169f630826cd2c97615f5ee8
OK kettenis@