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. Pingbo _______________________________________________ Y2038 mailing list [email protected] https://lists.linaro.org/mailman/listinfo/y2038
