David Brownell wrote:
>
> > Now with queued URBs:
> >
> > - Submit a chain (URB_1, URB_2) immediately to the HCD
> > /* I think we still need to submit both URBs seperately? */
>
> Certainly each "submit" can report errors immediately ... which
> is why I don't quite know what it should mean to submit the
> had of a list of bulk URBs linked by urb->next where all have
> USB_QUEUE_BULK set.
>
> If urb1 submits OK, and submitting urb2 gets an error, what
> then? Tough to report the error immediately since urb1 may
> have done its work already.
>
> > - than the HC handles the transfer (URB_1)
> > - than the HC handles the next transfer (queued URB_2)
> > \ at the same time HCD looks at the ->next pointer of URB_1
> > (it points to URB_2) but URB_2 is still queued so what now?????
>
> 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!!!!
- Roman
> - Dave
>
> _______________________________________________
> [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
