Date: Sun, 1 Feb 2009 21:40:01 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-usb@freebsd.org, thompsa@freebsd.org Subject: Re: USB2 patches Message-ID: <200902012140.04180.hselasky@c2i.net> In-Reply-To: <20090201.130051.-2130550806.imp@bsdimp.com> References: <200902012001.06914.hselasky@c2i.net> <200902012031.56899.hselasky@c2i.net> <20090201.130051.-2130550806.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200902012140.04180.hselasky>