On Sun, Oct 13, 2002, Stephan Feder <[EMAIL PROTECTED]> wrote: > Johannes Erdfelt wrote: > > > > On Sun, Oct 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > > > > > > >>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. > > > > > > Does UHCI notice that while there's no time left for a lowspeed > > > transfer, there may be time for a high speed one ... and try > > > the high speed transfer? > > > > That's a good question. I don't recall seeing anything that describes > > that the UHCI will do that. > > UHCI will simply initiate the low speed transfer, it does not check > whether it fits into the frame or not (The transfer will eventually stop > at the end of frame). And as it does not skip the low speed transfer it > cannot even see any pending high speed transfer. That is how I > understand the "spec", i.e. the UHCI design guide (or do you have access > to a more definite UHCI spec?), especially section 1.3:
Nope, that's the only spec I know of. > <quote> > UHCI only allows for bandwidth reclamation of full speed control and > bulk transfers. The software must schedule low speed control transfers > such that they are guaranteed to complete within the current frame. > </quote> Reading it again, I think you're right. It's pretty clear that it only uses the preSOF for full speed transfers. It's confusing in that it says it only does that for FSBR, which would imply that it doesn't work in the non FSBR case. I don't quite believe that since the HC doesn't differentiate between FSBR and non FSBR. It's just a loop in the schedule. Anyway, to be correct, it looks like we need to ensure that we don't schedule too many low speed control transfers at once, perhaps by queuing them until previous ones finish. 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
