Dave: The situation with regard to start_frame is a mess. Although the name and the documentation refer to frame numbers, for high speed devices the value stored there is a microframe number instead.
Clearly anyone who's interested in the value will want to know the full microframe number. But on the other hand, the value returned from ehci_get_frame() actually _is_ a frame number, so there's no way for drivers to learn the current microframe. Thus we have several related problems: How to tell whether you're dealing with frames or microframes and when to use each. Any suggestions on how to solve them? Also, it seems to me that drivers ought to be able to take the current (micro)frame value, add a small amount to it, and specify the result as the start frame for an URB. But such behavior is not documented as always workable, and we don't have any firm standard for how big the "small amount" can be. My feeling is that all HCDs should guarantee that anything up to 1 second will be acceptable. What do you think? Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
