From owner-freebsd-usb@FreeBSD.ORG Thu Jun 14 23:56:59 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 C62C316A400; Thu, 14 Jun 2007 23:56:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8165C13C468; Thu, 14 Jun 2007 23:56:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l5ENtVXS000347; Thu, 14 Jun 2007 17:55:32 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 14 Jun 2007 17:55:31 -0600 (MDT) Message-Id: <20070614.175531.71089195.imp@bsdimp.com> To: alfred@freebsd.org From: Warner Losh In-Reply-To: <20070614231645.GC96936@elvis.mu.org> References: <200706141156.18290.hselasky@c2i.net> <20070614231645.GC96936@elvis.mu.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 14 Jun 2007 17:55:32 -0600 (MDT) 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: Thu, 14 Jun 2007 23:56:59 -0000 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... Warner