svn commit: r227541 - head/sys/dev/usb/controller

[Hans Petter Selasky]

On Tuesday 15 November 2011 21:54:28 mdf at freebsd.org wrote:
> On Tue, Nov 15, 2011 at 12:48 PM, Hans Petter Selasky
> 
> <hselasky at freebsd.org> wrote:
> > Author: hselasky
> > Date: Tue Nov 15 20:48:57 2011
> > New Revision: 227541
> > URL: http://svn.freebsd.org/changeset/base/227541
> > 
> > Log:
> >  Some brands of XHCI controllers needs more time to reset.
> 

Hi,

> ... and since there's no guarantee that hz is 1000 or has any
> particular value, most of these seem a bit spurious.

The delays are a bit loosely defined, hence I think there is no clear 
definition what the minimum and maximum delay time is in the XHCI spec. The 
delay given just defines the minimum. It is not critical if the delay is 
larger, just that there is some kind of timeout.

I use pause() because that doesn't block if the modules are loaded after boot.

usb_pause_mtx() has an "if (cold)" check inside.

> 
> Is there some reason these functions aren't asking for a delay in
> terms of milli- or microseconds, and converting to hz internally?  I
> would expect a delay while waiting for hardware to have a wall-clock
> time, not a time relative to hz, which has no predefined range.

I have some macros that convert from hz to ms internally in the USB stack, 
though I see your point that if hz is low, then the specified value derivates 
from the real delay time.

For USB compliant operation, the USB stack requires hz to be greater or equal 
to 250 hz, to put it like that. Mostly a requirement in USB gadget/device 
mode.

--HPS