Date: Mon, 18 Jun 2007 09:05:04 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-usb@freebsd.org Subject: Re: HPS USB stack API change Message-ID: <200706180905.04587.hselasky@c2i.net> In-Reply-To: <20070614.175531.71089195.imp@bsdimp.com> References: <200706141156.18290.hselasky@c2i.net> <20070614231645.GC96936@elvis.mu.org> <20070614.175531.71089195.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 15 June 2007 01:55, Warner Losh wrote: > From: Alfred Perlstein <alfred@freebsd.org> > Subject: Re: HPS USB stack API change > Date: Thu, 14 Jun 2007 16:16:45 -0700 > > > * Hans Petter Selasky <hselasky@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 > > code. > > 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... > Ok, I implemented this by extending the functionality of "bInterval". By setting "xfer->interval" before a transfer, you can introduce a pre-delay. This is very useful for infinite polling loops and USB power saving for BULK-IN. See: http://perforce.freebsd.org/chv.cgi?CH=121894 --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200706180905.04587.hselasky>