Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 3 May 2004 23:10:06 +0200
From:      Bernd Walter <ticso@cicely12.cicely.de>
To:        Rita Lin <ritalin@comcast.net>
Cc:        ticso@cicely.de
Subject:   Re: USB device driver question: timeout() and usbd_do_request()
Message-ID:  <20040503211005.GJ38488@cicely12.cicely.de>
In-Reply-To: <008901c4314e$72b214e0$9402a8c0@emachine>
References:  <004c01c43053$2a775920$9402a8c0@emachine> <20040503120824.GG38488@cicely12.cicely.de> <008901c4314e$72b214e0$9402a8c0@emachine>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040503211005.GJ38488>