requesting the initial complete device descriptor and not as part of
the subsequent babble error recovery. Babble means that the received
USB packet was bigger than than configured maximum packet size. This
only affects enumeration of FULL speed USB devices which use a
bMaxPacketSize different from 8 bytes. This patch might help fix
enumeration of USB devices which exhibit USB I/O errors in dmesg
during boot.
MFC after: 1 week
Use driver settable callbacks for handling of:
- core post reset
- reading actual port speed
Typically, OTG enabled EHCI cores wants setting of USBMODE register,
but this register is not defined in EHCI specification and different
cores can have it on different offset.
Also, for cores with TT extension, actual port speed must be determinable.
But again, EHCI specification not covers this so this patch provides
function for two most common variant of speed bits layout.
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D5088
Driver was modified to ensure it attaches properly to "marvell,orion-ehci"
node, which doesn't have error interrupt line defined. Neccessary
ofw_compat_data struct was added and probe procedure was altered.
Reviewed by: andrew, ian
Obtained from: Semihalf
Sponsored by: Stormshield
Submitted by: Bartosz Szczepanek <bsz@semihalf.com>
Differential revision: https://reviews.freebsd.org/D4369
available. As with MSI interrupts these can be disabled by setting
hw.usb.xhci.msix to 0 in the loader.
MSI-X interrupts are needed on some hardware, for example the Cavium
ThunderX only supports them, and with this we don't fall back to polling.
PR: 204378
Reviewed by: hselasky, jhb
MFC after: 1 week (after r292669)
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D4698
32-bits aligned. Merge the two bounce buffers into a single one. Some
rough tests showed that the DWC OTG throughput on RPI2 increased by
10% after this patch.
MFC after: 1 week
status registers for every interrupt. Check a common host channel
status interrupt register first, then conditionally read the
individual host channel status registers.
Submitted by: Sebastian Huber <sebastian.huber@embedded-brains.de>
MFC after: 1 week
There is an issue with interrupts at the moment, but it works with
polling mode set (hw.usb.xhci.use_polling=1).
Reviewed by: hselasky
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3665
intervals less than 250us was not handled properly. Add support for
high-bandwidth ISOCHRONOUS packets. USB webcams, USB audio and USB DVB
devices are expected to work better. High-bandwidth INTERRUPT
endpoints is not yet supported.
MFC after: 2 weeks
like RPI-B and RPI-2.
Description of problem:
USB transfers can process data in their callbacks sometimes causing
unacceptable latency for other USB transfers. Separate BULK completion
callbacks from CONTROL, INTERRUPT and ISOCHRONOUS callbacks, and give
BULK completion callbacks lesser execution priority than the
others. This way USB audio won't be interfered by heavy USB ethernet
usage for example.
Further serve USB transfer completion in a round robin fashion,
instead of only serving the most CPU hungry. This has been done by
adding a third flag to USB transfer queue structure which keeps track
of looping callbacks. The "command" callback function then decides
what to do when looping.
MFC after: 2 weeks
Remove NAKing limit and pause IN and OUT transactions for 125us in
case of NAK response for BULK and CONTROL endpoints. This gets the
receive latency down and improves USB network throughput at the cost
of some CPU usage.
MFC after: 1 month
xhci_start_controller() to xhci_init(). These values don't change at run-
time so there's no point of acquiring them on every USB_HW_POWER_RESUME
instead of only once during initialization. In r276717, reading the first
couple of registers in question already had been moved as a prerequisite
for the changes in that revision.
- Identify ASMedia ASM1042A controllers.
- Use NULL instead of 0 for pointers.
MFC after: 3 days
1) Use the TX FIFO empty interrupts to poll the transmit FIFO usage,
instead of using own software counters and waiting for SOF
interrupts. Assume that enough FIFO space is available to execute one
USB OUT transfer of any kind when the TX FIFO is empty.
2) Use the host channel halted event to asynchronously wait for host
channels to be disabled instead of waiting for SOF interrupts. This
results in less turnaround time for re-using host channels and at the
same time increases the performance.
The network transmit performance measured by "iperf" for the "RPi-B v1
2011/12" board, increased from 45MBit/s to 65Mbit/s after applying the
changes above.
No regressions seen using:
- High Speed (BULK, CONTROL, INTERRUPT)
- Full Speed (All transfer types)
- Low Speed (Control and Interrupt)
MFC after: 1 month
Submitted by: Daisuke Aoyama <aoyama@peach.ne.jp>
stage processing is only allowed after the setup complete event has
been received. Else a race may occur and the OUT data can be corrupted.
While at it ensure resetting a FIFO has the required wait loop.
MFC after: 3 days
'BUS_PROBE_DEFAULT'. This allows bhyve's 'ppt' driver to claim ownership
of the device and pass it through to the guest.
In the common case where there are no competing drivers for USB controllers
this change is a no-op.
Reviewed by: hselasky
MFC after: 2 weeks
been done by U-Boot. This allows the USB to work when we load the kernel
directly.
No dma sync is performed after these operations as the data we read/write
is not used by the cpu after the calls to the maimbox driver.
Differential Revision: https://reviews.freebsd.org/D1940
Reviewed by: imp, Michal Meloun (meloun AT miracle.cz)
MFC after: 1 Week
Sponsored by: ABT Systems Ltd
when re-enumerating a FULL speed device. Else the wrong max packet
setting might be used when trying to re-enumerate a FULL speed device.
MFC after: 3 days
interrupt status bit. According to the UHCI controller specification
the host controller halted interrupt is non-maskable.
PR: 156596
Tested by: adrian @
MFC after: 1 week
that we should use a normal-TRB if there are more TRBs extending the
data-stage TRB. Add a dedicated state bit to the internal USB transfer
flags to handle this case.
Reported by: Kohji Okuno <okuno.kohji@jp.panasonic.com>
MFC after: 1 week
every operation to retrieve the bs_cookie value almost nothing actually uses.
The bus_space struct contains a private data pointer (poorly named bs_cookie,
now renamed to bs_privdata) which is used only by a few old armv4 xscale
implementations. The bus_space functions were all defined to take this
value as the first parameter instead of the bus_space_tag_t, requiring all
the inline macro and function expansions to dereference the tag to pass it
to another function, which never uses it. Now all the functions take the tag
as the first parameter and retrieve the privdata if they need it.
Also fix a couple bus_space_unmap() implementations that were calling
kva_free() instead of pmap_unmapdev().
Discussed with: cognet
simultaneously detaching kernel drivers on the same USB device we can
get stuck in the "usb_wait_pending_ref_locked()" function because the
conditions needed for allowing detach are not met. The "destroy_dev()"
function waits for all system calls involving the given character
device to return. Character device system calls may lock the USB
enumeration lock, which is also held when "destroy_dev()" is
called. This can sometimes lead to a deadlock not noticed by
WITNESS. The current solution is to ensure the calling thread is the
only one holding the USB enumeration lock and prevent other threads
from getting refs while a USB device detach is ongoing. This turned
out not to be sufficient. To solve this deadlock we could use
"destroy_dev_sched()" to schedule the device destruction in the
background, but then we don't know when it is safe to free() the
private data of the character device. Instead a callback function is
executed by the USB explore process to kill off any leftover USB
character devices synchronously after the USB device explore code is
finished and the USB enumeration lock is no longer locked. This makes
porting easier and also ensures us that character devices must
eventually go away after a USB device detach.
While at it ensure that "flag_iserror" is only written when "priv_mtx"
is locked, which is protecting it.
MFC after: 5 days
