This patch (as1642) adds an ehci->priv field for private use by EHCI
platform drivers.  The space was provided some time ago, but it didn't
have a name.

Until now none of the platform drivers has used this private space,
but that's about to change in the next patch of this series.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Without this, platform drivers e.g. ehci-omap.c will see a
different version of struct ehci_hcd than ehci-hcd.c and
break reference to 'debug_dir' and 'priv' members when
CONFIG_USB_DEBUG is enabled.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1630) cleans up a few minor items resulting from the
split-up of the ehci-hcd driver:

	Remove the product_desc string from the ehci_driver_overrides
	structure.  All drivers will use the generic "EHCI Host
	Controller" string.  (This was requested by Felipe Balbi.)

	Allow drivers to pass a NULL pointer to ehci_init_driver()
	if they don't have to override any settings.

	Remove a #define symbol that is no longer used from the
	ChipIdea host driver.

	Rename overrides to pci_overrides in ehci-pci.c, for
	consistency with ehci-platform.c.

	Mark the *_overrides structures as __initdata.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1624) prepares ehci-hcd for being split up into a core
library and separate platform driver modules.  A generic
ehci_hc_driver structure is created, containing all the "standard"
values, and a new mechanism is added whereby a driver module can
specify a set of overrides to those values.  In addition the
ehci_setup(), ehci_suspend(), and ehci_resume() routines need to be
EXPORTed for use by the drivers.

As a side effect of this change, a few routines no longer need to be
marked __maybe_unused.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Felipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1622) removes the USB-2.1 Link Power Management code
from the ehci-hcd driver.  This code was never integrated with
usbcore, it is full of bugs, and it was not getting used by anybody.

However, the debugging code for dumping the LPM-related fields in the
EHCI registers is left in place.  In theory it might be useful to see
these values, even though we don't use them.

This essentially amounts to a partial revert of commit
aa4d8342 (USB: EHCI: EHCI 1.1
addendum: preparation) and an almost full revert of commit
48f24970 (USB: EHCI: EHCI 1.1
addendum: Basic LPM feature support) plus its follow-ons.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In preparation for splitting the ehci-hcd driver into a core library
and separate platform-specific driver modules, this patch (as1617)
changes the way ehci_read_frame_index() is handled.

Since the same core library will have to work with both PCI and
non-PCI platforms, the quirk handler routine will be compiled
unconditionally.  The decision about whether to call it or simply to
read the frame index register is made at run time, based on whether
the frame_index_bug quirk flag is set.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In preparation for splitting the ehci-hcd driver into a core library
and separate platform-specific driver modules, this patch (as1616)
moves the console logging macros from ehci-dbg.c to ehci.h, where they
will be available to the platform drivers.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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 (as1589) resolves some unlikely races involving system
shutdown or controller death in ehci-hcd:

	Shutdown races with both root-hub resume and controller
	resume.

	Controller death races with root-hub suspend.

A new bitflag is added to indicate that the controller has been shut
down (whether for system shutdown or because it died).  Tests are
added in the suspend and resume pathways to avoid reactivating the
controller after any sort of shutdown.
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 (as1584) fixes a minor bug that has been present in
ehci-hcd since the beginning.

Scanning the schedules for URB completions is single-threaded.  If a
completion interrupt occurs while an URB is being given back, the
interrupt handler realizes that a scan is in progress on another CPU
and avoids starting a new one.

This means that completion events can be lost.  If an URB completes
after it has been scanned but while a scan is still in progress, the
driver won't notice and won't rescan the completed URB.

The patch fixes the problem by adding a new flag to indicate that
another scan is needed after the current scan is done.  The flag gets
set whenever a completion interrupt occurs while a scan is in
progress.  The rescan will see the completion, thus preventing it from
getting lost.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1583) changes ehci-hcd to use an hrtimer event for
unlinking empty (unused) async QHs instead of using a kernel timer.

The check for empty QHs is moved to a new routine, where it doesn't
require going through an entire scan of both the async and periodic
schedules.  And it can unlink multiple QHs at once, unlike the current
code.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1582) changes ehci-hcd's strategy for unlinking async
QHs.  Currently the driver never unlinks more than one QH at a time.
This can be inefficient and cause unnecessary delays, since a QH
cannot be reused while it is waiting to be unlinked.

