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.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
