[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20100512152137.GA3358@xanatos>
Date: Wed, 12 May 2010 08:21:37 -0700
From: Sarah Sharp <sarah.a.sharp@...ux.intel.com>
To: Alan Stern <stern@...land.harvard.edu>
Cc: Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
Clemens Ladisch <clemens@...isch.de>,
Tejun Heo <tj@...nel.org>,
Christoph Lameter <cl@...ux-foundation.org>,
Joe Perches <joe@...ches.com>,
USB list <linux-usb@...r.kernel.org>,
alsa-devel@...a-project.org,
Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Use of start_frame in usbusx2yaudio.c
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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists