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: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1577) adds hrtimer support for unlinking interrupt QHs
in ehci-hcd.  The current code relies on a fixed delay of either 2 or
55 us, which is not always adequate and in any case is totally bogus.
Thanks to internal caching, the EHCI hardware may continue to access
an interrupt QH for more than a millisecond after it has been unlinked.

In fact, the EHCI spec doesn't say how long to wait before using an
unlinked interrupt QH.  The patch sets the delay to 9 microframes
minimum, which ought to be adequate.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1574) changes the return type of multiple functions in
ehci-sched.c from int to void.  The values they return are now always
0, so there's no reason for them to return any value at all.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1573) adds hrtimer support for managing ehci-hcd's
periodic schedule.  There are two issues to deal with.

First, the schedule's state (on or off) must not be changed until the
hardware status has caught up with the current command.  This is
handled by an hrtimer event that polls at 1-ms intervals to see when
the Periodic Schedule Status (PSS) flag matches the Periodic Schedule
Enable (PSE) value.

Second, the schedule should not be turned off as soon as it becomes
empty.  Turning the schedule on and off takes time, so we want to wait
until the schedule has been empty for a suitable period before turning
it off.  This is handled by an hrtimer event that gets set to expire
10 ms after the periodic schedule becomes empty.

The existing code polls (for up to 1125 us and with interrupts
disabled!) to check the status, and doesn't implement a delay before
turning off the schedule.  Furthermore, if the polling fails then the
driver decides that the controller has died.  This has caused problems
for several people; some controllers can take 10 ms or more to turn
off their periodic schedules.

This patch fixes these issues.  It also makes the "broken_periodic"
workaround unnecessary; there is no longer any danger of turning off
the periodic schedule after it has been on for less than 1 ms.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1571) adds a new state for ehci-hcd's root hubs:
EHCI_RH_STOPPING.  This value is used at times when the root hub is
being stopped and we don't know whether or not the hardware has
finished all its DMA yet.

Although the purpose may not be apparent, this distinction will come
in useful later on.  Future patches will avoid actions that depend on
the root hub being operational (like turning on the async or periodic
schedules) when they see the state is EHCI_RH_STOPPING.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1567) removes ehci-hcd's reference counting of QH
structures.  It's not necessary to refcount these things because they
always get deallocated at exactly one spot in ehci_endpoint_disable()
(except for two special QHs, ehci->async and ehci->dummy) and are
never used again.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1555) improves the code ehci-hcd uses while checking the
periodic schedule for isochronous transfers to full-speed devices.  In
addition to making sure that a new transfer does not violate the
restrictions on the high-speed schedule, it also has to check the
restrictions on the full-speed part of the bus, i.e., the part beyond
the Transaction Translator (TT).

It does this by calling tt_available() (or tt_no_collision() if
CONFIG_USB_EHCI_TT_NEWSCHED isn't enabled).  However it calls that
routine on each pass through a loop over the frames being modified,
which is an unnecessary expense because tt_available() (or
tt_no_collision) already does its own loop over frames.  It is
sufficient to do the check just once, before starting the loop.

In addition, the function calls incorrectly converted the transfer's
period from microframes to frames by doing a left shift instead of a
right shift.  The patch fixes this while moving the calls.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

dbg() was a very old USB-specific macro that should no longer
be used. This patch removes it from being used in the driver
and uses dev_dbg() instead.

CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The ehci-hcd driver is a little haphazard about keeping track of the
state of the USBCMD register.  The ehci->command field is supposed to
hold the register's value (apart from a few special bits) at all
times, but it isn't maintained properly.

This patch (as1543) cleans up the situation.  It keeps ehci->command
up-to-date, and uses that value rather than reading the register from
the hardware whenever possible.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix a regression that was introduced by commit
811c926c (USB: EHCI: fix HUB TT scheduling
issue with iso transfer).

We detect an error if next == start, but this means uframe 0 can't be allocated
anymore for iso transfer...
Reported-by: NSander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: NMatthieu CASTET <castet.matthieu@free.fr>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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>