> > > Because it's faster to just send the CLEAR_HALT than to actually stop and
> > > look at the status -- other driver vendors have realized this, resulting in
> > > some odd-looking but totally legal bus transactions which run very quickly.
> >
> > I can't buy this. The instructions requesting I/O cost more than the ones
> > testing status, and then there's cost for the I/O cost itself.
>
> But not when you have to have an interrupt before you can check status and thus
> miss at least 1 usb frame.
Based on the previous context, I was assuming that interrupt already.
It had already been established that today's host controller drivers won't
guarantee the type of scheduling you've just assumed. (On Linux, that is.)
> I am not familiar with the specifics of the *hci's, so I don't know if this is even
>possible.
Well, the UHCI drivers won't queue control urbs, and while OHCI
can do that I don't see any guarantees (from any *hci driver) for how
sequencing is done on control and bulk requests. Periodic urbs
(interrupt, iso) are the only ones offering any guarantees.
That is, if urb1 is submitted just before urb2, the only way I'm sure
to know urb1 will complete before urb2 is to know that they're
queued to the same bulk endpoint (and device and bus). That means
that if ordering matters, you have only two options: bulk queueing, or
not submitting urb2 until urb1 completes. You're assuming there's
some third option. Not today; probably not soon, if ever.
(The urb->next queuing, above the HCD queue level, can provide
such sequencing guarantees, but only if it's leveraging bulk queuing
is it going to be able to avoid needing interrupts to trigger progress
to the next urb in the sequence.)
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
