Georg Acher wrote:
>
> On Wed, May 23, 2001 at 09:19:07AM +0200, Roman Weissgaerber wrote:
>
> > But then there will be a gap again. At the time the CPU
> > looks at the ->next pointer that next URB should be
> > already queued.
> >
> > !!!URB QUEUEING IS NOT AN OPTION IT SHOULD BE THE NORMAL CASE!!!!
>
> It's easy to say that if the hardware already does the job ;-)
The hardware does the job only if the software supports it the right way
8)
>
> But I think that there are actually different applications for real queuing
> and using the next-stuff:
That's what I am trying to say and in my opinion the next-stuff is not
really compatible with the queueing.
>
> 1) Transfering data as fast as possible, with no turnaround time -> queuing
> 2) Automatic streaming without any user code (mainly ISO) -> next-pointer
> 3) Execution of a pre-determined sequence ("program") of unspecified and
> possibly mixed URB-types without user intervention -> next-pointer
>
> Item 1) has the main problem in the error handling (and the correct
> implementation for the dump UHCI).
>
There are two possible error handling strageties:
- Queue approach: if a queue (endpoint) gets an error we stop (and
flush) the queue
e.g. the URB with an error returns the error code and the queue stops
(may be halts).
something like unlink_urb() should unlink all the rest of the URBs
- single URB approach: the URB returns the error but the other URBs just
keep on.
Note that stalls should work right with both approaches.
> The next-pointer was intended to be used by 2), to give the user a mechanism
> for an easy isochronous transfer, start it and it runs (just like
> interrupts). That goal can be reached much simpler (resubmit flag), but in
> the end, the next-pointer is a bit more flexible
>
Here we have the same problem as we have with queued URBs and the
next-stuff.
You just made a workaround that works somehow :-(
> For 3), the current functionality is not smart enough, since it would submit
> a bulk and a following control transfer at the same time, thus the resulting
> sequence may not be the intended one. So we would need the sequence handling
> of a finite state machine or some type of microprogram. This is definitely
> not the HCD's job...
>
But may be UHCI could queue URBs of different endpoints. OHCI can't do
this.
- Roman
> BTW: A universal microprogram interpreter for USB transaction processing
> would be a cool stuff ;-) Have to think about it...
>
> --
> Georg Acher, [EMAIL PROTECTED]
> http://www.in.tum.de/~acher/
> "Oh no, not again !" The bowl of petunias
>
> _______________________________________________
> [EMAIL PROTECTED]
> To unsubscribe, use the last form field at:
> http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
