USB2 patches

[Hans Petter Selasky]

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