The new strategy unlinks all the waiting QHs at once.  In practice the
improvement won't be very big, because it's somewhat uncommon to have
two or more QHs waiting to be unlinked at any time.  But it does
happen, and in any case, doing things this way makes more sense IMO.

The change requires the async unlinking code to be refactored
slightly.  Now in addition to the routines for starting and ending an
unlink, there are new routines for unlinking a single QH and starting
an IAA cycle.  This approach is needed because there are two separate
paths for unlinking async QHs:

	When a transfer error occurs or an URB is cancelled, the QH
	must be unlinked right away;

	When a QH has been idle sufficiently long, it is unlinked
	to avoid consuming DMA bandwidth uselessly.

In the first case we want the unlink to proceed as quickly as
possible, whereas in the second case we can afford to batch several
QHs together and unlink them all at once.  Hence the division of
labor.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1581) replaces the iaa_watchdog kernel timer used by
ehci-hcd with an hrtimer event, in keeping with the general conversion
to high-res timers.
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 (as1578) adds an hrtimer event to handle the death of an
EHCI controller.  When a controller dies, it doesn't necessarily stop
running right away.  The new event polls at 1-ms intervals to see when
all activity has safely stopped.  This replaces a busy-wait polling
loop in the current code.
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 (as1576) adds hrtimer support for managing ehci-hcd's
async schedule.  Just as with the earlier change to the periodic
schedule management, two new hrtimer events take care of everything.

One event polls at 1-ms intervals to see when the Asynchronous
Schedule Status (ASS) flag matches the Asynchronous Schedule Enable
(ASE) value; the schedule's state must not be changed until it does.
The other event delays for 15 ms after the async schedule becomes
empty before turning it off.

The new events replace a busy-wait poll and a kernel timer usage.
They also replace the rather illogical method currently used for
indicating the async schedule should be turned off: attempting to
unlink the dedicated QH at the head of the async list.
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 (as1572) begins the conversion of ehci-hcd over to using
high-resolution timers rather than old-fashioned low-resolution kernel
timers.  This reduces overhead caused by timer roundoff on systems
where HZ is smaller than 1000.  Also, the new timer framework
introduced here is much more logical and easily extended than the
ad-hoc approach ehci-hcd currently uses for timers.

An hrtimer structure is added to ehci_hcd, along with a bitflag array
and an array of ktime_t values, to keep track of which timing events
are pending and what their expiration times are.

Only the infrastructure for the timing operations is added in this
patch.  Later patches will add routines for handling each of the
various timing events the driver needs.  In some cases the new hrtimer
handlers will replace the existing handlers for ehci-hcd's kernel
timers; as this happens the old timers will be removed.  In other
cases the new timing events will replace busy-wait loops.
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 (as1570) adds a pointer for the end of ehci-hcd's
async-unlink list.  The list (which is actually a queue) is singly
linked, so having a pointer to its end makes adding new entries easier
-- there's no longer any need to scan through the whole list.

In principle it could be changed to a standard doubly-linked list.  It
turns out that doing so actually makes the code less clear, so I'm
leaving it as is.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1569) renames the ehci->reclaim list in ehci-hcd.  The
word "reclaim" is used in the EHCI specification to mean something
quite different, and "unlink_next" is more descriptive of the list's
purpose anyway.

Similarly, the "reclaim" field in the ehci_stats structure is renamed
"iaa", which is more meaningful (to experts, anyway) and is a better
match for the "lost_iaa" field.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1568) introduces symbolic constants for some of the
less-frequently used bitfields in the QH structure.  This makes the
code a little easier to read and understand.
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>

 - to decrease redundant since both ehci_hcd and ohci_hcd have the same variable
 - it helps access phy in usb core code
 - phy is more meaningful than transceiver
Signed-off-by: NRichard Zhao <richard.zhao@freescale.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 1996e6c5.

