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