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. 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. 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
