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. > Meaning that every URB has to be submitted as much as 250 us in advance. Or we could do it that way, yes. > 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. Monty ------------------------------------------------------------------------- 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
