On Tue, 9 Sep 2003, David Brownell wrote: > How about a different radical approach. Remembering that there's > already a queue of URBs in the HCD glue, it's clear that they don't > all need to have TDs immediately allocated ... when an endpoint queue > is "empty enough", the lower level HCD code could check for urbs > that are queued to that endpoint but which don't yet have TDs, then > allocate (and queue) TDs for those URBs. > > That notion could be combined with the notion of TD queues that > are throttled in the same way many network drivers throttle. For > example, maybe a bulk endpoint would have no more than 40 TDs > at a given moment ... that's enough to keep the controller busy > for about two frames. Whenever a set of TDs completes from the > front of the td list, they could be recycled to advance transfers > starting from end of that td list. (Implies recycling TDs as > the HC returns them, instead of when the HCD returns urbs.)
This would mesh well with the idea (kicking around for a long time, apparently, but not implemented) of tracking the intermediate states as the controller finishes off some of the TDs for an URB. Alan Stern ------------------------------------------------------- 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
