On 1/8/07, Greg KH [EMAIL PROTECTED] wrote:
Hi,
I dropped all of the EHCI scheduler patches from my tree a week or so
ago due to some merge conflicts that I couldn't easily resolve. As it
looks like it is going to be a while before these patches go into
mainline, I figure there's no need to
From: Monty Montgomery [EMAIL PROTECTED]
Greg, the next few patches are for previously requested fixes.
This patch eliminates fstn leakage on controller driver shutdown. The
visible effect is to eliminate 'dma_pool_destroy ehci_fstn,
busy' messages on ehci-hcd module removal.
Patch
On 11/7/06, Alan Stern [EMAIL PROTECTED] wrote:
Hm, I thought that for some reason since this only depended on the EHCI
scheduler code,
Correct
that it was going to be rolled into that big patchset
the next time it was released.
Oh, I'd been submitting incrementals since The Big
On 10/20/06, Alan Stern [EMAIL PROTECTED] wrote:
At this point it's beyond me. Monty will have to take it from here.
I will look more closely at what might have changed there. Despite
the code refactoring (and a hand-resolved patch collision at that
point) the async disable handling *should*
On 10/19/06, Alan Stern [EMAIL PROTECTED] wrote:
Monty has been making changes to this driver recently; maybe he has some
ideas about the problem.
I have been watching the thread worried that this is due to a change
I've made. However, I should not have done anything to change
handling on the
On 10/17/06, Alan Stern [EMAIL PROTECTED] wrote:
On Mon, 16 Oct 2006, Christopher Monty Montgomery wrote:
On 10/16/06, Alan Stern [EMAIL PROTECTED] wrote:
If this isn't the first URB in the stream then there should not be any
problem, assuming start_frame actually is one
On 10/15/06, Alan Stern [EMAIL PROTECTED] wrote:
Yes, differing interpretations. Perhaps we should introduce a new URB
submission flag, such as URB_ISO_STRICT, which would mean to schedule each
packet for its intended slot even if it's already too late. That way the
driver could choose
On 10/16/06, Alan Stern [EMAIL PROTECTED] wrote:
If this isn't the first URB in the stream then there should not be any
problem, assuming start_frame actually is one of the allocated slots.
I'm specifically concerned if it is not the first URB and start_frame
!= one of the slots. The case
On 10/11/06, Alan Stern [EMAIL PROTECTED] wrote:
Monty, you might try going through all the code you changed. There are
_lots_ of places where you have spaces instead of tabs.
you missed the discussion with GregKH about the fact that GMail
recently broke and started molesting plaintext
On 10/11/06, Clemens Ladisch [EMAIL PROTECTED] wrote:
If you don't want to 'throw away' the samples that should have been
played during the underrun but instead want to play them (and all
following samples) later, call snd_pcm_forward() to skip over some part
of the buffer.
OK, I had assumed
On 10/9/06, Alan Stern [EMAIL PROTECTED] wrote:
On Mon, 9 Oct 2006, Christopher Monty Montgomery wrote:
On 10/9/06, Alan Stern [EMAIL PROTECTED] wrote:
So you're saying if the current uframe is N when you receive an URB whose
first slot belongs in uframe N+1, then you have to reject
On 10/10/06, Clemens Ladisch [EMAIL PROTECTED] wrote:
You could read the delay just after the write and check that it is at
least as big as the data you've written, but this can, of course, race
in the other way. (Well, you could think of that as a safety margin ...)
The race is more
On 10/9/06, Alan Stern [EMAIL PROTECTED] wrote:
The lengths of underruns are generally biased toward low numbers, right?
The most common length is 0 (no underrun), and the next most common is 1
slot.
I'm not actually sure of that.
Now I don't have hard numbers to support this, but I rather
On 10/9/06, Alan Stern [EMAIL PROTECTED] wrote:
It's amusing watching the two of you talk past each other... especially
in regard to issues of latency.
I'd have called it 'frustrating', but the discussion is at least still
moving forward.
Let's consider a simple case. Suppose we're using a
On 10/9/06, Alan Stern [EMAIL PROTECTED] wrote:
Don't much like that one. Requires HCDs to record history that would
otherwise not be needed, and interrogate it.
I don't like it either; even less than #1. However Monty seemed to
mention it, so I brought it up for discussion.
If it turned
On 10/10/06, Alan Stern [EMAIL PROTECTED] wrote:
So far we haven't settled on anything that is exactly correct.
Agreed.
In any case, missed slots do _not_ turn into delayed/out-of-phase data.
They are just missed, or as you say, pure dropouts.
You assume a single device at a time.
On 10/10/06, Alan Stern [EMAIL PROTECTED] wrote:
You're talking about detecting URB completion before a completion IRQ
arrives. In other words, polling. I would prefer not to see that added
to the HCDs, but it is a possibility.
Ah, EHCI (or USB in general) specifies a completion interrupt
On 10/8/06, Alan Stern [EMAIL PROTECTED] wrote:
On Sun, 8 Oct 2006, Christopher Monty Montgomery wrote:
On 10/8/06, Alan Stern [EMAIL PROTECTED] wrote:
No, I'm just pointing out that it's not always possible to tell at
submission time whether the submission was made early enough
On 10/9/06, David Brownell [EMAIL PROTECTED] wrote:
On Sunday 08 October 2006 8:16 pm, Alan Stern wrote:
On Sun, 8 Oct 2006, Christopher Monty Montgomery wrote:
I don't know what this low-latency thing is you're referring to. But
it sounds like it's trying to be _too_ low
On 10/9/06, Alan Stern [EMAIL PROTECTED] wrote:
So you're saying if the current uframe is N when you receive an URB whose
first slot belongs in uframe N+1, then you have to reject it, right?
No, that we try to fill the slot and if the clock is at/past the slot
when we're done filling, look to
Okay. Then there's nothing to stop you from putting 1 or 2 ms worth of
data in each URB and keeping 2 URBs in the queue at all times. Except
that you run a high risk of loss-of-sync owing to kernel latency. But
that will always be true in a low-latency application.
2ms of read URB +
On 10/9/06, Clemens Ladisch [EMAIL PROTECTED] wrote:
Christopher Monty Montgomery wrote:
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
According to Clemens, snd-usb-audio can be configured to use or to not use
dummy data, by the application. If it's doing the wrong thing your
On 10/9/06, David Brownell [EMAIL PROTECTED] wrote:
Exactly why I'm reminding you that your driver -- queueing only one
URB at a time -- is the source of a **LOT** of your problemss.
I've not heard any other plausible suggestions other than repeated
assertions that 'Linux can't do that'.
On 10/9/06, David Brownell [EMAIL PROTECTED] wrote:
On Friday 06 October 2006 7:00 pm, Christopher Monty Montgomery wrote:
So?
I hand you a pointer to memory and ask you what type it is. You can't
tell me. You have to have the pointer *to the parent* to tell. It's
not a show-stopper
On 10/9/06, Clemens Ladisch [EMAIL PROTECTED] wrote:
Alan Stern wrote:
[...]
To satisfy the requirements, a driver only needs to make sure that the
stream never starves. It can easily do so, regardless of whether it
has any data available to send. It can even submit 0-length ISO URBs,
On 10/9/06, David Brownell [EMAIL PROTECTED] wrote:
On Monday 09 October 2006 9:02 am, Christopher Monty Montgomery wrote:
On 10/9/06, David Brownell [EMAIL PROTECTED] wrote:
Exactly why I'm reminding you that your driver -- queueing only one
URB at a time -- is the source of a **LOT
On 10/9/06, Clemens Ladisch [EMAIL PROTECTED] wrote:
Christopher Monty Montgomery wrote:
Hrm. that's non-atomic and as such involves a race and is not
reliable. Or am I missing something in the API? Does the xrun staus
persist until read?
The delay gets smaller when the device reads
On 10/9/06, David Brownell [EMAIL PROTECTED] wrote:
I need 2ms latency.
Do it the way we're doing it.
Uhh.. that is barely working for 50ms latency right now. And even if
we got optimal performance, it could never theoretically get down to
2ms.
Too bad. This is The Way.
You have
On 10/9/06, David Brownell [EMAIL PROTECTED] wrote:
On Monday 09 October 2006 9:37 am, Christopher Monty Montgomery wrote:
I hand you a pointer to memory and ask you what type it is. You can't
tell me.
A C struct foo * points to a foo.
For a C void *, the type info is out-of-band
On 10/9/06, David Brownell [EMAIL PROTECTED] wrote:
On Monday 09 October 2006 10:10 am, Christopher Monty Montgomery wrote:
You have not ** YET ** tried to do it the way that's known to work,
so it's no surprise you've been seeing the failures which lead to
the requirement to use
On 10/7/06, David Brownell [EMAIL PROTECTED] wrote:
On Friday 06 October 2006 9:38 pm, Christopher Monty Montgomery wrote:
What do I have or what do I want? I *want* 2-5ms from sample to
playback. MacOSX can do it. Windows can do it. We can't, at least
not yet.
We can't ... why
For example, let's say an URB is submitted for slot S, just as S's
microframe is starting. ehci-hcd adds the URB into the hardware schedule;
was it in time for the controller to see it?
Right now, that attempt would be outright rejected. ehci-sched will
not (and never would) schedule into
On 10/8/06, Alan Stern [EMAIL PROTECTED] wrote:
On Sun, 8 Oct 2006, Christopher Monty Montgomery wrote:
Oh, Hell. I think I know why. Because low-latency is only ever one
URB deep. There's no second URB waiting when the first completes. So
the stream is shut down.
I don't know what
On 10/8/06, Alan Stern [EMAIL PROTECTED] wrote:
On Sun, 8 Oct 2006, Christopher Monty Montgomery wrote:
[or are you worried about caching and propogation of changes?]
No, I'm just pointing out that it's not always possible to tell at
submission time whether the submission was made early
On 10/8/06, Alan Stern [EMAIL PROTECTED] wrote:
No, I'm just pointing out that it's not always possible to tell at
submission time whether the submission was made early enough.
Is that actually true? If the slot is filled, we look at the clock,
and the clock says definitively that the filled
On 10/7/06, David Brownell [EMAIL PROTECTED] wrote:
No, not entirely correct; though I don't think anyone had previously
pointed out that resubmitting wouldn't necessarily make the underlying
issue go away!
Clemens asked about a week and a half ago. You weren't on the
explicit Cc: list
Oops, I only replied to Greg first time.
On 10/7/06, Greg KH [EMAIL PROTECTED] wrote:
On Sat, Oct 07, 2006 at 01:26:13AM -0400, Christopher Monty Montgomery wrote:
Monty, how does other operating systems report this back to the driver?
I'm guessing that Windows uses yet-another-message, right
On 10/7/06, David Brownell [EMAIL PROTECTED] wrote:
And also, the parts are not uniform. ITDs are uniform; SITDs are not,
especially in conjunction with FSTNs.
No, but we could imagine they're all rectangular if we only use PowerPoint.
HCDs are _allowed_ to do that if they want. I don't
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
In my primary use case, the endpoint will lose its bandwidth
reservation,
What makes you think that?
Bandwidth fragmentation. If we release an ISO stream's bandwidth from
the middle of a schedule frame, we cannot currently recover the hole.
On 10/6/06, Clemens Ladisch [EMAIL PROTECTED] wrote:
Except when doing input. In ALSA, we just call them xruns. :-)
Yes, that is the better term.. I should be using it.
All three choices are possible, depending on how the application has
configured the device. Either application xruns get
On 10/6/06, Clemens Ladisch [EMAIL PROTECTED] wrote:
In the case of ALSA, it's the application's choice whether an underrun
should stop the stream.
Yes, I agree the application should have such a choice.
I had noticed, though, that I either never see underruns, or when an
underrun happens,
On 10/6/06, Christopher Monty Montgomery [EMAIL PROTECTED] wrote:
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
You still don't seem to understand. Kernel latency by itself _cannot_
cause a bandwidth reservation to be lost.
I call bullshit. A single well-placed printk inside
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
On Fri, 6 Oct 2006, Clemens Ladisch wrote:
In the case of ALSA, it's the application's choice whether an underrun
should stop the stream. I don't know which application you were using,
but in the case of Jack, it was decided that it would be
On 10/6/06, Christopher Monty Montgomery [EMAIL PROTECTED] wrote:
NetBSD does not revoke bandwidth on XRUN.
BTW, I realize that NetBSD is overall far more screwed with respect to
ISOCH than we are. But they don't just shut down on xrun ;-)
Monty
On 10/6/06, David Brownell [EMAIL PROTECTED] wrote:
On Thursday 28 September 2006 12:33 am, Christopher Monty Montgomery wrote:
patch 15: This is a usbaudio fixed necessitated by fixing the isoch
underrun detection/reporting in ehci. usbaudio playback nominally
causes one harmless underrun
On 10/6/06, Christopher Monty Montgomery [EMAIL PROTECTED] wrote:
Justify that.
Ah, the list is delivering things in a weird order, you've addressed
this point in mail that just arrived.
My other points still stand. This patch is necessitated by the other
patches. Leaving 1-14 and nacking 15
On 10/6/06, David Brownell [EMAIL PROTECTED] wrote:
Nope; not a tradeoff. For one thing, the pointers _are_ typed;
for another, we have no option to trade _to_ since the hardware
requires using those typed pointers.
You cannot tell the type of the object you currently have. You can
only
+ if (iso){
Use if (iso) { instead ... one espace before such brackets.
I did not entirely succeed in suppressing my own coding style in these
patches; I relied heavily on linux-c-mode, but there are a number fo
things it will not change/enforce (like spaces instead of tabs; it
will
On 10/6/06, David Brownell [EMAIL PROTECTED] wrote:
On Thursday 05 October 2006 12:21 pm, Christopher Monty Montgomery wrote:
endpoint_disable is where the budget is released, which has
little/nothing to do with the hardware schedule itself. Once a USB
periodic endpoint is open()ed
On 10/6/06, David Brownell [EMAIL PROTECTED] wrote:
Hmm, in the current EHCI scheduler, the place which returns EL2NSYNC is
arguably just a bug that should get fixed ... it even includes the
comment someday, try to reschedule.
I'll point out we did discuss this and came to a different
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
Notice that you didn't answer the question I asked. I asked why you
thought the reservation would be lost, and you replied by explaining why
the reservation could not be recovered once it was lost. My original
question still stands.
What else
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
It is still the case that not being able to distinguish between normal
shutdown and xrun in case 2 is scary, again because USB bandwidth
allocation is fragile. The 'xrun and shutdown are the same' is
suboptimal only because of this
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
Why do you say that? In principle it's possible to report loss of sync
quite easily. uhci-hcd reports it by setting
urb-iso_frame_desc[n].status to -EXDEV. It won't release the bandwidth
reservation when this happens. I don't see any reason
On 10/6/06, David Brownell [EMAIL PROTECTED] wrote:
My other points still stand. This patch is necessitated by the other
patches.
Did one of them cause EL2NSYNC to get reported differently then?
No, I mean that standard usage patterns will reliably cause an
EL2NSYNC when my new scheduler
On 10/6/06, David Brownell [EMAIL PROTECTED] wrote:
On Friday 06 October 2006 7:22 pm, Christopher Monty Montgomery wrote:
Except that your comment is incorrect in both content and intent. The
whole point is that the bandwidth *is* still there and *will* be
available, by design.
Nope
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
I don't know the details of ehci-hcd, but this may well be unfeasible. It
would require checking the status of previous submissions every time a new
submission is made, which might be a considerable extra load.
ehci-sched already knows if slots
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
According to Clemens, snd-usb-audio can be configured to use or to not use
dummy data, by the application. If it's doing the wrong thing your
application is therefore at fault.
If it uses dummy data, it never reports the xrun. If it doesn't
On 10/6/06, Alan Stern [EMAIL PROTECTED] wrote:
Basically you're saying that the old driver would sometimes lose a
bandwidth reservation. I'm not disputing that.
But this could be a result of the way snd-usb-audio was being used, and it
could also be a result of the way ehci-hcd was
On 10/7/06, Christopher Monty Montgomery [EMAIL PROTECTED] wrote:
Conceeded.
Misspelled
Monty
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
On 10/6/06, David Brownell [EMAIL PROTECTED] wrote:
Not a good analogy. More accurate would be a jigsaw puzzle ... because
you can pull a piece out of the middle, and then safely put it back in
the same place.
I chose my analogy carefully. If we were doing better than we're
doing right now,
On 10/7/06, Greg KH [EMAIL PROTECTED] wrote:
Ok, then what is the proper channel for reporting the missed slots? Did
I miss something here?
I think Alan is mostly done p0wning me, but we've not decided what to
do quite yet.
Monty
On 10/7/06, David Brownell [EMAIL PROTECTED] wrote:
NOTE: I updated $SUBJECT to be accurate.
yes, thank you.
A quick search of email that I exchanged with you on this topic only
includes the following, from 4-June-2006:
The EL2NSYNC will happen on occasion, e.g. fell behind by having the
On 10/7/06, David Brownell [EMAIL PROTECTED] wrote:
I will point out I was documenting what the code actually did, and
what the code actually asserted.
Nope ... current kernel plus patch #1 obeys the comment I showed.
ahhh... right, OK, point. Yes, you're right. Misstep in the
On 10/7/06, David Brownell [EMAIL PROTECTED] wrote:
I'd made suggestions there ... probably the simplest way for things like
the audio driver is to return a positive status code from urb submit,
indicating a schedule lossage fault but not a submit error. Simple enough
to make sure usbcore
On 10/7/06, David Brownell [EMAIL PROTECTED] wrote:
Right now == what's in 2.6.19-rc1, and that's like the jigsaw.
The optimal situation is tetris with entirely square blocks.
I'm not sure I'd agree; certainly I chose my analogy carefully too.
OK, so it's the time-pronouns we're being
On 10/7/06, David Brownell [EMAIL PROTECTED] wrote:
On Friday 06 October 2006 9:59 pm, Greg KH wrote:
I didn't understand what was so objectionable with the alsa driver
change in the first place, but oh well, I'll wait for the next
iteration...
One thing is that nothing actually
On 10/4/06, Clemens Ladisch [EMAIL PROTECTED] wrote:
I guess sox trips this because it opens the device, sets some sample
formats to check which are available, and then resets the device without
playing any data. (Many applications using the OSS API do this.)
Ah, that is indeed plausible.
thanks. I'll submit an additional patch.
Monty
On 10/4/06, Alan Stern [EMAIL PROTECTED] wrote:
Monty:
Your new patches cause a problem on systems with more than one EHCI
controller. This statement
ehci-budget_pool =
kmem_cache_create (ehci_budget,
On 10/5/06, Alan Stern [EMAIL PROTECTED] wrote:
Bandwidth is allocated in the USB budget as soon as the first URB of a
stream is submitted. That bandwidth remains allocated until the stream is
interrupted, which happens whenever there are no URBs queued for the
endpoint and the last
[BTW, Alan, I get the impression we did some amount of talking past
each other. Some of that might be terminology.]
The scheduler, as I modified it, is actually two pieces; the budgeter
(which reserves bandwidth and makes timing decisions) and the
scheduler (which inspects the budget and
On 10/5/06, Alan Stern [EMAIL PROTECTED] wrote:
The question is, how does a stream get disabled?
ehci_endpoint_disable(). As patched, that will perform the final
refcount decrement and reap the ehci_iso_stream, which will also
release the budget.
No, that's not what I said. The way it's
On 10/5/06, Alan Stern [EMAIL PROTECTED] wrote:
The intent is that endpoint_disable is called upon close(); in my
testing (and from the code I read), close would in fact always result
in an endpoint_disable.
No, it doesn't. endpoint_disable() happens only at a few specific times:
when an
to associate with bandwidth budget reservations
later.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci.h
b/drivers/usb/host/ehci.h
--- a/drivers/usb/host/ehci.h 2006-08-07 00:18:54.0 -0400
+++ b/drivers/usb/host
with nothing to do.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci.h
b/drivers/usb/host/ehci.h
--- a/drivers/usb/host/ehci.h 2006-09-26 22:12:14.0 -0400
+++ b/drivers/usb/host/ehci.h 2006-09-26 22:12
-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-hcd.c
b/drivers/usb/host/ehci-hcd.c
--- a/drivers/usb/host/ehci-hcd.c 2006-09-26 22:12:14.0 -0400
+++ b/drivers/usb/host/ehci-hcd.c 2006-09-26 22:17
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 4: modes ehci_iso_sched funtions to one place. Trivial patch
that makes no funcitonal difference.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb
difference.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-sched.c
b/drivers/usb/host/ehci-sched.c
--- a/drivers/usb/host/ehci-sched.c 2006-09-26 22:20:51.0 -0400
+++ b/drivers/usb/host/ehci-sched.c 2006-09
of unused ifdefs, this patch results in no
functional difference.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-sched.c
b/drivers/usb/host/ehci-sched.c
--- a/drivers/usb/host/ehci-sched.c 2006-09-26 22:22
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 7: slightly rearrange sitd patching and linking code flow to
simplify addition of sITD backpointer support later. This should
result in no functional difference.
Signed-off-by: Christopher Monty Montgomery [EMAIL
at a time that
guarantees they'd have finished).
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-sched.c
b/drivers/usb/host/ehci-sched.c
--- a/drivers/usb/host/ehci-sched.c 2006-09-26 22:26:57.0 -0400
such that the lowest level of the QH
tree can be smaller than the width of the full periodic schedule;
useful for saving memory upon implementation of save-state FSTNs.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci.h
as well as logic for making scheduling decisions
based on previously budgeted allocations.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci.h
b/drivers/usb/host/ehci.h
--- a/drivers/usb/host/ehci.h 2006-09-26 22:29
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 11: adds necessary calls such that the shadow budget is actively
maintained, but the rest of the scheduler is not yet using the shadow
budget to make any decisions.
Signed-off-by: Christopher Monty Montgomery [EMAIL
Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci.h
b/drivers/usb/host/ehci.h
--- a/drivers/usb/host/ehci.h 2006-09-26 22:30:47.0 -0400
+++ b/drivers/usb/host/ehci.h 2006-09-26 22:32:07.0 -0400
@@ -486,13 +486,9 @@ struct ehci_qh
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 13: Adds low-level scheduler mechanisms for linking, unlinking,
manipulating and maintaining FSTNs. Turns on shadow budget logic to
allow/use FSTNs in budgeting.
Signed-off-by: Christopher Monty Montgomery [EMAIL
in startup that the usbaudio code doesn't currently handle
properly.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/sound/usb/usbaudio.c
b/sound/usb/usbaudio.c
--- a/sound/usb/usbaudio.c 2006-09-26 22:10:24.0 -0400
+++ b/sound/usb
86 matches
Mail list logo
