Roman Weissgaerber writes:
> David Brownell wrote:
> > Maybe if USB_QUEUE_BULK is set on an urb, any
> > automagic urb->next handling on completion should be
> > bypassed ... unless usb_submit_urb() couldn't submit
> > that urb->next successfully.
> >
> 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!!!!
Yes, I think this is the key point. QUEUE_BULK submits both URBs to the
hardware there is no delay between them.
Using the ->next pointer requires an interrupt and a load of processing
within the HCD before the new URB is submitted. The only saving for using
->next instead of using a completion handler is one function call overhead.
When submitting small URBs (smaller than a frame) using ->next or using a
completion handler the second URB will probably end up in the next 1ms USB
frame anyway so is no faster.
What we really need, for performance, is some way to say "I want this URB to
be sent on the bus immediately after this other URB [but only if the
previous URB succeeded]". The URBs shouldn't need to be going to the same
endpoint or to be the same type. If the HCD can get the hardware to do this
(I think UHCI can - don't know about OHCI or others) without missing a frame
then it should do so, if not then it should do it off an interrupt.
QUEUE_BULK does this for bulk only, and only if they are the same type, with
undefined behaviour if there is an error.
[I would like this because I am writing a driver for some very weird
hardware which needs an IN access to succeed before the next OUT access can
be sent. Regardless of the speed of my OUT accesses I can't get more than
one OUT access every 2ms].
Andy
ps. To be honest I'm not sure what the point of ->next is, especially given
all the special case code which seems to be in the completion handler for
working out whether there is a ring buffer or not. Calling a completion
handler (which knows whether the URBs are arranged in a ring buffer) would
probably be faster than working it all out each time.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
