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.
I have a couple questions about driver behavior:
1. Do drivers ever submit their first URB in interrupt context?
2. Do drivers that use a different interval than the endpoint
advertises stick with the same interval when submitting new URBs?
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?
Sarah Sharp
--
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
