The current TT scheduling doesn't allow to play and then record on a
full-speed device connected to a high speed hub.

The IN iso stream can only start on the first uframe (0-2 for a 165 us)
because of CSPLIT transactions.
For the OUT iso stream there no such restriction. uframe 0-5 are possible.

The idea of this patch is that the first uframe are precious (for IN TT iso
stream) and we should allocate the last uframes first if possible.

For that we reverse the order of uframe allocation (last uframe first).

Here an example :

hid interrupt stream
----------------------------------------------------------------------
uframe                |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
----------------------------------------------------------------------
max_tt_usecs          | 125 | 125 | 125 | 125 | 125 | 125 | 30  |  0  |
----------------------------------------------------------------------
used usecs on a frame | 13  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
----------------------------------------------------------------------

iso OUT stream
----------------------------------------------------------------------
uframe                |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
----------------------------------------------------------------------
max_tt_usecs          | 125 | 125 | 125 | 125 | 125 | 125 | 30  |  0  |
----------------------------------------------------------------------
used usecs on a frame | 13  | 125 |  39 |  0  |  0  |  0  |  0  |  0  |
----------------------------------------------------------------------

There no place for iso IN stream  (uframe 0-2 are used) and we got "cannot
submit datapipe for urb 0, error -28: not enough bandwidth" error.

With the patch this become.

iso OUT stream
----------------------------------------------------------------------
uframe                |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
----------------------------------------------------------------------
max_tt_usecs          | 125 | 125 | 125 | 125 | 125 | 125 | 30  |  0  |
----------------------------------------------------------------------
used usecs on a frame |  13 |  0  |  0  |  0  | 125 |  39 |  0  |  0  |
----------------------------------------------------------------------

iso IN stream
----------------------------------------------------------------------
uframe                |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
----------------------------------------------------------------------
max_tt_usecs          | 125 | 125 | 125 | 125 | 125 | 125 | 30  |  0  |
----------------------------------------------------------------------
used usecs on a frame |  13 |  0  | 125 | 40  | 125 |  39 |  0  |  0  |
----------------------------------------------------------------------
Signed-off-by: NMatthieu Castet <matthieu.castet@parrot.com>
Signed-off-by: NThomas Poussevin <thomas.poussevin@parrot.com>
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1489) works around a hardware bug in MosChip EHCI
controllers.  Evidently when one of these controllers increments the
frame-index register, it changes the three low-order bits (the
microframe counter) before changing the higher order bits (the frame
counter).  If the register is read at just the wrong time, the value
obtained is too low by 8.

When the appropriate quirk flag is set, we work around this problem by
reading the frame-index register a second time if the first value's
three low-order bits are all 0.  This gives the hardware a chance to
finish updating the register, yielding the correct value.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NJason N Pitt <jpitt@fhcrc.org>
CC: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1483) improves the ehci-hcd driver family by getting rid
of the reliance on the hcd->state variable.  It has no clear owner and
it isn't protected by the usual HCD locks.  In its place, the patch
adds a new, private ehci->rh_state field to record the state of the
root hub.

Along the way, the patch removes a couple of lines containing
redundant assignments to the state variable.  Also, the QUIESCING
state simply gets changed to the RUNNING state, because the driver
doesn't make any distinction between them.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There are cases, when 80% max isochronous bandwidth is too limiting.

For example I have two USB video capture cards which stream uncompressed
video, and to stream full NTSC + PAL videos we'd need

    NTSC 640x480 YUV422 @30fps      ~17.6 MB/s
    PAL  720x576 YUV422 @25fps      ~19.7 MB/s

isoc bandwidth.

Now, due to limited alt settings in capture devices NTSC one ends up
streaming with max_pkt_size=2688  and  PAL with max_pkt_size=2892, both
with interval=1. In terms of microframe time allocation this gives

    NTSC    ~53us
    PAL     ~57us

and together

    ~110us  >  100us == 80% of 125us uframe time.

So those two devices can't work together simultaneously because the'd
over allocate isochronous bandwidth.

80% seemed a bit arbitrary to me, and I've tried to raise it to 90% and
both devices started to work together, so I though sometimes it would be
a good idea for users to override hardcoded default of max 80% isoc
bandwidth.

After all, isn't it a user who should decide how to load the bus? If I
can live with 10% or even 5% bulk bandwidth that should be ok. I'm a USB
newcomer, but that 80% set in stone by USB 2.0 specification seems to be
chosen pretty arbitrary to me, just to serve as a reasonable default.

NOTE 1
~~~~~~

for two streams with max_pkt_size=3072 (worst case) both time
allocation would be 60us+60us=120us which is 96% periodic bandwidth
leaving 4% for bulk and control.  Alan Stern suggested that bulk then
would be problematic (less than 300*8 bittimes left per microframe), but
I think that is still enough for control traffic.

NOTE 2
~~~~~~

Sarah Sharp expressed concern that maxing out periodic bandwidth
could lead to vendor-specific hardware bugs on host controllers, because

> It's entirely possible that you'll run into
> vendor-specific bugs if you try to pack the schedule with isochronous
> transfers.  I don't think any hardware designer would seriously test or
> validate their hardware with a schedule that is basically a violation of
> the USB bus spec (more than 80% for periodic transfers).

So far I've only tested this patch on my HP Mini 5103 with N10 chipset

    kirr@mini:~$ lspci
    00:00.0 Host bridge: Intel Corporation N10 Family DMI Bridge
    00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated Graphics Controller
    00:02.1 Display controller: Intel Corporation N10 Family Integrated Graphics Controller
    00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02)
    00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02)
    00:1c.3 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 4 (rev 02)
    00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02)
    00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02)
    00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02)
    00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02)
    00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02)
    00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
    00:1f.0 ISA bridge: Intel Corporation NM10 Family LPC Controller (rev 02)
    00:1f.2 SATA controller: Intel Corporation N10/ICH7 Family SATA AHCI Controller (rev 02)
    01:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01)
    02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8059 PCI-E Gigabit Ethernet Controller (rev 11)

and the system works stable with 110us/uframe (~88%) isoc bandwith allocated for
above-mentioned isochronous transfers.

NOTE 3
~~~~~~

This feature is off by default. I mean max periodic bandwidth is set to
100us/uframe by default exactly as it was before the patch. So only those of us
who need the extreme settings are taking the risk - normal users who do not
alter uframe_periodic_max sysfs attribute should not see any change at all.

NOTE 4
~~~~~~

I've tried to update documentation in Documentation/ABI/ thoroughly, but
only "TBD" was put into Documentation/usb/ehci.txt -- the text there seems
to be outdated and much needing refreshing, before it could be amended.

Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NKirill Smelkov <kirr@mns.spb.ru>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1467) removes the last usages of hcd->state from
usbcore.  We no longer check to see if an interrupt handler finds that
a controller has died; instead we rely on host controller drivers to
make an explicit call to usb_hc_died().

This fixes a regression introduced by commit
9b37596a (USB: move usbcore away from
hcd->state).  It used to be that when a controller shared an IRQ with
another device and an interrupt arrived while hcd->state was set to
HC_STATE_HALT, the interrupt handler would be skipped.  The commit
removed that test; as a result the current code doesn't skip calling
the handler and ends up believing the controller has died, even though
it's only temporarily stopped.  The solution is to ignore HC_STATE_HALT
following the handler's return.

As a consequence of this change, several of the host controller
drivers need to be modified.  They can no longer implicitly rely on
usbcore realizing that a controller has died because of hcd->state.
The patch adds calls to usb_hc_died() in the appropriate places.

The patch also changes a few of the interrupt handlers.  They don't
expect to be called when hcd->state is equal to HC_STATE_HALT, even if
the controller is still alive.  Early returns were added to avoid any
confusion.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NManuel Lauss <manuel.lauss@googlemail.com>
CC: Rodolfo Giometti <giometti@linux.it>
CC: Olav Kongas <ok@artecdesign.ee>
CC: <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1466) speeds up processing of ehci-hcd's periodic list.
The existing code will pointlessly rescan an interrupt endpoint queue
each time it encounters the queue's QH in the periodic list, which can
happen quite a few times if the endpoint's period is low.  On some
embedded systems, this useless overhead can waste so much time that
the driver falls hopelessly behind and loses events.

The patch introduces a "periodic_stamp" variable, which gets
incremented each time scan_periodic() runs and each time the scan
advances to a new frame.  If the corresponding stamp in an interrupt
QH is equal to the current periodic_stamp, we assume the QH has
already been scanned and skip over it.  Otherwise we scan the QH as
usual, and if none of its URBs have completed then we store the
current periodic_stamp in the QH's stamp, preventing it from being
scanned again.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch moves the AMD PLL quirk code in OHCI/EHCI driver to pci-quirks.c,
and exports the functions to be used by xHCI driver later.

