From owner-freebsd-usb@FreeBSD.ORG Sun Feb 1 20:37:42 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 239A4106566C; Sun, 1 Feb 2009 20:37:42 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.swipnet.se [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id 58A1D8FC29; Sun, 1 Feb 2009 20:37:41 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=rmrU8kTBWN7SvPJ5QBgA:9 a=zTEVK1LEtGmBGfXtk00erOG5m9gA:4 a=50e4U0PicR4A:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe10.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1020179517; Sun, 01 Feb 2009 21:37:39 +0100 From: Hans Petter Selasky To: "M. Warner Losh" Date: Sun, 1 Feb 2009 21:40:01 +0100 User-Agent: KMail/1.9.7 References: <200902012001.06914.hselasky@c2i.net> <200902012031.56899.hselasky@c2i.net> <20090201.130051.-2130550806.imp@bsdimp.com> In-Reply-To: <20090201.130051.-2130550806.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902012140.04180.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org, thompsa@freebsd.org Subject: Re: USB2 patches 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: Sun, 01 Feb 2009 20:37:43 -0000 Hi Warner, > : Hi Andrew, > : > : I've looked in the taskqueue code: > : > : if (task->ta_pending) { > : task->ta_pending++; > : TQ_UNLOCK(queue); > : return 0; > : } > : > : Take the following for example. Now you changed it a little bit, but I > : see similar issues where other commands are involved: > : > : 1) queue DTR on cmd > : 2) queue DTR off cmd > : 3) queue DTR on cmd > > This is a bad example. The example is not the best. Let's pick another example: Assume you have a 3g modem and we are doing software flow control. Regularly modem status bits are transferred between host and device. Now, lets assume that the modem application has only got one thread. What will happen if transferring the RTS/CTS status bits to the modem is synchronous? Immediate data-loss! Especially at higher data rates. Let me elaborate: Assume it takes 3ms to handle a control request to program the DTR/RTS/CTS, because the device is slow. Then you have a 1024 byte buffer on a BULK endpoint which needs to be handled every 1ms. If DTR/RTS and CTS are not done async, you severely degrade the overall performance of the system, don't you agree about that, if every time you update the modem status have to wait 3ms, having to skip Rx'ed data? > In this case, clearly you'd want to turn it > on, wait for it to go on, wait a while, turn it off, wait for it to go > off, wait a while, then repeat the on part. If you are trying to get > a notch signal in DTR, you have to cope this way. According to your approach we will end up not knowing what state is programmed! It all depends on the sampling point of the softc's value, if I can express it like that. I think it is important to preserve the initial signal. If there was a level, we need to produce a level. It tells the peer something. > If you are > implementing an ioctl from userland to do this (as exposed by the tty > system), then you'd need to wait for the DTR command to finish anyway > before returning to userland, no? The MPSAFETTY API doesn't allow sleeping from what I know. All signalling via MPSAFETTY is made asynchronous. > > There's likely other reasons for wanting to do this, but DTR changes > should be synchronous to the caller. Yes and no. If the TTY device is setup for non-blocking operation, then setting the DTR should return as quick as possible. If the TTY/Modem device is setup for blocking operation, then the IOCTL should return once the DTR [for example] has been set ??? --HPS