Use of start_frame in usbusx2yaudio.c

Use of start_frame in usbusx2yaudio.c

[Sarah Sharp]

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?
I really can't tell what fall back method is if this submission fails.

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.

I'm not too worried about the other two drivers.  The code in st5481_d.c
seems to fall back fine to URB_ISO_ASAP if the submission with the
start_frame set failed.  devio.c is usbfs, and I can't tell what
userspace drivers do. (It could be argued that if they needed such tight
control over isoc, they should have written a kernel driver.)

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Use of start_frame in usbusx2yaudio.c

[Clemens Ladisch]

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

Re: Use of start_frame in usbusx2yaudio.c

[Alan Stern]

On Tue, 11 May 2010, 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?

BTW, urb->start_frame generally is ignored as an input parameter.  Many 
host controller drivers pay no attention to it.  Unless someone has a 
real reason, I think we are better off not using it.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Use of start_frame in usbusx2yaudio.c

[Sarah Sharp]

On Wed, May 12, 2010 at 10:54:23AM -0400, Alan Stern wrote:
> On Tue, 11 May 2010, 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?
> 
> BTW, urb->start_frame generally is ignored as an input parameter.  Many 
> host controller drivers pay no attention to it.  Unless someone has a 
> real reason, I think we are better off not using it.

Oh good.  In theory, the xHCI driver is supposed to be able to set the
starting frame ID of an isoc transfer (although the current patches for
isoc don't do that).  The xHCI spec writers were looking at limiting
software to only being able to set the frame ID on the very first
transfer you enqueue to the endpoint, to limit the complexity of the
hardware scheduler.  It looks like they won't have an issue with legacy
drivers if they do.

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html