Sometimes disable_periodic() stop scan_periodic before than free_cached_itd_list() was called.
In such case USB Host stacked during disconnect operation
Solution: add call of free_cached_itd_list() function in disable_periodic()
Signed-off-by: NDimitry Epshtein <dima@marvell.com>
Signed-off-by: NSaeed Bishara <saeed@marvell.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The EHCI specification says that an EHCI host controller may cache part of
the isochronous schedule.  The EHCI controller must advertise how much it
caches in the schedule through the HCCPARAMS register isochronous
scheduling threshold (IST) bits.

In theory, adding new iTDs within the IST should be harmless.  The HW will
follow the old cached linked list and miss the new iTD.  SW will notice HW
missed the iTD and return 0 for the transfer length.

However, Intel ICH9 chipsets (and some later chipsets) have issues when SW
attempts to schedule a split transaction within the IST.  All transfers
will cease being sent out that port, and the drivers will see isochronous
packets complete with a length of zero.  Start of frames may or may not
also disappear, causing the device to go into auto-suspend.  This "bus
stall" will continue until a control or bulk transfer is queued to a
device under that roothub.

Most drivers will never cause this behavior, because they use multiple
URBs with multiple packets to keep the bus busy.  If you limit the number
of URBs to one, you may be able to hit this bug.

Make sure the EHCI driver does not schedule full-speed transfers within
the IST under an Intel chipset.  Make sure that when we fall behind the
current microframe plus IST, we schedule the new transfer at the next
periodic interval after the IST.

Don't change the scheduling for new transfers, since the schedule slop will
always be greater than the IST.  Allow high speed isochronous transfers to
be scheduled within the IST, since this doesn't trigger the Intel chipset
bug.

Make sure that if the host caches the full frame, the EHCI driver's
internal isochronous threshold (ehci->i_thresh) is set to
8 microframes + 2 microframes wiggle room.  This is similar to what is done in
the case where the host caches less than the full frame.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Change the constant SCHEDULE_SLOP to be 80 microframes, instead of 10
frames.  It was always multiplied by 8 to convert frames to microframes.
SCHEDULE_SLOP is only used in ehci-sched.c.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

a quirky chipset needs periodic schedules to run for a minimum
time before they can be disabled again. This enforces the requirement
with a time stamp and a calculated delay
Signed-off-by: NOliver Neukum <oliver@neukum.org>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When the EHCI driver falls behind in its scheduling, the active stream's
first empty microframe may be in the past with respect to the current
microframe.  The code attempts to move the starting microframe ("start") N
number of microframes forward, where N is the interval of endpoint.
However, stream->interval is a copy of the endpoint's bInterval, which is
designated in frames for FS devices, and microframes for HS devices.
Convert stream->interval to microframes before using it to move the
starting microframe forward.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The EHCI driver does some bounds checking when it's scheduling an iTD for
an active endpoint.  It sets the local variable start to
stream->next_uframe and moves that variable further in the schedule if
necessary.  However, the driver fails to do anything with start before
jumping to the ready label and setting the URB's starting frame to
stream->next_uframe.  Alan Stern confirms the EHCI driver should set
stream->next_uframe to start before jumping.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1281) changes the way ehci-hcd deschedules interrupt
QHs, copying the approach used for async QHs.  The caller is no longer
responsible for rescheduling the QH if its queue is non-empty; instead
the reschedule is done directly by intr_deschedule(), after calling
qh_completions().  This is exactly the same as how end_unlink_async()
works.

ehci_urb_dequeue() and intr_deschedule() now correctly handle the case
where they are called while another interrupt URB for the same QH is
being given back.  This was a surprisingly large blind spot.  And
scan_periodic() now respects the new needs_rescan flag.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: David Brownell <david-b@pacbell.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The ehci_qh structure merged hw and sw together which is not good:
1. More and more items are being added into ehci_qh, the ehci_qh software
   part are unnecessary to be allocated in DMA qh_pool.
2. If HCD has local SRAM, the sw part will consume it too, and it won't
   bring any benefit.
