On Tuesday, September 15, 2015 10:49 PM, Arnd Bergmann wrote: > On Tuesday 15 September 2015 10:40:24 Alan Stern wrote: >> On Tue, 15 Sep 2015, Arnd Bergmann wrote: >> >>>>> Do you know the specific requirement on the USB frame numbers? I don't know >>>>> enough about USB to tell if either of those matter. >>>> >>>> Using jiffies_to_msecs() here is a nice way. According to USB 2.0 Spec, however, the frame time is 1ms >>>> in full / low-speed, and 125us in high-speed. >> >> That's not quite right. A frame is always 1 ms, no matter what the >> speed. In high-speed and SuperSpeed, each 125-us period is called a >> micro-frame. >> >>>> Actually, most of HCD implement this in hardware, the >>>> driver just read a register and return its value. It's hard to cover all platform here if we only use kernel >>>> time wheel. >>> >>> ktime_get() should have a high enough resolution to cover the high-speed mode, >>> but that would also mean changing the driver more fundamentally. >>> >>> The dummy driver does support emulating both superspeed and highspeed USB, >>> so that may indeed be the right solution. At this point, we probably need >>> Felipe, Alan and the linux-usb list to make a decision, so I've added >>> them to Cc. >>> >>> My impression from your comment is that the driver should check the >>> dummy_hcd_module_parameters variable for the device speed in order to >>> pick the right time base for the frame number, and then calculate it >>> using ktime_divns(ktime_get()) with an appropriate factor. >> >> The right place to get the speed would be hcd->speed (in >> dummy_h_get_frame) and _gadget->speed (in dummy_g_get_frame). The >> module parameters affect what speeds are allowed but they don't fully >> determine the actual speed. However this is moot, since the API always >> returns the frame number, not the micro-frame number. > > Ok, thanks for the clarification! > >> I agree that the monotonic clock would be better than the real-time >> clock. >> >> On the other hand, this probably doesn't matter much. Frame numbers >> generally aren't useful for anything other than isochronous transfers, >> and dummy-hcd doesn't support isochronous. > > Ok. I'd suggest that Pingbo uses ktime_get_ts64() for the next version > then, and add an explanation why it is likely irrelevant. By now, the > main advantage I see in using monotonic time is that it might save > someone from having to look at this file when searching for possible > leap second issues, but that's still better than nothing. > I will fix it in next version. Pingbo -- 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
