On Mon, 9 Oct 2006, Christopher "Monty" Montgomery wrote: > On 10/9/06, Alan Stern <[EMAIL PROTECTED]> wrote: > > So you're saying if the current uframe is N when you receive an URB whose > > first slot belongs in uframe N+1, then you have to reject it, right? > > No, that we try to fill the slot and if the clock is at/past the slot > when we're done filling, look to see if the slot was processed. If it > wasn't, unlink it and return loss of sync.
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? > > What about other host controllers? A full-speed controller uses 1-ms > > frames. Are you willing to live with up to 2 ms of pessimism? > > Before I answer that, would the first way I suggested work? We go > through all the careful atomic linking/unlinking for a reason, and > the point of the driver is to usefully encapsulate complexity--- this > would be a handy thing to encapsulate. There is more than one way to encapsulate this, and I don't particularly like the way you're suggesting. The reason I don't like it is because it won't always work -- as you can see from the example given just above. 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
