Revert ehci(4) bits in the previous commit. Apparently 64-bit DMA is broken
in (almost?) all ehci(4) controllers.

Relax DMA restrictions on ehci(4) and xhci(4) controllers that can do
64-bit DMA.

ok mpi@, mlarkin@

remove unneeded includes; ok mpi@

constify USB host controller method tables and root hub descriptors

ok mglocker@

spelling
feedback and ok tb@ jmc@ ok ratchov@

M_USB -> M_USBHC

Align memory allocation for USB device drivers and USB HC drivers:

* USB device drivers use M_USBDEV instead of M_DEVBUF.
* USB HC drivers use M_USBHC instead of M_DEVBUF.

In a vanilla setup, this

Align memory allocation for USB device drivers and USB HC drivers:

* USB device drivers use M_USBDEV instead of M_DEVBUF.
* USB HC drivers use M_USBHC instead of M_DEVBUF.

In a vanilla setup, this enlarges the USB memory pool.

ok anton@

show more ...

Improve unhibernate performance (30% on some machines, another upcoming diff
shows gains up to 50%) by skipping attach of irrelevant devices, which are
tagged CD_SKIPHIBERNATE in the per-driver cfdri

Improve unhibernate performance (30% on some machines, another upcoming diff
shows gains up to 50%) by skipping attach of irrelevant devices, which are
tagged CD_SKIPHIBERNATE in the per-driver cfdriver. In particular, usb devices
are not attached, so they don't need to detach during the suspend-unpack-resume.
New bootblocks are required (which tell the kernel it's job is unhibernate
before configure runs)
tested by various

show more ...

When an endpoint stalls, we usually try to reset it by calling
usbd_clear_endpoint_stall(), which in turn will call
usbd_clear_endpoint_toggle(). It can be a common situation that when
this happens,

When an endpoint stalls, we usually try to reset it by calling
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@

show more ...

Unleash curlen check from DIAGNOSTIC block, and change the related printf's
to DPRINTF's.

From Mikolaj Kucharski <mikolaj AT kucharski DOT name>

Don't panic on curlen == 0. This DIAGNOSTIC code should have been removed
already in revision 1.57 IMO.

From Mikolaj Kucharski <mikolaj AT kucharski DOT name>

Remove duplicate comment.

ok mpi@

Move the responsibility of syncing the data buffers from the USB
stack into the USB controller driver, since not all of the xfers
actually use DMA and some invalidations might even be harmful.

The i

Move the responsibility of syncing the data buffers from the USB
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@

show more ...

No point in checking the loop variable for NULL inside a LIST_FOREACH.

CID 980279

Instead of passing the flags as part of a struct that's supposed to be
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. Since
the import in '99 all buffers allocated using usb_allocmem() have
been mapped COHERENT. On some ARM SoCs, where the USB controller
i

Switch USB to use non-coherent buffers for data transfers. Since
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@

show more ...

use the UE_GET_XFERTYPE macro where applicable

ok mpi@

Convert tsleep(9) to tsleep_nsec(9).

ok visa@, kn@, cheloha@

Fix comment typo: 'trasnfer' -> 'transfer'.

Add missing bus powered bit, from aalm@

Change transfer schedule of split interrupt transfer,
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 periodic
(interrupt) transfer.

When RL is not zero, interrupt transfer cannot work correctly.
It causes USB2.0 hub cannot detect device at

RL (NAK count reload) field in QH should be zero when using periodic
(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@

show more ...

Replace remaining SPLUSBCHECK by a splsoftassert(IPL_SOFTUSB).

USB is the last real user of IPL_SOFTNET.

A pile of sizes to free(9). In test for a few days in snapshots.
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 fixes
them, but for release let's be conservative and use 0.