On Mon, 18 Feb 2013 22:10:45 -0500 (EST) Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 19 Feb 2013, Stefan Tauner wrote: > > > Therefore I am currently playing around with a > > usb_hcd_get_real_frame_number() which uses a ehci_get_real_frame() > > function hacked into ehci-hcd.c which returns the actual SOF counter > > without the artificial horizon limit, but this is of course not > > committable. I wonder though why the limitation is there in the first > > place. Most users of usb_get_current_frame_number() seem rather unhappy > > with the limitation (e.g. drivers/media/usb/uvc/uvc_video.c) or don't > > care because they cap the returned value to the (locally defined(!)) > > minimum of the schedule horizon (0xFF everywhere AFAICS). Only very few > > use it directly to determine a possible scheduling (e.g. > > drivers/isdn/hisax/st5481_d.c which looks rather dubious to my naive > > eyes BTW). > > I wasn't aware that anyone was trying to use this API. In my opinion > doing so is probably a mistake. Most of what I have seen is for debugging prints only, but not all. No idea if that is of any use under the discussed circumstances (of inaccuracies). > > So from the user's perspective I don't see a reason why the artificially > > limited reply should be returned instead of the complete value. I have > > not checked if the raw value is available on all HCDs, but I assume it > > is. Wouldn't it make sense to change usb_hcd_get_frame_number() to > > return the raw value and add another one that returns the actual limit > > of the schedule horizon e.g. periodic_size in the case of EHCI(?) for > > those users that want to scheduler packets? > > Users should never want to schedule packets. Fair enough, I just mentioned it because I don't want to break any existing users. > > If you think refactoring get_frame_number should be done I would be > > glad to work on it. A few pointers to what the result should look like > > and any obvious pitfalls would be appreciated in that case. > > 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? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
