On Mon, May 21, 2001, Matthew Dharm <[EMAIL PROTECTED]> wrote:
> On Mon, May 21, 2001 at 04:52:58PM -0400, Johannes Erdfelt wrote:
> > On Mon, May 21, 2001, David Brownell <[EMAIL PROTECTED]> wrote:
> > > >    That is, I want to move several URBs for one
> > > > endpoint, and _when_they_are_done_, I want to move an URB for another
> > > > endpoint.  And, it doesn't matter how the beginning URBs end, I still want
> > > > to move the last one.
> > > 
> > > So far as I know, the only way to make that happen is to have the
> > > completion function(s) for that first endpoint trigger the behavior
> > > you want (by submitting urbs for the other endpoint).
> > 
> > This could be done with ->next. Or you can do it in the completion
> > handler.
> 
> Wait... different answer here.... can this be done with ->next?  People
> seem to have different opinions here.  Some say ->next is for ISO only.

That's incorrect. From Documentation/usb/URB.txt:

- URBs can be linked. After completing one URB, the next one can be
automatically submitted. This is especially useful for ISO transfers:
You only have read/write the data from/to the buffers in the completion 
handler, the continuous streaming itself is transparently done by the 
URB-machinery.

It specifically mentions ISO as a place where it useful, but it does not
limit it to specifically ISO.

> What I'd _hope_ for is this:  I construct a chain of arbitrary URBs in a
> linked list via the ->next pointer.  I send the chain to the API, and now I
> go to sleep while I wait for a completion message from the last URB.
> Meanwhile, the URBs are processed by executing the head of the queue, and
> (when that's finished), executing the next item on the queue.
> 
> Is that possible?  Yes, I can do this via submitting URBs from the
> completion function.  But, then I have to do a lot of management in the
> completion handler, which I don't want to do.  I'd like to set everything
> up ahead of time and let it run, so that the time between URBs is
> minimized.
> 
> Yes, I realize that I could try to prep the next URB while one is running,
> but then there are synchronization problems.  So, if I'm preping them all
> in advance anyway....

I dunno if that's possible. If one of the previous URB's fails, the
behvaiour is poorly defined.

Right now it submits along the chain merrily. I dunno if that's the
desired behaviour or not.

JE


_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to