From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 14:11:14 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4908F16A4CE for ; Mon, 3 May 2004 14:11:14 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E37043D3F for ; Mon, 3 May 2004 14:11:13 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) i43LAwDv003745 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 3 May 2004 23:11:03 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id i43LA8Ui086955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 May 2004 23:10:09 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id i43LA7Ju045455; Mon, 3 May 2004 23:10:07 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id i43LA6r3045454; Mon, 3 May 2004 23:10:06 +0200 (CEST) (envelope-from ticso) Date: Mon, 3 May 2004 23:10:06 +0200 From: Bernd Walter To: Rita Lin Message-ID: <20040503211005.GJ38488@cicely12.cicely.de> References: <004c01c43053$2a775920$9402a8c0@emachine> <20040503120824.GG38488@cicely12.cicely.de> <008901c4314e$72b214e0$9402a8c0@emachine> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008901c4314e$72b214e0$9402a8c0@emachine> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.61 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on cicely5.cicely.de cc: freebsd-hackers@freebsd.org cc: ticso@cicely.de Subject: Re: USB device driver question: timeout() and usbd_do_request() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 21:11:14 -0000 On Mon, May 03, 2004 at 04:37:22PM -0400, Rita Lin wrote: > > But I don't understand the whole issue you have. > > Just schedule a request and wait for the device to ack. > > The Host controller does the polling for you as long as the request is > > queued and the timeout value supplied with the request did not time out. > > That has nothing to do with FreeBSD - it's how things work with USB in > > general. > I needed a "task" or a timer that periodicaly polls the modem status from > the USB device. > I think you meant the timeout value inside the usbd_do_request(). I needed > something that > periodically calls usbd_do_request(). Igh - that sounds like a very bad device design then. There would have been lots a ways to do in a clean way without additional pipes - such as transfering 0 sized packets to trigger a status inquiry or by adding status bytes in each packet. For what purpose do you need to poll the status in case for this device? > The mention of FreeBSD device polling was something I found on the Web. The > FreeBSD allows network driver to do polling instead of interrupt. The > implementation requires the first interrupt from the device in order to > register the callback for the polling. When I first saw the device polling > support in FreeBSD, I thought I could call usbd_do_request() in the callback > routine. I was wrong. Yes - that's for IO or memory accessable devices - basicly to avoid interrupt overhead I think. > Mike Silbersack suggested the use of kthread. I added it today, tested it > out, and it works. Thanks, Mike! > > By the way, for people who are writing USB drivers that uses ucom support, > you do not need to modify ucom.c to support multiple ports. By doing a trick > in declaring xxx_softc, I was able to create 4 ucom ports with one single > physical device. Yes that's possible as long a you have separate pipes for each channel. But if you have separate pipes for each channel then the device could use separate USB interfaces as well so you can attach seprate instances of your driver as well without doing special handling. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de