On Tuesday 15 September 2015 20:10:10 Pingbo Wen wrote: > On Tuesday, September 15, 2015 02:38 PM, Arnd Bergmann wrote: > > On Tuesday 15 September 2015 09:48:10 Pingbo Wen wrote: > >>>> - does the driver use monotonic or real time > >>>> Real time. But only microsecond part is used. > >>>> > >>>> - if it uses real time, should it use monotonic time instead > >>>> Monotonic time will be ok if it can meet the precise requirement(us). > >>> Your patch picks the easy approach by leaving the driver to use real > >>> time. This clearly has a lower risk of regressions, which is good, but > >>> you should come up with an argument on which of the two is the better > >>> choice here. > >>> > >> Yes, I just follow the old way to avoid additional risks. If using monotonic time here, > >> maybe we can replace the whole function as: > >> > >> return jiffies % HZ; > >> > >> But we need some tricks here to make sure the return value is correct, > >> if HZ macro is greater than 1000 in some platform. > > On most architectures, HZ is between 100 and 1000, I believe Alpha is the > > only exception that goes as high as 1200. However, there is also a > > jiffies_to_msecs() function that might do the exact right thing and > > is normally very efficient. > > > > The main downsides are that it loses precision on architectures with HZ=100, > > and that it will jump once every 41 days on architectures with HZ=1000 when > > jiffies overflows, as ULONG_MAX is not a multiple of 1000. > > > > 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. 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. Arnd -- 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