3. For non-cache-coherence system, the entire ehci_qh is uncachable, actually
   we only need the hw part to be uncacheable. Spliting them will let the sw
   part to be cacheable.
Signed-off-by: NAlek Du <alek.du@intel.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1274) simplifies the counting of transaction-error
retries.  Now we will count up from 0 to QH_XACTERR_MAX instead of
down from QH_XACTERR_MAX to 0.

The patch also fixes a small bug: qh->xacterr was not getting
initialized for interrupt endpoints.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NMatthijs Kooijman <matthijs@stdin.nl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1259b) makes ehci-hcd return the total number of bytes
transferred in urb->actual_length for Isochronous transfers.
Until now, the actual_length value was unaccountably left at 0.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1243) tries to improve ehci-hcd's scheduling of
interrupt transfers.  Instead of trying to cram all transfers with the
same period into the same frame, the new code will spread the
transfers out among lots of different frames.  This should reduce the
periodic schedule load in any one frame -- some host controllers have
trouble when there's too much work to do.

A more thorough approach would stagger the uframe values as well.  But
this is enough to make a big improvement.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NDwayne Fontenot <dwayne.fontenot@att.net>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Without this patch, the driver won't check that the last fully-occupied
uframe for a new split transaction was vacant beforehand.  This can
lead to a situation in which the first 188 bytes of a 192-byte
isochronous transfer are scheduled in the same uframe as an existing
interrupt transfer.  The resulting schedule looks like this:

       uframe 0: 188-byte isoc-OUT SSPLIT, 8-byte int-IN SSPLIT
       uframe 1: 4-byte isoc-OUT SSPLIT

The SSPLITs are intermingled, causing an error in the downstream hub's
TT.

If you are having problems with devices or hub ports resetting, or failed
interrupt transfers, when you start using a USB audio or video (Isochronous)
device, this patch may help.
Signed-off-by: NDan Streetman <ddstreet@ieee.org>
Reported-by: NKung James <kong1191@gmail.com>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: Alan Stern <stern@rowland.harvard.edu>

The base versions handle constant folding now.
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

ehci-hcd uses usb_get_urb() and usb_put_urb() in an unbalanced way causing
isochronous URB's kref.counts incrementing once per usb_submit_urb() call.
The culprit is *usb being set to NULL when usb_put_urb() is called after URB
is given back.
Due to other fixes there is no need for ehci-hcd to deal with usb_get_urb()
nor usb_put_urb() anymore, so patch removes their usages in ehci-hcd.
Patch also makes ehci_to_hcd(ehci)->self.bandwidth_allocated adjust, if a
stream finishes.
Signed-off-by: NKarsten Wiese <fzu@wemgehoertderstaat.de>
Cc: David Brownell <david-b@pacbell.net>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Currently ITDs are immediately recycled whenever their URB completes.
However, EHCI hardware can sometimes remember some ITD state.  This
means that when the ITD is reused before end-of-frame it may sometimes
cause the hardware to reference bogus state.

This patch defers reusing such ITDs by moving them into a new ehci member
cached_itd_list. ITDs resting in cached_itd_list are moved back into their
stream's free_list once scan_periodic() detects that the active frame has
elapsed.

This makes the snd_usb_us122l driver (in kernel since .28) work right
when it's hooked up through EHCI.

[ dbrownell@users.sourceforge.net: comment fixups ]
Signed-off-by: NKarsten Wiese <fzu@wemgehoertderstaat.de>
Tested-by: NPhilippe Carriere <philippe-f.carriere@wanadoo.fr>
Tested-by: NFederico Briata <federicobriata@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1164) fixes a bug in the EHCI scheduler.  The interval
value it uses is already in linear format, not logarithmically coded.
The existing code can sometimes crash the system by trying to divide
by zero.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <david-b@pacbell.net>
Cc: Stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

As noted by Stefan Neis <Stefan.Neis@kobil.com>, we had a recent
regression with EHCI periodic transfers, in some (seemingly not
all that common) cases.

