Re: Use of start_frame in usbusx2yaudio.c

[Clemens Ladisch <clemens@ladisch.de>]

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