It turned out to not be needed, now that the real fix has been
committed.
Reported-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1556) works around a bug in the Philips ISP1562 EHCI
controller.  Although the controller claims to support frame-list
lengths smaller than the default of 1024 for its periodic schedule, in
fact smaller values don't work.  A new quirk flag is added to indicate
when the bug is present, and if it is then the schedule size is left
at the default value.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1537) adds a bit-array to ehci-hcd for keeping track of
which ports are undergoing a resume transition.  If any of the bits
are set when ehci_hub_status_data() is called, the routine will return
a nonzero value even if no ports have any status changes pending.
This will allow usbcore to handle races between root-hub suspend and
port wakeup.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
CC: Chen Peter-B29397 <B29397@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This is the first step in separating USB transceivers from
USB OTG utilities.

Includes fixes to IMX code from Sascha Hauer.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NPavankumar Kondeti <pkondeti@codeaurora.org>
Acked-by: NLi Yang <leoli@freescale.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NIgor Grinberg <grinberg@compulab.co.il>
Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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>

This patch (as1480) fixes a rather obscure bug in ehci-hcd.  The
qh_update() routine needs to know the number and direction of the
endpoint corresponding to its QH argument.  The number can be taken
directly from the QH data structure, but the direction isn't stored
there.  The direction is taken instead from the first qTD linked to
the QH.

However, it turns out that for interrupt transfers, qh_update() gets
called before the qTDs are linked to the QH.  As a result, qh_update()
computes a bogus direction value, which messes up the endpoint toggle
handling.  Under the right combination of circumstances this causes
usb_reset_endpoint() not to work correctly, which causes packets to be
dropped and communications to fail.

Now, it's silly for the QH structure not to have direct access to all
the descriptor information for the corresponding endpoint.  Ultimately
it may get a pointer to the usb_host_endpoint structure; for now,
adding a copy of the direction flag solves the immediate problem.

This allows the Spyder2 color-calibration system (a low-speed USB
device that sends all its interrupt data packets with the toggle set
to 0 and hance requires constant use of usb_reset_endpoint) to work
when connected through a high-speed hub.  Thanks to Graeme Gill for
supplying the hardware that allowed me to track down this bug.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NGraeme Gill <graeme@argyllcms.com>
CC: <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1477) fixes a problem affecting a few types of EHCI
controller.  Contrary to what one might expect, these controllers
automatically stop their internal frame counter when no ports are
enabled.  Since ehci-hcd currently relies on the frame counter for
determining when it should unlink QHs from the async schedule, those
controllers run into trouble: The frame counter stops and the QHs
never get unlinked.

Some systems have also experienced other problems traced back to
commit b9638011 (USB: ehci-hcd unlink
speedups), which made the original switch from using the system clock
to using the frame counter.  It never became clear what the reason was
for these problems, but evidently it is related to use of the frame
counter.

To fix all these problems, this patch more or less reverts that commit
and goes back to using the system clock.  But this can't be done
cleanly because other changes have since been made to the scan_async()
subroutine.  One of these changes involved the tricky logic that tries
to avoid rescanning QHs that have already been seen when the scanning
loop is restarted, which happens whenever an URB is given back.
Switching back to clock-based unlinks would make this logic even more
complicated.

Therefore the new code doesn't rescan the entire async list whenever a
giveback occurs.  Instead it rescans only the current QH and continues
on from there.  This requires the use of a separate pointer to keep
track of the next QH to scan, since the current QH may be unlinked
while the scanning is in progress.  That new pointer must be global,
so that it can be adjusted forward whenever the _next_ QH gets
unlinked.  (uhci-hcd uses this same trick.)

Simplification of the scanning loop removes a level of indentation,
which accounts for the size of the patch.  The amount of code changed
is relatively small, and it isn't exactly a reversion of the
b9638011 commit.

This fixes Bugzilla #32432.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: <stable@kernel.org>
Tested-by: NMatej Kenda <matejken@gmail.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>

{read,write}l_be are now defined for SPARC and do not need to be
defined for SPARC_LEON in ehci.h. This patch fixes the following
warnings:

  CC      drivers/usb/host/ehci-hcd.o
In file included from drivers/usb/host/ehci-hcd.c:119:
drivers/usb/host/ehci.h:631:1: warning: "readl_be" redefined
...
drivers/usb/host/ehci-hcd.c:119:
drivers/usb/host/ehci.h:632:1: warning: "writel_be" redefined
...
Signed-off-by: NJan Andersson <jan@gaisler.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>