AMD PLL quirk disable the optional PM feature inside specific
SB700/SB800/Hudson-2/3 platforms under the following conditions:

1. If an isochronous device is connected to OHCI/EHCI/xHCI port and is active;
2. Optional PM feature that powers down the internal Bus PLL when the link is
   in low power state is enabled.

Without AMD PLL quirk, USB isochronous stream may stutter or have breaks
occasionally, which greatly impair the performance of audio/video streams.

Currently AMD PLL quirk is implemented in OHCI and EHCI driver, and will be
added to xHCI driver too. They are doing similar things actually, so move
the quirk code to pci-quirks.c, which has several advantages:

1. Remove duplicate defines and functions in OHCI/EHCI (and xHCI) driver and
   make them cleaner;
2. AMD chipset information will be probed only once and then stored.
   Currently they're probed during every OHCI/EHCI initialization, move
   the detect code to pci-quirks.c saves the repeat detect cost;
3. Build up synchronization among OHCI/EHCI/xHCI driver. In current
   code, every host controller enable/disable PLL only according to
   its own status, and may enable PLL while there is still isoc transfer on
   other HCs. Move the quirk to pci-quirks.c prevents this issue.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alex He <alex.he@amd.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This reverts commit b7d5b439.
It conflicts with commit baab93af "USB:
EHCI: ASPM quirk of ISOC on AMD Hudson" and merging the two just doesn't
work properly.

Cc: Andiry Xu <andiry.xu@amd.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alex He <alex.he@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The pre-release GCC-4.6 now correctly flags this code as dead.
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch moves the AMD PLL quirk code in OHCI/EHCI driver to pci-quirks.c,
and exports the functions to be used by xHCI driver later.

AMD PLL quirk disable the optional PM feature inside specific
SB700/SB800/Hudson-2/3 platforms under the following conditions:

1. If an isochronous device is connected to OHCI/EHCI/xHCI port and is active;
2. Optional PM feature that powers down the internal Bus PLL when the link is
   in low power state is enabled.

Without AMD PLL quirk, USB isochronous stream may stutter or have breaks
occasionally, which greatly impair the performance of audio/video streams.

Currently AMD PLL quirk is implemented in OHCI and EHCI driver, and will be
added to xHCI driver too. They are doing similar things actually, so move
the quirk code to pci-quirks.c, which has several advantages:

1. Remove duplicate defines and functions in OHCI/EHCI (and xHCI) driver and
   make them cleaner;
2. AMD chipset information will be probed only once and then stored.
   Currently they're probed during every OHCI/EHCI initialization, move
   the detect code to pci-quirks.c saves the repeat detect cost;
3. Build up synchronization among OHCI/EHCI/xHCI driver. In current
   code, every host controller enable/disable PLL only according to
   its own status, and may enable PLL while there is still isoc transfer on
   other HCs. Move the quirk to pci-quirks.c prevents this issue.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alex He <alex.he@amd.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When ASPM PM Feature is enabled on UMI link, devices that use ISOC stream of
data transfer may be exposed to longer latency causing less than optimal per-
formance of the device. The longer latencies are normal and are due to link
wake time coming out of low power state which happens frequently to save
power when the link is not active.
The following code will make exception for certain features of ASPM to be by
passed and keep the logic normal state only when the ISOC device is connected
and active. This change will allow the device to run at optimal performance
yet minimize the impact on overall power savings.
Signed-off-by: NAlex He <alex.he@amd.com>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

On AMD SB700/SB800/Hudson-2/3 platforms, USB EHCI controller may read/write
to memory space not allocated to USB controller if there is longer than
normal latency on DMA read encountered. In this condition the exposure will
be encountered only if the driver has following format of Periodic Frame
List link pointer structure:

For any idle periodic schedule, the Frame List link pointers that have the
T-bit set to 1 intending to terminate the use of frame list link pointer
as a physical memory pointer.

Idle periodic schedule Frame List Link pointer shoule be in the following
format to avoid the issue:

