On Tue, 10 Oct 2006, Christopher "Monty" Montgomery wrote: > > What happens if, when you're done filling, the clock is exactly at the > > slot? Unless you wait for the clock to move past the slot, you can't know > > whether or not the slot will end up being processed. But you can't wait > > during a submit, so what do you do? > > That... is a good point. I submit the following: > > You accept it, the clock is not past. Assume for the time being it > scheduled in time. If it didn't, that's reported at the next > submission (still semantically correct: the XRUN is still happening > then). > > Reporting -EXDEV in the completion handler gets you nothing because > that URB isn't going to complete; it missed its slot.
That is another good point. If the HCD can't guarantee the last slot in an URB will be scheduled in time, then it has to return an error during submission because completion might be delayed for a very long time. But I still dislike the idea of reporting a problem in the _next_ submission. For all you know, the next submission might be made before the HCD can tell there was a problem. > Hm, interestingly though, neither case works if that was the last URB > to be submitted before stream shutdown. You'll get neither a next > submission nor a completion. Another good reason for reporting the problem at submission time. > There's not real precedent in either direction as it appears the > higher level drivers expect neither channel as yet. Either way will > involve work. The real problem involves cases that are too close to call accurately. Suppose an URB is submitted and its last slot goes in the (u)frame following the currently active one. Should the HCD refuse it? That would add an extra (u)frame of delay into the processing loop. But what if the HCD accepts it, adds it to the schedule, and then sees that the clock has advanced so that the slot is now active? Then there's no way to tell whether or not the hardware will process it until the (u)frame is over. And if the hardware did not process it then there won't be a completion interrupt. The only safe approach is to refuse the URB and live with the added delay. Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
