Sorry, I should have said packet. I have UHCI on the brain :)
I wonder why ... :)
So it does a maximum of one packet per endpoint per frame for low speed devices? Or does it only do one packet and then move on, but if there's still time left in the frame, there's the chance of doing another one?
Both OHCI and EHCI do the "one and move on, but coming back is fine". So if there's any uhci-hcd mode where the controller sits on any QH for many packets, until it NAKs or the frame ends, that'd be a difference in behavior. Doesn't matter what speed you're talking about; the fairness I was referring to is a "don't starve anyone" issue. Low-speed comes up because it's so easy to starve someone else that way, since they take up so much time.
Does it differentiate between high speed and low speed control?
Only EHCI would do high speed. The difference would be that low (and full) speed uses split transactions, which is pretty much transparent for control and bulk (even though both start-split and complete-split transactions are needed). Other than that, no speed-dependent difference that I recall. - Dave ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
