HPS USB stack API change
imp at bsdimp.com
Thu Jun 14 23:56:59 UTC 2007
From: Alfred Perlstein <alfred at freebsd.org>
Subject: Re: HPS USB stack API change
Date: Thu, 14 Jun 2007 16:16:45 -0700
> * Hans Petter Selasky <hselasky at c2i.net> [070614 02:56] wrote:
> > Hi all!
> > I'm planning to add another argument to "usbd_start_hardware()", which is a
> > delay value that gives the delay in microseconds or maybe milliseconds before
> > the transfer is actually queued. This can be used to reduce the polling rate
> > on BULK-IN transfers among other things, to reduce the overall power usage,
> > and to safely create infinite polling loops without fearing BUS overusage in
> > case of failure conditions.
> > For example:
> > usbd_start_hardware(xfer, 200000); //200 ms delay
> > A delay value of zero indicates no delay.
> Sounds like a good idea.
> > I plan to implement this re-using the timeout callout.
> > Any comments ?
> Can't comment as I'm not that familiar with the existing underlying
I think so too. I was wondering if there's really a benefit from
having a timeout + queue mechanism for most devices. For more
isochronous things, that need to play out data at a constant rate to
the device, it would certainly be convenient to be able to schedule
more than one buffer at a time, especially if the granularity of the
callback could be improved beyond 1/HZ. I don't know enough about the
host controllers to know if there would be the ability to schedule
transfers that far in advance or not...
So it seems like it would be useful. Not sure it would solve the
problem you present, but even so...
More information about the freebsd-usb