On Tue, 19 Feb 2013, Stefan Tauner wrote: > > Using frame boundaries for time synchronization at the user level is > > possibly a defensible reason for exporting frame numbers. But there > > are better ways to accomplish this goal. For example, there could be > > an API that returns both a realtime value and a microframe number as of > > the next time a completion interrupt occurs. > > Adding a completely new API that returns a timestamp associated with > the start/end/fixed offset of a frame number sounds like a perfect > solution for my problem. I am not sure what you mean with completion > (interrupt). AFAICS that term is used mainly/only in relation to > (signaling) completed URBs. How does that fit together? What can I do > to make it happen?
Yes, completion interrupts are used for signalling when an URB completes. That's most of the signalling the CPU gets from a host controller; other things like port connect and disconnect are comparatively rare. The way they fit together is that completion IRQs are raised at microframe boundaries. Hence, if the interrupt handler stores a realtime clock value together with the new microframe number, there's no need for polling. The drawback, of course, is that there won't _be_ any completion interrupts until an active URB completes. Presumably that won't be a problem for you, but it is a weakness for a general-purpose API. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
