10 Jan, 2015
2 commits
-
The USB stack uses error code -ENOSPC to indicate that the periodic
schedule is too full, with insufficient bandwidth to accommodate a new
allocation. It uses -EFBIG to indicate that an isochronous transfer
could not be linked into the schedule because it would exceed the
number of isochronous packets the host controller driver can handle
(generally because the new transfer would extend too far into the
future).ehci-hcd uses the wrong error code at one point. This patch fixes it,
along with a misleading comment and debugging message.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
Commit c3ee9b76aa93 (EHCI: improved logic for isochronous scheduling)
introduced the idea of using ehci->last_iso_frame as the origin (or
base) for the circular calculations involved in modifying the
isochronous schedule. However, the new code it added used
ehci->last_iso_frame before the value was properly initialized. This
patch rectifies the mistake by moving the initialization lines earlier
in iso_stream_schedule().This fixes Bugzilla #72891.
Signed-off-by: Alan Stern
Fixes: c3ee9b76aa93
Reported-by: Joe Bryant
Tested-by: Joe Bryant
Tested-by: Martin Long
CC:
Signed-off-by: Greg Kroah-Hartman
20 Oct, 2013
2 commits
-
This patch fixes several sparse errors in ehci-hcd introduced by
commit 3d091a6f7039 (USB: EHCI: AMD periodic frame list table quirk).
Although the problem fixed by that commit affects only little-endian
systems, the source code has to use types appropriate for big-endian
too.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
This patch fixes a type mismatch in ehci-hcd caused by commit
b35c5009bbf6 (USB: EHCI: create per-TT bandwidth tables). The c_maskp
parameter in check_intr_schedule() was changed to point to unsigned
int rather than __hc32, but the prototype declaration wasn't adjusted
accordingly.Signed-off-by: Alan Stern
Reported-by: kbuild test robot
Signed-off-by: Greg Kroah-Hartman
15 Oct, 2013
2 commits
-
This patch changes the initial delay before the startup of a newly
scheduled isochronous stream. Currently the stream doesn't start
for at least 5 ms (40 microframes). This value is just an estimate;
it has no real justification.Instead, we can start the stream as soon as possible after the
scheduling computations are complete. Essentially this requires
nothing more than reading the frame counter after the stream is
scheduled, instead of before.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
This patch continues the scheduling changes in ehci-hcd by adding a
table to store the bandwidth allocation below each TT. This will
speed up the scheduling code, as it will no longer need to read
through the entire schedule to compute the bandwidth currently in use.Properly speaking, the FS/LS budget calculations should be done in
terms of full-speed bytes per microframe, as described in the USB-2
spec. However the driver currently uses microseconds per microframe,
and the scheduling code isn't robust enough at this point to change
over. For the time being, we leave the calculations as they are.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman
12 Oct, 2013
6 commits
-
This patch significantly changes the scheduling code in ehci-hcd.
Instead of calculating the current bandwidth utilization by trudging
through the schedule and adding up the times used by the existing
transfers, we will now maintain a table holding the time used for each
of 64 microframes. This will drastically speed up the bandwidth
computations.In addition, it eliminates a theoretical bug. An isochronous endpoint
may have bandwidth reserved even at times when it has no transfers
listed in the schedule. The table will keep track of the reserved
bandwidth, whereas adding up entries in the schedule would miss it.As a corollary, we can keep bandwidth reserved for endpoints even
when they aren't in active use. Eventually the bandwidth will be
reserved when a new alternate setting is installed; for now the
endpoint's reservation takes place when its first URB is submitted.A drawback of this approach is that transfers with an interval larger
than 64 microframes will have to be charged for bandwidth as though
the interval was 64. In practice this shouldn't matter much;
transfers with longer intervals tend to be rather short anyway (things
like hubs or HID devices).Another minor drawback is that we will keep track of two different
period and phase values: the actual ones and the ones used for
bandwidth allocation (which are limited to 64). This adds only a
small amount of overhead: 3 bytes for each endpoint.The patch also adds a new debugfs file named "bandwidth" to display
the information stored in the new table.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
This patch begins the process of unifying the scheduling parameters
that ehci-hcd uses for interrupt and isochronous transfers. It
creates an ehci_per_sched structure, which will be stored in both
ehci_qh and ehci_iso_stream structures, and will contain the common
scheduling information needed for both.Initially we merely create the new structure and move some existing
fields into it. Later patches will add more fields and utilize these
structures in improved scheduling algorithms.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
ehci-hcd is inconsistent in the sentinel values it uses to indicate
that no frame number has been assigned for a periodic transfer. Some
places it uses NO_FRAME (defined as 65535), other places it uses -1,
and elsewhere it uses 9999.This patch defines a value for NO_FRAME which can fit in a 16-bit
signed integer, and changes the code to use it everywhere.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
The scheduling code in ehci-hcd contains an error. For full-speed
isochronous-OUT transfers, the EHCI spec forbids scheduling
Start-Split transactions in H-microframe 7, but the driver allows it
anyway. This patch adds a check to prevent it.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
Although the bandwidth statistics maintained by ehci-hcd show up only
in the /sys/kernel/debug/usb/devices file, they ought to be calculated
correctly. The calculation for full-speed isochronous endpoints is
wrong; it mistakenly yields bytes per microframe instead of bytes per
frame. The "interval" value, which is in frames, should not be
converted to microframes.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
The check_intr_schedule() routine in ehci-hcd looks at the wrong
microframes when checking to see if a full-speed or low-speed
interrupt endpoint will fit in the periodic schedule. If the
Start-Split transaction is scheduled for microframe N then the
Complete-Split transactions get scheduled for microframes N+2, N+3, and
N+4. However the code considers N+1, N+2, and N+3 instead.This patch fixes the limits on the "for" loop and also improves the
use of whitespace.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman
18 Sep, 2013
2 commits
-
This patch updates the iso_stream_schedule() routine in ehci-sched.c
to handle cases where an underrun causes an isochronous endpoint's
queue to empty out, but the client driver wants to maintain
synchronization with the device (i.e., the URB_ISO_ASAP flag is not
set). This could not happen until recently, when ehci-hcd switched
over to completing URBs in a tasklet.(This may seem like an unlikely case to worry about, but underruns are
all too common with the snd-usb-audio driver, which doesn't use
URB_ISO_ASAP.)As part of the fix, some URBs may need to be given back when they are
submitted. This is necessary when the URB's scheduled slots all fall
before the current value of ehci->last_iso_frame, and as an
optimization we do it also when the slots all fall before the current
frame number.As a second part of the fix, we may need to skip some but not all of
an URB's packets. This is necessary when some of the URB's scheduled
slots fall before the current value of ehci->last_iso_frame and some
of them fall after the current frame number. A new field
(first_packet) is added to struct ehci_iso_sched, to indicate how many
packets should be skipped.Signed-off-by: Alan Stern
CC: Ming Lei
Signed-off-by: Greg Kroah-Hartman -
This patch interchanges the "if" and "else" branches of the big "if"
statement in iso_stream_schedule(), in preparation for the next patch
in this series. That is, it changesif (likely(!...)) {
A
} else {
B
}to
if (unlikely(...)) {
B
} else {
A
}Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman
31 Aug, 2013
2 commits
-
The debugging code for ehci is enabled to run if the DEBUG flag is defined.
This patch enables the debugging code also when the kernel is configured
with dynamic debugging on.Signed-off-by: Xenia Ragiadakou
Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
This patch removes ehci_vdbg debugging statements from EHCI host controller
driver because they produce too much information, lowering the signal to noise
ratio when debugging, and because they are not used anymore.Signed-off-by: Xenia Ragiadakou
Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman
19 Aug, 2013
1 commit
-
We want these USB fixes in this branch as well.
Signed-off-by: Greg Kroah-Hartman
13 Aug, 2013
2 commits
-
Since commits 4005ad4390bf (EHCI: implement new semantics for
URB_ISO_ASAP) and c75c5ab575af (ALSA: USB: adjust for changed 3.8 USB
API) became widely distributed, people have been experiencing problems
with audio transfers. The slightest underrun causes complete failure,
requiring the audio stream to be restarted.It turns out that the current isochronous API doesn't handle underruns
in the best way. The ALSA developers would much rather have transfers
that are submitted too late be accepted and complete in the normal
fashion, rather than being refused outright.This patch implements the requested approach. When an isochronous URB
submission is so late that all its scheduled slots have already
expired, a debugging message will be printed in the log and the URB
will be accepted as usual. Assuming it was submitted by a completion
handler (which is normally the case), it will complete shortly
thereafter with all the usb_iso_packet_descriptor status fields marked
-EXDEV.This fixes (for ehci-hcd)
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603
It should be applied to all kernels that include commit 4005ad4390bf.
Signed-off-by: Alan Stern
Tested-by: Maksim Boyko
CC: Clemens Ladisch
CC:
Signed-off-by: Greg Kroah-Hartman -
ehci-hcd currently unlinks an interrupt QH when it becomes empty, that
is, after its last URB completes. This works well because in almost
all cases, the completion handler for an interrupt URB resubmits the
URB; therefore the QH doesn't become empty and doesn't get unlinked.When we start using tasklets for URB completion, this scheme won't work
as well. The resubmission won't occur until the tasklet runs, which
will be some time after the completion is queued with the tasklet.
During that delay, the QH will be empty and so will be unlinked
unnecessarily.To prevent this problem, this patch adds a 5-ms time delay before empty
interrupt QHs are unlinked. Most often, during that time the interrupt
URB will be resubmitted and thus we can avoid unlinking the QH.Signed-off-by: Alan Stern
Signed-off-by: Ming Lei
Signed-off-by: Greg Kroah-Hartman
30 May, 2013
1 commit
-
This patch adds some code that inadvertently got left out of commit
c1fdb68e3d73741630ca16695cf9176c233be7ed (USB: EHCI: changes related
to qh_refresh()). The calls to qh_refresh() and qh_link_periodic()
were taken out of qh_schedule(); therefore it is necessary to call
these routines manually after calling qh_schedule().Signed-off-by: Alan Stern
Reported-and-tested-by: Oleksij Rempel
Signed-off-by: Greg Kroah-Hartman
29 May, 2013
1 commit
-
This patch reverts commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d
(USB: EHCI: fix bug in scheduling periodic split transfers). The
commit was valid -- it fixed a real bug -- but the periodic scheduler
in ehci-hcd is in such bad shape (especially the part that handles
split transactions) that fixing one bug is very likely to cause
another to surface. That's what happened in this case; the result was
choppy and noisy playback on certain 24-bit audio devices.The only real fix will be to rewrite this entire section of code. My
next project...This fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110.
Thanks to Tim Richardson for extra testing and feedback, and to Joseph
Salisbury and Tyson Tan for tracking down the original source of the
problem.Signed-off-by: Alan Stern
CC: Joseph Salisbury
CC: Tim Richardson
Cc: stable
Signed-off-by: Greg Kroah-Hartman
29 Mar, 2013
1 commit
-
This lets us fix the build error that happens when these two trees are merged
together.Signed-off-by: Greg Kroah-Hartman
26 Mar, 2013
5 commits
-
[Description written by Alan Stern]
Soeren tracked down a very difficult bug in ehci-hcd's DMA pool
management of iTD and siTD structures. Some background: ehci-hcd
gives each isochronous endpoint its own set of active and free itd's
(or sitd's for full-speed devices). When a new itd is needed, it is
taken from the head of the free list, if possible. However, itd's
must not be used twice in a single frame because the hardware
continues to access the data structure for the entire duration of a
frame. Therefore if the itd at the head of the free list has its
"frame" member equal to the current value of ehci->now_frame, it
cannot be reused and instead a new itd is allocated from the DMA pool.
The entries on the free list are not released back to the pool until
the endpoint is no longer in use.The bug arises from the fact that sometimes an itd can be moved back
onto the free list before itd->frame has been set properly. In
Soeren's case, this happened because ehci-hcd can allocate one more
itd than it actually needs for an URB; the extra itd may or may not be
required depending on how the transfer aligns with a frame boundary.
For example, an URB with 8 isochronous packets will cause two itd's to
be allocated. If the URB is scheduled to start in microframe 3 of
frame N then it will require both itds: one for microframes 3 - 7 of
frame N and one for microframes 0 - 2 of frame N+1. But if the URB
had been scheduled to start in microframe 0 then it would require only
the first itd, which could cover microframes 0 - 7 of frame N. The
second itd would be returned to the end of the free list.The itd allocation routine initializes the entire structure to 0, so
the extra itd ends up on the free list with itd->frame set to 0
instead of a meaningful value. After a while the itd reaches the head
of the list, and occasionally this happens when ehci->now_frame is
equal to 0. Then, even though it would be okay to reuse this itd, the
driver thinks it must get another itd from the DMA pool.For as long as the isochronous endpoint remains in use, this flaw in
the mechanism causes more and more itd's to be taken slowly from the
DMA pool. Since none are released back, the pool eventually becomes
exhausted.This reuslts in memory allocation failures, which typically show up
during a long-running audio stream. Video might suffer the same
effect.The fix is very simple. To prevent allocations from the pool when
they aren't needed, make sure that itd's sent back to the free list
prematurely have itd->frame set to an invalid value which can never be
equal to ehci->now_frame.This should be applied to -stable kernels going back to 3.6.
Signed-off-by: Soeren Moch
Signed-off-by: Alan Stern
Cc: stable
Signed-off-by: Greg Kroah-Hartman -
This patch (as1664) converts ehci-hcd's async_unlink, async_iaa, and
intr_unlink from singly-linked lists to standard doubly-linked
list_heads. Originally it didn't seem necessary to use list_heads,
because items are always added to and removed from these lists in FIFO
order. But now with more list processing going on, it's easier to use
the standard routines than continue with a roll-your-own approach.I don't know if the code ends up being notably shorter, but the
patterns will be more familiar to any kernel hacker.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
This patch (as1662) does some more QH-related cleanup in ehci-hcd.
The qh->needs_rescan flag is currently used for two different
purposes; the patch replaces it with two separate flags for greater
clarity: qh->dequeue_during_giveback indicates that a completion
handler dequeued an URB (implying that a rescan is needed), and
qh->exception indicates that the QH is in an exceptional state
requiring an unlink (either it encountered an I/O error or an unlink
was requested).The new flags get set where the dequeue, exception, or unlink request
occurred, rather than where the unlink is started. This is so that in
the future, if we need to, we will be able to tell apart unlinks that
truly were required from those that were carried out merely because
the QH wasn't being used.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
This patch (as1658) cleans up the usage of qh_completions() in
ehci-hcd. Currently the function's return value indicates whether any
URBs were given back; the idea was that the caller can scan the QH
over again to handle any URBs that were dequeued by a completion
handler. This is not necessary; when qh_completions() is ready to
give back dequeued URBs, it does its own rescanning.Therefore the new return value will be a flag indicating whether the
caller needs to unlink the QH. This is more convenient than forcing
the caller to check qh->needs_rescan, and it makes a lot more sense --
why should "needs_rescan" imply that an unlink is needed? The callers
are also changed to remove the unneeded rescans.Lastly, the check for whether qh->qtd_list is non-empty is removed
from the start of qh_completions(). Two of the callers have to make
this test anyway, so the same test can simply be added to the other
two callers.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
This patch (as1638) makes several changes to the ehci-hcd driver, all
related to the qh_refresh() function. This function must be called
whenever an idle QH gets linked back into either the async or the
periodic schedule.Change a BUG_ON() in the qh_update routine to a WARN_ON().
Since this code runs in atomic context, a BUG_ON() would
immediately freeze the whole system.Remove two unneeded calls to qh_refresh(), one when a QH is
initialized and one when a QH becomes idle. Adjust the
adjacent comments accordingly.Move the qh_refresh() and qh_link_periodic() calls for new
interrupt URBs to after the new TDs have been added.As a result of the previous two changes, qh_refresh() is never
called when the qtd_list is empty. The corresponding check in
qh_refresh() can be removed, along with an indentation level.These changes should not cause any alteration of behavior.
Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman
31 Jan, 2013
2 commits
-
This patch (as1654) fixes a very old bug in ehci-hcd, connected with
scheduling of periodic split transfers. The calculations for
full/low-speed bus usage are all carried out after the correction for
bit-stuffing has been applied, but the values in the max_tt_usecs
array assume it hasn't been. The array should allow for allocation of
up to 90% of the bus capacity, which is 900 us, not 780 us.The symptom caused by this bug is that any isochronous transfer to a
full-speed device with a maxpacket size larger than about 980 bytes is
always rejected with a -ENOSPC error.Signed-off-by: Alan Stern
Cc: stable
Signed-off-by: Greg Kroah-Hartman -
This patch (as1653) fixes a bug in ehci-hcd. Unlike iTD entries, an
siTD entry in the periodic schedule may not complete until the frame
after the one it belongs to. Consequently, when scanning the periodic
schedule it is necessary to start with the frame _preceding_ the one
where the previous scan ended.Not doing this properly can result in memory leaks and failures to
complete isochronous URBs.Signed-off-by: Alan Stern
Reported-by: Andy Leiserson
Cc: stable
Signed-off-by: Greg Kroah-Hartman
12 Nov, 2012
1 commit
-
This patch (as1632b) fixes a bug in ehci-hcd. The USB core uses
urb->hcpriv to determine whether or not an URB is active; host
controller drivers are supposed to set this pointer to a non-NULL
value when an URB is queued. However ehci-hcd sets it to NULL for
isochronous URBs, which defeats the check in usbcore.In itself this isn't a big deal. But people have recently found that
certain sequences of actions will cause the snd-usb-audio driver to
reuse URBs without waiting for them to complete. In the absence of
proper checking by usbcore, the URBs get added to their endpoint list
twice. This leads to list corruption and a system freeze.The patch makes ehci-hcd assign a meaningful value to urb->hcpriv for
isochronous URBs. Improving robustness always helps.Signed-off-by: Alan Stern
Reported-by: Artem S. Tashkinov
Reported-by: Christof Meerwald
CC:
Signed-off-by: Greg Kroah-Hartman
25 Oct, 2012
1 commit
-
In preparation for splitting the ehci-hcd driver into a core library
and separate platform-specific driver modules, this patch (as1617)
changes the way ehci_read_frame_index() is handled.Since the same core library will have to work with both PCI and
non-PCI platforms, the quirk handler routine will be compiled
unconditionally. The decision about whether to call it or simply to
read the frame index register is made at run time, based on whether
the frame_index_bug quirk flag is set.Signed-off-by: Alan Stern
Acked-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman
23 Oct, 2012
1 commit
-
This patch (as1612) updates the isochronous scheduling and processing
in ehci-hcd to match the new semantics for URB_ISO_ASAP. It also adds
a missing "unlikely" in sitd_complete() to match the corresponding
statement in itd_complete(), and it increments urb->error_count in a
couple of places that had been overlooked.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman
22 Oct, 2012
3 commits
-
This patch (as1610) replaces multiplication and divison operations in
ehci-hcd's isochronous scheduling code with a bit-mask operation,
taking advantage of the fact that isochronous periods are always
powers of 2.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
This patch (as1609) changes the way ehci-hcd uses the "Isochronous
Scheduling Threshold" in its calculations. Until now the code has
ignored the threshold except for certain Intel PCI-based controllers.
This violates the EHCI spec.The new code takes the threshold into account always, removing the
need for the fs_i_thresh quirk flag. In addition it implements the
"full frame cache" setting more efficiently, moving forward only as
far as the next frame boundary instead of always moving forward 8
microframes.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
This patch (as1608) reworks the logic used by ehci-hcd for scheduling
isochronous transfers. Now the modular calculations are all based on
a window that starts at the last frame scanned for isochronous
completions. No transfer descriptors for any earlier frames can
possibly remain on the schedule, so there can be no confusion from
schedule wrap-around. This removes the need for a "slop" region of
arbitrary size.There's no need to check for URBs that are longer than the schedule
length. With the old code they could throw things off by wrapping
around and appearing to end in the near future rather than the distant
future. Now such confusion isn't possible, and the existing test for
submissions that extend too far into the future will also catch those
that exceed the schedule length. (But there still has to be an
initial test to handle the case where the schedule already extends as
far into the future as possible.)Delays caused by IRQ latency won't confuse the algorithm unless they
are ridiculously long (over 250 ms); they will merely reduce how far
into the future new transfers can be scheduled. A few people have
reported problems caused by delays of 50 ms or so. Now instead of
failing completely, isochronous transfers will experience a brief
glitch and then continue normally.(Whether this is truly a good thing is debatable. A latency as large
as 50 ms generally indicates a bug is present, and complete failure of
audio or video transfers draws people's attention pretty vividly.
Making the transfers more robust also makes it easier for such bugs to
remain undetected.)Finally, ehci->next_frame is renamed to ehci->last_iso_frame, because
that better describes what it is: the last frame to have been scanned
for isochronous completions.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman
17 Jul, 2012
5 commits
-
This patch (as1587) simplifies ehci-hcd's scan_isoc() routine by
eliminating some local variables, declaring boolean-valued values as
bool rather than unsigned, changing variable names to make more sense,
and so on.The logic at the end of the routine is cut down significantly. The
scanning doesn't have to catch up all the way to where the hardware
is; it merely has to catch up to where the hardware was when the last
interrupt occurred. If the hardware has made more progress since then
and issued another interrupt, a rescan will catch up to it.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
This patch (as1586) replaces the kernel timer used by ehci-hcd as an
I/O watchdog with an hrtimer event.Unlike in the current code, the watchdog event is now always enabled
whenever any isochronous URBs are active. This will prevent bugs
caused by the periodic schedule wrapping around with no completion
interrupts; the watchdog handler is guaranteed to scan the isochronous
transfers at least once during each iteration of the schedule. The
extra overhead will be negligible: one timer interrupt every 100 ms.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
This patch (as1585) fixes a bug in ehci-hcd's scheme for scanning
interrupt QHs.Currently a single routine takes care of scanning everything on the
periodic schedule. Whenever an interrupt occurs, it scans all
isochronous and interrupt URBs scheduled for frames that have elapsed
since the last scan.This has two disadvantages. The first is relatively minor: An
interrupt QH is likely to end up getting scanned multiple times,
particularly if the last scan was not fairly recent. (The current
code avoids this by maintaining a periodic_stamp in each interrupt
QH.)The second is more serious. The periodic schedule wraps around. If
the last scan occurred during frame N, and the next scan occurs when
the schedule has gone through an entire cycle and is back at frame N,
the scanning code won't look at any frames other than N. Consequently
it won't see any QHs that completed during frame N-1 or earlier.The patch replaces the entire frame-based approach for scanning
interrupt QHs with a new routine using a list-based approach, the same
as for async QHs. This has a slight disadvantage, because it means
that all interrupt QHs have to be scanned every time. But it is more
robust than the current approach.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
This patch (as1580) makes ehci_iso_stream structures behave more like
QHs, in that they will remain allocated until their isochronous
endpoint is disabled. This will come in useful in the future, when
periodic bandwidth gets allocated as an altsetting is installed rather
than on-the-fly.For now, the change to the ehci_iso_stream lifetimes means that each
structure is always deallocated at exactly one spot in
ehci_endpoint_disable() and never used again. As a result, it is no
longer necessary to use reference counting on these things, and the
patch removes it.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
This patch (as1579) adds an hrtimer event to handle deallocation of
iTDs and siTDs in ehci-hcd.Because of the frame-oriented approach used by the EHCI periodic
schedule, the hardware can continue to access the Transfer Descriptor
for isochronous (or split-isochronous) transactions for up to a
millisecond after the transaction completes. The iTD (or siTD) must
not be reused before then.The strategy currently used involves putting completed iTDs on a list
of cached entries and every so often returning them to the endpoint's
free list. The new strategy reduces overhead by putting completed
iTDs back on the free list immediately, although they are not reused
until it is safe to do so.When the isochronous endpoint stops (its queue becomes empty), the
iTDs on its free list get moved to a global list, from which they will
be deallocated after a minimum of 2 ms. This delay is what the new
hrtimer event is for.Overall this may not be a tremendous improvement over the current
code, but to me it seems a lot more clear and logical. In addition,
it removes the need for each iTD to keep a reference to the
ehci_iso_stream it belongs to, since the iTD never needs to be moved
back to the stream's free list from the global list.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman