On Thu, 22 Oct 2009, Sarah Sharp wrote: > > > So, as long as you only use urb->start_frame for the starting *frame*, > > > the xHCI driver should be able to accommodate device drivers. > > > > But urb->start_frame is implemented as meaning the starting > > _microframe_ for high-speed devices. > > Then why is it called start_frame and not start_microframe or > start_uframe? Grumble. Grumble indeed. The answer, of course, is "historical reasons". The field was created before microframes existed. We have the same problem with urb->interval; for LS/FS devices the interval is in frames whereas for HS/SS devices it is in uframes. > > However, given the hit-or-miss way in which existing HCDs implement it > > (i.e., basically not at all), I guess there's nothing wrong with > > pre-allocating the schedule and then choosing the actual starting > > uframe to be the slot closest to the uframe given by urb->start_frame. > > Did you mean "choosing the actual starting frame"? No, I meant "uframe". But the analogous idea for frames would apply to LS/FS devices. > Or are you planning > on scheduling inactive endpoints with microframe granularity for every > HCD other than xHCI? Well... Inactive endpoints don't matter so much. But _active_ endpoints clearly do have to be scheduled with uframe granularity for high-speed or super-speed devices, which in practice means in xHCI and the EHCI family. (Obviously this issue is moot for USB-1.1 controllers.) And I don't see any reason to complicate matters by doing a partial, frame-granular allocation while an endpoint is inactive, which would then have to be refined to uframe granularity when the endpoint gets used. We might as well do a complete allocation from the beginning. 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
