Sarah Sharp wrote:
Are there any drivers in the kernel that set urb->start_frame on every URB?
Could those drivers handle it if only the first URB they submitted to the host controller was scheduled for that frame ID, and all the rest of the URBs were scheduled ASAP?
I see there are three drivers that set start_frame (while not setting URB_ISO_ASAP):
- drivers/isdn/hisax/st5481_d.c
- drivers/usb/core/devio.c
- sound/usb/usx2y/usbusx2yaudio.c
I'm not really sure what usbusx2yaudio.c is doing. I think when one URB completes, it sets the next URB's start_frame to the previous URB's start_frame plus the number of URBs (2 by default) times the number of packets (4 by default). Isn't this basically like setting URB_ISO_ASAP?
For an audio driver, anything except ASAP (or the equivalent computation) would not make sense because then there would be a gap in the audio output.
What is usbusx2yaudio.c attempting to do? I've tried to get an overall picture of what it expects the isochronous scheduling to look like, but I'm finding the driver a bit hard to read.
AFAIK it just wants a continuous stream of packets, like the other audio drivers.
I really can't tell what fall back method is if this submission fails.
So I guess xHCI does not support start_frame? A few other, seldom-used HC drivers get away with silently ignoring start_frame:
ohci-hcd.c: /* yes, only URB_ISO_ASAP is supported, and * urb->start_frame is never used as input. */ ehci-sched.c: /* NOTE: assumes URB_ISO_ASAP, to limit complexity/bugs */
Regards, Clemens