On Mon, May 21, 2001 at 03:02:09PM -0700, David Brownell wrote:
> > > Near as I can tell, that bit of text has never been correct ...
> > > Clearly it's wrong today, and has been so for the last year!
> >
> > Never been correct? Do you mean by design? Or by implementation?
>
> Yes! :)
>
> Clearly by implementation, "facts on the ground".
Well, if I read the code of process_urb() in usb-uhci correctly ;-), it does
what the spec says (and a bit more, what's not in the spec...):
After one URB is finished (but before the completion) it tries to submit as
much URBs reachable by next. If there's an error in the submission, it stops
pointer chasing. The "error" automatically supports the linking of bulk URBs
without the QUEUE_BULK-flag: One URB is correctly submitted, the second one
should return with -ENXIO, thus the loop is aborted. What's not explicitely
stated in the spec is, that there has to be some detection for a ring (and
to cope with only one URB, it has to be submitted after the completion...)
and a maximal next-chasing-count. For usb-uhci, I set this arbitrarily to
2048 (should be enough...).
> To my way of thought, by design/architecture as well; and that text
> was just a bug. (One can argue "design bug" or otherwise.) Maybe
> some of the folk who advocated URBs in the first place will disagree.
usb-uhci does what the spec says, or the spec does it like usb-uhci, you can
choose ;-)
> I'll suggest that 2.5 might be a fine time to figure out what changes ought
> to be made in the URB scheduling framework. I want to see things be
> simplified and streamlined ... and see better arguments for these "submit
> more than one URB at a time" behaviors and their scheduling models.
> Any arguments in favor of those models were ones I missed at the time.
It would be a good place to clear things up, when we "invented" of the
next-linking, we thought that it would be a good feature, which makes
seamless streaming easier. Opnions may differ... That it also applies to
bulk is an accident by generalisation (why doing it only for ISO
transfers...).
--
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