The root cause was that the schedule activation was only loosely
coupled to the addition or removal of transfers, so two different
execution contexts could both think they had to deactivate (or
conversely activate) the schedule.  So this fix tightens that
coupling, managing it more like a refcount.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1098) changes the way ehci-hcd schedules its periodic
Iso transfers.  That the current scheduling code is wrong is clear on
the face of it: Sometimes it returns -EL2NSYNC (meaning that an URB
couldn't be scheduled because it was submitted too late), but it does
this even when the URB_ISO_ASAP flag is set (meaning the URB should be
scheduled as soon as possible).

The new code properly implements as-soon-as-possible scheduling,
assigning the next unexpired slot as the URB's starting point.  It
also is more careful about checking for Iso URB completion: It doesn't
bother to check for activity during frames that are already over,
and it allows for the possibility that some of the URB's packets may
have raced the hardware when they were submitted and so never got used
(the packet status is set to -EXDEV).

This fixes problems several people have experienced with USB video
applications.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Remove two (or one) conditional tests in per-urb isochronous
transfer setup code paths.
Signed-off-by: NKarsten Wiese <fzu@wemgehoertderstaat.de>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Refactor the EHCI "if (handshake()) state = HC_STATE_HALT" idiom,
which appears 4 times, by replacing it with calls to a new function
called handshake_on_error_set_halt().  Saves a few bytes too.
Signed-off-by: NKarsten Wiese <fzu@wemgehoertderstaat.de>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This has some bugfixes for the EHCI driver's ISO transfer scanning
logic.  It was leaving ITDs and SITDs on the schedule too long, for
a few different reasons, which caused trouble.

  (a)	Look at all microframes for high speed transfers, not just
	the ones we expect to have finished.  This way transfers
	ending mid-frame will complete without needing another IRQ.
	This also minimizes bogus scheduling underruns (e.g. EL2NSYNC).

  (b)	When we encounter an ISO transfer (either speed, but this
	hits mostly at full speed) that's not yet been completed,
	immediately stop scanning; we've caught up to the hardware,
	no matter what other indications might say.

  (c)	Always clean up ITDs (for high speed transfers) when the HC
	is no longer running.

I'm not sure whether the last one has been observed before, but both
the others have been reported with "real world" audio and video code.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Small updates to the EHCI driver's ISO support:

 - Get rid of the Kconfig option for full speed ISO.  It may
   not be perfect yet, but it hasn't appeared to be dangerous
   and pretty much every configuration wants it.

 - Instead of two places to disable an empty periodic schedule
   after an ISO transfer completes, just have one.

 - After the periodic schedule is disabled, we can short-circuit
   the schedule scan ... it can't possibly have more work to do.

Assuming a typical config with split iso enabled, the only change
in behavior should be almost unobservable:  quicker termination
of periodic scans when the schedule gets emptied.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

In the EHCI driver, itd->usecs[8] is used in periodic_usecs(), indexed by
uframe.  For an ITD's unused uframes it is 0, else it contains the same
value as itd->stream->usecs.  To check if an ITD's uframe is used, we can
instead test itd->hw_transaction[uframe]:  if used, it will be nonzero no
matter what endianess is used.

This patch replaces those two uses, eliminates itd->usecs[], and saves
eight bytes from each ITD.
Signed-off-by: NKarsten Wiese <fzu@wemgehoertderstaat.de>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This adds a workaround for an issue reported with ISO transfers
on some EHCI controllers, most recently with VIA KT800 and PS3
EHCI silicon.

The issue is that the silicon doesn't necessarily seem to be done
using ISO DMA descriptors (itd, sitd) when it marks them inactive.
(One theory is that the ill-defined mechanism where hardware caches
periodic transfer descriptors isn't invalidating their state...)
With such silicon, quick re-use of those descriptors makes trouble.
Waiting until the next frame seems to be a sufficient workaround.

This patch ensures that the relevant descriptors aren't available
for immediate re-use.  It does so by not recycling them until after
issuing the completion callback which would reuse them by enqueueing
an URB and thus (re)allocating ISO DMA descriptors.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Acked-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Cc: Masashi Kimoto <Masashi_Kimoto@hq.scei.sony.co.jp>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as974) reorganizes the way ehci-hcd sets urb->status.  It
now keeps the information in a local variable until the last moment.

The patch also simplifies the handling of -EREMOTEIO, since the only
use of that code is to set the do_status flag.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: David Brownell <david-b@pacbell.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as954) implements a suggestion of David Brownell's.  Now
the host controller drivers are responsible for linking and unlinking
URBs to/from their endpoint queues.  This eliminates the possiblity of
strange situations where usbcore thinks an URB is linked but the HCD
thinks it isn't.  It also means HCDs no longer have to check for URBs
being dequeued before they were fully enqueued.

