On Sun, Oct 13, 2002, Stephan Feder <[EMAIL PROTECTED]> wrote: > Johannes Erdfelt wrote: > > > > On Fri, Oct 11, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote: > > > On Fri, 11 Oct 2002, Johannes Erdfelt wrote: > > > >On Fri, Oct 11, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote: > ... > > > >> -changed lowspeed control TDs from depth to breadth. > > > > > > > >Why for? This will guarantee that it will take (# of TD's * 1 ms) time > > > >to complete. > > > > > > Well, mainly to make the code common...but also, making it depth opens the > > > possibility (for a large transfer) of hogging the bus, and, will most > > > lowspeed devices really be able to send more than 1 packet per frame? > > > > It's control, it's allowed to hog the bus. I don't see the difference > > between transferring x packets in one frame versus 1 packet in x frames. > > > > I know that there are low speed devices that can send multiple packets > > per frame. > > > > The only disadvantage I can see is if a device has to NAK. We could use > > that packet to do something more useful. I don't think it's a problem > > because the most common usage of low speed control is enumeration time. > > I'd rather not slow that down anymore than it needs to be. > > The HC does not control bandwidth reclamation for low speed transfers. I > am not sure what happens in case of frame overrun (device stall, or > would that not matter in case of control endpoints?).
Nothing that serious. The HC won't let a transfer spill over into the next frame. It'll just wait until the next frame and start the schedule over again. JE ------------------------------------------------------- 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
