> > 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 was thinking it's the second case, as you can tell ... :)
> > 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...).
I can see why multi-buffering might be useful to handle scheduling overruns
in controlled-bandwidth i/o (periodic transfers otherwise require real-time
scheduling) but that reasoning doesn't apply to bulk or control transfers.
ISO in fact has three mechanisms (!) for handling multiple transfers
per call to usb_submit_urb(), which seems like at least two extra.
One is the iso_frame_desc[] array, and two use multiple URBs
and "urb->next" ... in ring and list modes. (Not all HCDs handle
that "list" mode though.)
Now, I'm not even quite sure why there's even one such mechanism;
it would be just as easy to call usb_submit_urb() once per URB. It
looks as if several models got tried while the code evolved towards
its first stable point; and remnants of older models lingered on in some
of the HCDs, then got written up in the spec. I suspect there's more
to it than that, but that's how I read the result.
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