In addition to the core changes, this requires changing every host
controller driver and the root-hub URB handler.  For the most part the
required changes are fairly small; drivers have to call
usb_hcd_link_urb_to_ep() in their urb_enqueue method,
usb_hcd_check_unlink_urb() in their urb_dequeue method, and
usb_hcd_unlink_urb_from_ep() before giving URBs back.  A few HCDs make
matters more complicated by the way they split up the flow of control.

In addition some method interfaces get changed.  The endpoint argument
for urb_enqueue is now redundant so it is removed.  The unlink status
is required by usb_hcd_check_unlink_urb(), so it has been added to
urb_dequeue.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: David Brownell <david-b@pacbell.net>
CC: Olav Kongas <ok@artecdesign.ee>
CC: Tony Olech <tony.olech@elandigitalsystems.com>
CC: Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This reverts commit 196705c9.  It was
reported to cause a regression by Daniel Exner, and Arjan van de Ven
points out that we actually already have infrastructure in place for
setting limits on acceptable DMA latency that would be the much more
correct fix for the problem with some Broadcom EHCI controllers.

Fixed up trivial conflicts due to the changes to support big-endian host
controller descriptors in drivers/usb/host/{ehci-sched.c,ehci.h}.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch implements supports for EHCI controllers whose in-memory
data structures are represented in big-endian format. This is needed
(unfortunately) for the AMCC PPC440EPx SoC EHCI controller; the EHCI
spec doesn't specify little-endian format, although that's what most
other implementations use.

The guts of the patch are to introduce the hc32 type and change all
references from le32 to hc32.  All access routines are converted from
cpu_to_le32(...) to cpu_to_hc32(ehci, ...) and similar for the other
"direction".  (This is the same approach used with OHCI.)

David fixed:
	Whitespace fixes; refresh against ehci cpufreq patch; move glue
	for that PPC driver to the patch adding it; fix free symbol
	capture bugs in modified "constant" macros; and make "hc32" etc
	be "le32" unless we really need the BE options, so "sparse" can
	do some real good.
Signed-off-by: NStefan Roese <sr@denx.de>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

EHCI controllers that don't cache enough microframes can get MMF errors
when CPU frequency changes occur between the start and completion of
split interrupt transactions, due to delays in reading main memory
(caused by CPU cache snoop delays).

This patch adds a cpufreq notifier to the EHCI driver that will
inactivate split interrupt transactions during frequency transitions.
It was tested on Intel ICH7 and Serverworks/Broadcom HT1000 EHCI
controllers.
Signed-off-by: NStuart Hayes <stuart_hayes@dell.com>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch implements supports for EHCI controllers whose MMIO
registers are big endian and enables that functionality for
the Toshiba SCC chip. It does _not_ add support for big endian
in-memory data structures as this is not needed for that chip
and I hope it will never be.

The guts of the patch are to convert readl(...) to
ehci_readl(ehci, ...) and similarly for register writes.
Signed-off-by: NKou Ishizaki <kou.ishizaki@toshiba.co.jp>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
of passing regs around manually through all ~1800 interrupt handlers in the
Linux kernel.

The regs pointer is used in few places, but it potentially costs both stack
space and code to pass it around.  On the FRV arch, removing the regs parameter
from all the genirq function results in a 20% speed up of the IRQ exit path
(ie: from leaving timer_interrupt() to leaving do_IRQ()).

Where appropriate, an arch may override the generic storage facility and do
something different with the variable.  On FRV, for instance, the address is
maintained in GR28 at all times inside the kernel as part of general exception
handling.

