On Thu, 7 May 2009, Sarah Sharp wrote: > I'm working on adding interrupt transfer support to the xHCI host > controller driver, and I'm having a slight problem with device drivers > that submit an URB with a different interval than the endpoint > advertises. We don't really have a policy about that. As far as I know, no driver ever changes the interval from value in the endpoint descriptor. However usbcore does sometimes change the descriptor value (when the value in the descriptor is invalid). And usb_submit_urb changes the requested interval to a power of two (not an issue with SS). > I have a couple questions about driver behavior: > 1. Do drivers ever submit their first URB in interrupt context? Yes. Or at least, you should assume they are allowed to do so. > 2. Do drivers that use a different interval than the endpoint > advertises stick with the same interval when submitting new URBs? Yes. More accurately, if an interrupt endpoint queue is active then drivers are not allowed to change the interval. > I'm grepping my way through the device drivers, but I figured that > someone else might know off the top of their head. > > > The main problem with URB intervals that don't match the endpoint > interval is that xHCI doesn't have a frame list like EHCI. Instead, the > host controller uses the interval specified in the endpoint context (a > host controller data structure set up by the xHCI driver) to schedule > transfers. To change an interval for an endpoint, I have to issue a > command to the hardware and wait for it to complete. > > That has two consequences: > - the xHCI driver can't honor a different interval if the interrupt URB > is submitted in interrupt context, and has to fall back on the > interval in the last submitted URB. > - I can't change the interrupt interval for a newly submitted URB if > another URB is still on the hardware queue. That would be racey, and > the first URB may or may not be scheduled for the interval it asked > for. > > If drivers do submit their first interrupt URB in an interrupt context, > and they use a consistent interval, then I could make a USB core API to > set the interrupt interval for an endpoint and make those drivers call > it in their probe functions. Thoughts? I'm not aware of any drivers that would need this. In fact, AFAICS the urb->interval value could just as well be made output-only. Maybe it should be. 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