Frame list link pointer should be always contains a valid pointer to a
inactive QHead with T-bit set to 0.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1409) removes some dead code from the ehci-hcd
scheduler.  Thanks to the previous patch in this series, stream->depth
is no longer used.  And stream->start and stream->rescheduled
apparently have not been used for quite a while, except in some
statistics-reporting code that never gets invoked.
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 (as1408) rearranges the scheduling code in ehci-hcd, partly
to improve its structure, but mainly to change the way it works.
Whether or not a transfer exceeds the hardware schedule length will
now be determined by looking at the last frame the transfer would use,
instead of the first available frame following the end of the transfer.

The benefit of this change is that it allows the driver to accept
valid URBs which would otherwise be rejected.  For example, suppose
the schedule length is 1024 frames, the endpoint period is 256 frames,
and a four-packet URB is submitted.  The four transfers would occupy
slots that are 0, 256, 512, and 768 frames past the current frame
(plus an extra slop factor).  These don't exceed the 1024-frame limit,
so the URB should be accepted.  But the current code notices that the
next available slot would be 1024 frames (plus slop) in the future,
which is beyond the limit, and so the URB is rejected unnecessarily.
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 (as1407) fixes a bug in ehci-hcd's isochronous scheduler.
All its calculations should be done in terms of microframes, but for
full-speed devices, sched->span is stored in frames.  It needs to be
converted.

This fix is liable to expose problems in other drivers.  The old code
would accept URBs that should not have been accepted, so drivers have
had no reason to avoid submitting URBs that exceeded the maximum
schedule length.  In an attempt to partially compensate for this, the
patch also adjusts the schedule length from a minimum of 256 frames up
to a minimum of 512 frames.
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 (as1406) adds a micro-optimization to ehci-hcd's scheduling
code.  Instead of computing remainders with respect to the schedule
length, use bitwise-and (which is quicker).  We know that the schedule
length will always be a power of two, but the compiler doesn't have
this information.
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 (as1405) fixes a small bug in ehci-hcd's isochronous
scheduler.  Not all EHCI controllers are PCI, and the code shouldn't
assume that they are.  Instead, introduce a special flag for
controllers which need to delay iso scheduling for full-speed devices
beyond the scheduling threshold.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
CC: David Brownell <david-b@pacbell.net>
CC: stable <stable@kernel.org>
Acked-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

This patch (as1393) converts several of the single-bit fields in
struct usb_hcd to atomic flags.  This is for safety's sake; not all
CPUs can update bitfield values atomically, and these flags are used
in multiple contexts.

The flag fields that are set only during registration or removal can
remain as they are, since non-atomic accesses at those times will not
cause any problems.

(Strictly speaking, the authorized_default flag should become atomic
as well.  I didn't bother with it because it gets changed only via
sysfs.  It can be done later, if anyone wants.)
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1369) fixes a problem in ehci-hcd.  Some controllers
occasionally run into trouble when the driver reclaims siTDs too
quickly.  This can happen while streaming audio; it causes the
controller to crash.

The patch changes siTD reclamation to work the same way as iTD
reclamation: Completed siTDs are stored on a list and not reused until
at least one frame has passed.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NNate Case <ncase@xes-inc.com>
CC: <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The EHCI driver stores in usb_host_endpoint.hcpriv a pointer to either
an ehci_qh or an ehci_iso_stream structure, and uses the contents of the
hw_info1 field to distinguish the two cases.

After ehci_qh was split into hw and sw parts, ehci_iso_stream must also
be adjusted so that it again looks like an ehci_qh structure.

This fixes a NULL pointer access in ehci_endpoint_disable() when it
tries to access qh->hw->hw_info1.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Reported-by: NColin Fletcher <colin.m.fletcher@googlemail.com>
Cc: stable <stable@kernel.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When isochronous URBs are shorter than one frame and when more than one
ITD in a frame has been completed before the interrupt can be handled,
scan_periodic() completes the URBs in the order in which they are found
in the descriptor list.  Therefore, the descriptor list must contain the
ITDs in the correct order, i.e., a new ITD must be linked in after any
previous ITDs of the same endpoint.

This should fix garbled capture data in the USB audio drivers.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Reported-by: NColin Fletcher <colin.m.fletcher@googlemail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch fix audio record functionality for some Full speed sound blaster devices.
Issue: Sometimes transaction complete indication is coming from HW one frame later.
Solution: If scan_periodic process now frame or previous frame now-1 and sitd transaction
is not finished yet, exit scan_periodic function and check the same transaction in the next frame.
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>

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>