Having looked over the code, it appears that the parameter may be handed down
through up to twenty or so layers of functions.  Consider a USB character
device attached to a USB hub, attached to a USB controller that posts its
interrupts through a cascaded auxiliary interrupt controller.  A character
device driver may want to pass regs to the sysrq handler through the input
layer which adds another few layers of parameter passing.

I've build this code with allyesconfig for x86_64 and i386.  I've runtested the
main part of the code on FRV and i386, though I can't test most of the drivers.
I've also done partial conversion for powerpc and MIPS - these at least compile
with minimal configurations.

This will affect all archs.  Mostly the changes should be relatively easy.
Take do_IRQ(), store the regs pointer at the beginning, saving the old one:

	struct pt_regs *old_regs = set_irq_regs(regs);

And put the old one back at the end:

	set_irq_regs(old_regs);

Don't pass regs through to generic_handle_irq() or __do_IRQ().

In timer_interrupt(), this sort of change will be necessary:

	-	update_process_times(user_mode(regs));
	-	profile_tick(CPU_PROFILING, regs);
	+	update_process_times(user_mode(get_irq_regs()));
	+	profile_tick(CPU_PROFILING);

I'd like to move update_process_times()'s use of get_irq_regs() into itself,
except that i386, alone of the archs, uses something other than user_mode().

Some notes on the interrupt handling in the drivers:

 (*) input_dev() is now gone entirely.  The regs pointer is no longer stored in
     the input_dev struct.

 (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking.  It does
     something different depending on whether it's been supplied with a regs
     pointer or not.

 (*) Various IRQ handler function pointers have been moved to type
     irq_handler_t.
Signed-Off-By: NDavid Howells <dhowells@redhat.com>
(cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)

[ ... when you have an editor set to remind you of whitespace bugs ... ]

Cosmetic EHCI changes: remove end-of-line whitespace, spaces before tabs.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This updates the EHCI driver by adding an improved scheduler for the
transaction translators, found in USB 2.0 hubs and used for low and
full speed devices.

 - adds periodic_tt_usecs() and some helper functions, which does
   the same thing that "periodic_usecs" does, except on the other
   side of the TT, i.e.  it calculates the low/fullspeed bandwidth
   usage instead of highspeed.

 - adds a tt_available() function which is the new implementation
   of what tt_no_collision() does ... while tt_no_collision() ensures
   that each TT handles only 1 periodic transfer at a time (a very
   pessimistic approach) this version instead tracks bandwidth and
   allows each TT to handle as many transfers as will fit on each TT's
   downstream bus (closer to best-case).

The new scheduler is selected by a config option, marked as EXPERIMENTAL
so it can be tested (and more broadly reviewed) for a while until it
seems safe to remove the original scheduler.
Signed-off-by: NDan Streetman <ddstreet@ieee.org>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NEric Sesterhenn <snakebyte@gmx.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as640) removes several put_device and the corresponding
get_device calls from the USB core and HCDs.  Some of the puts were done
in atomic contexts, and none of them are needed since the core now
guarantees that every endpoint will be disabled and every URB completed
before a USB device is released.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NDavid Brownell <david-b@pacbell.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch replaces the split ISO raw_mask calculation code in the
iso_stream_init() function that computed incorrect numbers of high
speed transactions for both input and output transfers.

In the output case, it added a superfluous start-split transaction for
all maxmimum packet sizes that are a multiple of 188.

In the input case, it forgot to add complete-split transactions for all
microframes covered by the full speed transaction, and the additional
complete-split transaction needed for the case when full speed data
starts arriving near the end of a microframe.

These changes don't affect the lack of full speed bandwidth, but at
least it removes the MMF errors that the HC raised with some input
streams.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix sparse warning:
drivers/usb/host/ehci-hcd.c:719:35: warning: incorrect type in argument 3 (different base types)
drivers/usb/host/ehci-hcd.c:719:35:    expected unsigned int [unsigned] mem_flags
drivers/usb/host/ehci-hcd.c:719:35:    got restricted unsigned int [usertype] mem_flags
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch adds a reinitializion for the uf variable that got modified
by the preceding start-split bandwidth check.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>