Get rid of the per-softc freelist of transfer descriptors and use a
per-driver pool(9) instead.

With inputs from mikeb@

Use the `use_polling' hack to make sure usb_delay_ms() will not
call tsleep(9) on resume. deraadt@ pointed that this not needed
for powerdown since `cold' is set.

Another approach would be to call

Use the `use_polling' hack to make sure usb_delay_ms() will not
call tsleep(9) on resume. deraadt@ pointed that this not needed
for powerdown since `cold' is set.

Another approach would be to call delay() directly in the reset
functions, but let stay coherent with the other HC drivers.

show more ...

XHCI -> xHCI to be consistent with device names.

Do not declare a struct as const if we write to it, fix build on sparc64
reported by brad@.

If a command is submitted when the hardware is already gone, it will
obviously time out. That is what happen when pipes are closed after
unplugging an xhci(4) express card for example. In such case

If a command is submitted when the hardware is already gone, it will
obviously time out. That is what happen when pipes are closed after
unplugging an xhci(4) express card for example. In such case, make
sure the command TRB is reset.

show more ...

Instead of matching root hubs with a custom address, that only works
because USB_START_ADDR is defined to 0 and the softc is M_ZERO'd,
assume that root hubs are the only devices with a depth of 0.

R

Instead of matching root hubs with a custom address, that only works
because USB_START_ADDR is defined to 0 and the softc is M_ZERO'd,
assume that root hubs are the only devices with a depth of 0.

Root hubs can now happily be detached and reattached.

show more ...

Upon resume do a full reset of the HC, including the command and event
rings, and rewrite all the addresses in the registers.

While here don't keep a copy of our usb(4) child device, autoconf(9)
kno

Upon resume do a full reset of the HC, including the command and event
rings, and rewrite all the addresses in the registers.

While here don't keep a copy of our usb(4) child device, autoconf(9)
knows how to reach our children.

show more ...

Properly clear and free the endpoint associated to a pipe. Do not
forget to update the Endpoint Context with the last valid endpoint
and free the device resources, including its slot, when the defau

Properly clear and free the endpoint associated to a pipe. Do not
forget to update the Endpoint Context with the last valid endpoint
and free the device resources, including its slot, when the default
pipe is closed.

Device addresses can now be reused and I should be done with
descriptor leaks.

show more ...

If a device is babbling do a full reset of the associated endpoint
before telling the stack/driver that the responsible transfer is
done.

Since the request sequence requires, in the present form, to

If a device is babbling do a full reset of the associated endpoint
before telling the stack/driver that the responsible transfer is
done.

Since the request sequence requires, in the present form, to submit
two commands from the interrupt handler, modify the command routine
to be able to submit asynchronous commands.

I can now use my crappy urtwn(4) over xhci(4).

While here convert some #if -> #ifdef, pointed out by brad@.

show more ...

Dumb xhci(4) implementation.

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 th

Dumb xhci(4) implementation.

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 :)

show more ...