On Tue, 19 Feb 2013, Stefan Tauner wrote: > Well, I am not entirely sure if even I want this in (as is) yet, > because it is just a part of a complete solution for my problem and I > can't imagine a reason why user space would want to know this odd > value as is. > So I can not give a committable rationale yet, but I can sum up what > I am trying to do eventually: I try to map SOF counters to > CLOCK_REALTIME timestamps in user space. Later I want to use that to > establish a global time base on microcontrollers connected via USB > without the hassle of running NTP or PTP over USB. In user space I am > waiting for changes in the frame_counter sysfs file by reading it and > comparing its contents to values previously read in a busy loop, which > is of course not very elegant but it works - apart from the fact that > the returned values are not the raw values (and as Alan noted, > might also be off a bit)... :) > > 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. In the future, all scheduling of periodic transfers will be done by the host controller driver; the upper-layer drivers won't have any choice in the matter. Hence they shouldn't care about the current frame number. (Note that drivers can still determine in which frames individual isochronous packets were sent. That information is available from urb->start_frame.) > 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 This was probably the result of some early design decisions which have not turned out well. > 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. > If not, I would really like to see the documentation of > usb_get_current_frame_number() be changed to make it more clear that it > is not the raw SOF value and *why*. I have not figured out what > *exactly* it is yet/how the iso scheduling works... grasping the kernel > - even a subsystem - is quite an effort :) If/when I do I will send a > documentation patch. It's going to get more complicated -- in one sense, that is: more complicated for the controller driver, but less complicated for everybody else. As far as I'm concerned, the usb_get_current_frame_number() API can be removed (unless somebody suggests a good use for it). > 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. Alan Stern -- 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
