From owner-freebsd-usb@FreeBSD.ORG Mon Jun 18 07:05:08 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D6B6616A421; Mon, 18 Jun 2007 07:05:08 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 33DC913C448; Mon, 18 Jun 2007 07:05:08 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe01.swip.net (CommuniGate Pro SMTP 5.1.9) with ESMTPA id 502610099; Mon, 18 Jun 2007 09:05:06 +0200 From: Hans Petter Selasky To: Warner Losh Date: Mon, 18 Jun 2007 09:05:04 +0200 User-Agent: KMail/1.9.5 References: <200706141156.18290.hselasky@c2i.net> <20070614231645.GC96936@elvis.mu.org> <20070614.175531.71089195.imp@bsdimp.com> In-Reply-To: <20070614.175531.71089195.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200706180905.04587.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: HPS USB stack API change X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2007 07:05:08 -0000 On Friday 15 June 2007 01:55, Warner Losh wrote: > From: Alfred Perlstein > Subject: Re: HPS USB stack API change > Date: Thu, 14 Jun 2007 16:16:45 -0700 > > > * Hans Petter Selasky [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