Separate the SPEAr host controller driver from ehci-hcd host code
so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before SPEAr can be
booted with a multi-platform kernel, but they are queued in the
arm-soc tree for 3.10.
With the infrastructure added by Alan Stern in patch 3e0232039
"USB: EHCI: prepare to make ehci-hcd a library module", we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the SPEAr bus glue.
In V4 (arnd):
- renamed all 'struct spear_ehci' pointers from 'ehci' to the
less ambiguous 'sehci'.
- folded trivial spear_start_ehci/spear_stop_ehci functions into
callers.
- brought back initialization of ehci->caps.
In V3:
- Detailed commit message added here about why this patch is required.
- Eliminated ehci_spear_setup routine because hcd registers can
be directly set in the spear_ehci_hcd_drv_probe function.
- spear_overrides struct initialized.
- Converted to using .extra_priv_size for allocating spear_ehci,
and updated all users of that structure.
- to_spear_ehci() macro modified for spear_ehci.
In V2:
- Replaced spear as SPEAr everywhere, leaving functions/variables/config options.
Signed-off-by: Deepak Saxena <dsaxena@linaro.org>
Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Viresh Kumar <viresh.linux@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Shiraz Hashim <shiraz.hashim@st.com>
Cc: spear-devel@list.st.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Separate the Orion host controller driver from ehci-hcd host
code into its own driver module because of following reason.
With the multiplatform changes in arm-soc tree, it becomes
possible to enable the mvebu platform (which uses
ehci-orion) at the same time as other platforms that require
a conflicting EHCI bus glue. At the moment, this results
in a warning like
drivers/usb/host/ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
drivers/usb/host/ehci-hcd.c:1277:0: note: this is the location of the previous definition
drivers/usb/host/ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined but not used [-Wunused-variable]
and an ehci driver that only works on one of them.
With the infrastructure added by Alan Stern in patch 3e0232039
"USB: EHCI: prepare to make ehci-hcd a library module", we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the orion bus glue.
An earlier version of this patch was included in 3.9 but caused
a regression there, which has subsequently been fixed.
While we are here, use the opportunity to disabiguate the two
Marvell EHCI controller implementations in Kconfig.
In V4 (arnd):
- Improve Kconfig text
In V3:
- More detail provided in commit message regarding this patch.
- Replaced hcd_name string "ehci-orion" into "orion-ehci".
- MODULE_LICENSE is GPL v2.
- In ehci_init_driver calling second argument passed as NULL instead of
ehci_orion_overrides because ehci_orion_overrides is removed.
In V2:
- Tegra patch related changes removed from this patch.
Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This lets us use the ehci-platform driver on platforms without special
requirements for their ehci controllers. In particular, this is true
for the vt8500/wm8x50 platforms, which currently have a separate
driver that causes problems with multiplatform configurations.
Tested-by: Tony Prisk <linux@prisktech.co.nz>
Tested-by: Peter Vasil <petervasil@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1665) changes the way ehci-hcd's end_unlink_async()
routine works in order to avoid recursive execution and to be more
efficient:
Now when an IAA cycle ends, a new one gets started up right
away (if it is needed) instead of waiting until the
just-unlinked QH has been processed.
The async_iaa list is renamed to async_idle, which better
expresses its new purpose: It is now the list of QHs which are
now completely idle and are waiting to be processed by
end_unlink_async().
A new flag is added to track whether an IAA cycle is in
progress, because the list formerly known as async_iaa no
longer stores the QHs waiting for the IAA to finish.
The decision about how many QHs to process when an IAA cycle
ends is now made at the end of the cycle, when we know the
current state of the hardware, rather than at the beginning.
This means a bunch of logic got moved from start_iaa_cycle()
to end_unlink_async().
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1664) converts ehci-hcd's async_unlink, async_iaa, and
intr_unlink from singly-linked lists to standard doubly-linked
list_heads. Originally it didn't seem necessary to use list_heads,
because items are always added to and removed from these lists in FIFO
order. But now with more list processing going on, it's easier to use
the standard routines than continue with a roll-your-own approach.
I don't know if the code ends up being notably shorter, but the
patterns will be more familiar to any kernel hacker.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1668) consolidates two nearly identical code paths in
ehci_urb_dequeue(). The test for !qh can be removed because it will
never succeed; the fact that usb_hcd_check_unlink_urb() returned 0
means that urb must be queued and therefore urb->hcpriv must point to
a QH.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1662) does some more QH-related cleanup in ehci-hcd.
The qh->needs_rescan flag is currently used for two different
purposes; the patch replaces it with two separate flags for greater
clarity: qh->dequeue_during_giveback indicates that a completion
handler dequeued an URB (implying that a rescan is needed), and
qh->exception indicates that the QH is in an exceptional state
requiring an unlink (either it encountered an I/O error or an unlink
was requested).
The new flags get set where the dequeue, exception, or unlink request
occurred, rather than where the unlink is started. This is so that in
the future, if we need to, we will be able to tell apart unlinks that
truly were required from those that were carried out merely because
the QH wasn't being used.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This is to pick up the fixes in that branch, and let Alan fix the merge
error in drivers/usb/host/ehci-timer.c better than I just did (as I know
I messed it up...)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1634) simplifies some of the code associated with the
per-port change bits added in EHCI-1.1, and in particular it fixes a
bug in the logic of ehci_hub_status_data(). Even if the change bit
doesn't indicate anything happened on a particular port, we still have
to notify the core about changes to the suspend or reset status.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1663) fixes a regression caused by commit
6e0c3339a6 (USB: EHCI: unlink one async
QH at a time). In order to avoid keeping multiple QHs in an unusable
intermediate state, that commit changed unlink_empty_async() so that
it unlinks only one empty QH at a time.
However, when the EHCI root hub is suspended, _all_ async QHs need to
be unlinked. ehci_bus_suspend() used to do this by calling
unlink_empty_async(), but now this only unlinks one of the QHs, not
all of them.
The symptom is that when the root hub is resumed, USB communications
don't work for some period of time. This is because ehci-hcd doesn't
realize it needs to restart the async schedule; it assumes that
because some QHs are already on the schedule, the schedule must be
running.
The easiest way to fix the problem is add a new function that unlinks
all the async QHs when the root hub is suspended.
This patch should be applied to all kernels that have the 6e0c3339a6
commit.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Adrian Bassett <adrian.bassett@hotmail.co.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1645) converts ehci-omap over to the new "ehci-hcd is a
library" approach, so that it can coexist peacefully with other EHCI
platform drivers and can make use of the private area allocated at
the end of struct ehci_hcd.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1660) works around a hardware problem present in some
(if not all) Intel EHCI controllers. After a QH has been unlinked
from the async schedule and the corresponding IAA interrupt has
occurred, the controller is not supposed access the QH and its qTDs.
There certainly shouldn't be any more DMA writes to those structures.
Nevertheless, Intel's controllers have been observed to perform a
final writeback to the QH's overlay region and to the most recent qTD.
For more information and a test program to determine whether this
problem is present in a particular controller, see
http://marc.info/?l=linux-usb&m=135492071812265&w=2http://marc.info/?l=linux-usb&m=136182570800963&w=2
This patch works around the problem by always waiting for two IAA
cycles when unlinking an async QH. The extra IAA delay gives the
controller time to perform its final writeback.
Surprisingly enough, the effects of this silicon bug have gone
undetected until quite recently. More through luck than anything
else, it hasn't caused any apparent problems. However, it does
interact badly with the path that follows this one, so it needs to be
addressed.
This is the first part of a fix for the regression reported at:
https://bugs.launchpad.net/bugs/1088733
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Stephen Thirlwall <sdt@dr.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1650) adds calls to the new
usb_hcd_{start,end}_port_resume() functions to ehci-hcd. Now EHCI
root hubs won't be runtime suspended while they are sending a resume
signal to one of their ports.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1643b) fixes a build error in ehci-hcd when compiling for
ARM with allmodconfig:
drivers/usb/host/ehci-hcd.c:1285:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition
drivers/usb/host/ehci-mxc.c:280:31: warning: 'ehci_mxc_driver' defined but not used [-Wunused-variable]
drivers/usb/host/ehci-hcd.c:1285:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition
The fix is to convert ehci-mxc over to the new "ehci-hcd is a library"
scheme so that it can coexist peacefully with the ehci-platform
driver. As part of the conversion the ehci_mxc_priv data structure,
which was allocated dynamically, is now placed where it belongs: in
the private area at the end of struct ehci_hcd.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1641) fixes a minor bug in ehci-hcd left over from when
the Chipidea driver was converted to the "ehci-hcd is a library"
scheme. The test for whether the Chipidea platform driver is active
should be IS_ENABLED(), not defined().
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Roger Quadros <rogerq@ti.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1627) splits the ehci-hcd core code, which has become a
separate library module, out from the ChipIdea host driver. Instead
of #include-ing ehci-hcd.c directly, the ChipIdea module will now use
the ehci-hcd library in a normal fashion.
This fixes a build error caused by commit
3e02320399 (USB: EHCI: prepare to make
ehci-hcd a library module); I had forgotten about the unorthodox way
the ChipIdea driver uses the ehci-hcd code.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1626) splits the ehci-platform code from ehci-hcd out
into its own separate driver module.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1625) splits the PCI portion of ehci-hcd out into its
own separate driver module, called ehci-pci. Consistently with the
current practice, the decision whether to build this module is not
user-configurable. If EHCI and PCI are enabled then the module will
be built, always.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
CC: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1623) removes the ehci_port_power() routine and all the
places that call it. There's no reason for ehci-hcd to change the
port power settings; the hub driver takes care of all that stuff.
There is one exception: When the controller is resumed from
hibernation or following a loss of power, the ports that are supposed
to be handed over to a companion controller must be powered on first.
Otherwise the handover won't work. This process is not visible to the
hub driver, so it has to be handled in ehci-hcd.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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
aa4d834298 (USB: EHCI: EHCI 1.1
addendum: preparation) and an almost full revert of commit
48f2497014 (USB: EHCI: EHCI 1.1
addendum: Basic LPM feature support) plus its follow-ons.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The users have been converted to use the ehci platform driver instead, thus
making the ehci-cns3xxx driver obsolete, so remove it.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The platform code has been converted to use the ehci-platform driver instead
thus obsoleting the ehci-au1xxx driver, which can be removed.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The platform code has been migrated to register the ehci-platform driver, thus
obsoleting the ehci-xls driver, which can be removed.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The platform code registering the Loongson 1B EHCI driver has now been
converted to register the ehci-platform driver instead, thus obsoleting the
ehci-ls1x driver, which can be removed.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This driver is not registered by any in-tree user. If needed it the EHCI
driver can be reinstatied using the ehci-platform driver with caps_offset to
0x100.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Just like for the in-tree early console debug port driver, the
hypervisor - when using a debug port based console - also needs to be
told about controller resets, so it can suppress using and then
re-initialize the debug port accordingly.
Other than the in-tree driver, the hypervisor driver actually cares
about doing this only for the device where the debug is port actually
in use, i.e. it needs to be told the coordinates of the device being
reset (quite obviously, leveraging the addition done for that would
likely benefit the in-tree driver too).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here's the big USB patch set for the 3.6-rc1 merge window.
Lots of little changes in here, primarily for gadget controllers and drivers.
There's some scsi changes that I think also went in through the scsi tree, but
they merge just fine. All of these patches have been in the linux-next tree
for a while now.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEABECAAYFAlAQhpcACgkQMUfUDdst+yms4wCgpMbfFYTZ8lHpDnXHYFv6qw8j
FIsAmwT4mbT7m8C0k+ELV/5T2e0eYJEQ
=QetG
-----END PGP SIGNATURE-----
Merge tag 'usb-3.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB patches from Greg Kroah-Hartman:
"Here's the big USB patch set for the 3.6-rc1 merge window.
Lots of little changes in here, primarily for gadget controllers and
drivers. There's some scsi changes that I think also went in through
the scsi tree, but they merge just fine. All of these patches have
been in the linux-next tree for a while now.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"
Fix up trivial conflicts in include/scsi/scsi_device.h (same libata
conflict that Jeff had already encountered)
* tag 'usb-3.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (207 commits)
usb: Add USB_QUIRK_RESET_RESUME for all Logitech UVC webcams
usb: Add quirk detection based on interface information
usb: s3c-hsotg: Add header file protection macros in s3c-hsotg.h
USB: ehci-s5p: Add vbus setup function to the s5p ehci glue layer
USB: add USB_VENDOR_AND_INTERFACE_INFO() macro
USB: notify phy when root hub port connect change
USB: remove 8 bytes of padding from usb_host_interface on 64 bit builds
USB: option: add ZTE MF821D
USB: sierra: QMI mode MC7710 moved to qcserial
USB: qcserial: adding Sierra Wireless devices
USB: qcserial: support generic Qualcomm serial ports
USB: qcserial: make probe more flexible
USB: qcserial: centralize probe exit path
USB: qcserial: consolidate usb_set_interface calls
USB: ehci-s5p: Add support for device tree
USB: ohci-exynos: Add support for device tree
USB: ehci-omap: fix compile failure(v1)
usb: host: tegra: pass correct pointer in ehci_setup()
USB: ehci-fsl: Update ifdef check to work on 64-bit ppc
USB: serial: keyspan: Removed unrequired parentheses.
...
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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1588) adjusts the locking in ehci-hcd's various halt,
shutdown, and suspend/resume pathways. We want to hold the spinlock
while writing device registers and accessing shared variables, but not
while polling in a loop.
In addition, there's no need to call ehci_work() at times when no URBs
can be active, i.e., in ehci_stop() and ehci_bus_suspend().
Finally, ehci_adjust_port_wakeup_flags() is called only in situations
where interrupts are enabled; therefore it can use spin_lock_irq
rather than spin_lock_irqsave.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1575) removes special code added for status polling of
the EHCI controller in PS3 systems. While the controller is running,
the polling is now carried out by an hrtimer handler. When the
controller is suspending or stopping, we use the same polling routine
as the old code -- but in neither case do we need to conclude that the
controller has died if the polling goes on for too long.
As a result the entire handshake_on_error_set_halt() routine is now
unused, so it is removed from the driver.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1566) removes the code in ehci-hcd's resume routines
which tries to restart or cancel any transfers left active while the
root hub or controller was asleep. This code isn't necessary, because
all URBs are terminated before the root hub is suspended.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently, EHCI initialization turns off the controller (in case it
was left running by the firmware) before setting up the ehci_hcd data
structure. This patch (as1565) reverses that order.
Although it doesn't matter now, it will matter later on when future
additions to ehci_halt() will want to acquire a spinlock that gets
initialized by ehci_init().
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1564c) converts the EHCI platform drivers to use the
central ehci_setup() routine for generic controller initialization
rather than each having its own idiosyncratic approach.
The major point of difficulty lies in ehci-pci's many vendor- and
device-specific workarounds. Some of them have to be applied before
calling ehci_setup() and some after, which necessitates a fair amount
of code motion. The other platform drivers require much smaller
changes.
One point not addressed by the patch is whether ports should be
powered on or off following initialization. The different drivers
appear to handle this pretty much at random. In fact it shouldn't
matter, because the hub driver turns on power to all ports when it
binds to the root hub. Straightening that out will be left for
another day.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1563) removes a lot of duplicated code by moving the
EHCI controller suspend/resume routines into the core driver, where
the various platform drivers can invoke them as needed.
Not only does this simplify these platform drivers, this also makes it
easier for other platform drivers to add suspend/resume support in the
future.
Note: The patch does not touch the ehci-fsl.c file, because its
approach to suspend and resume is so different from all the others.
It will have to be handled specially by its maintainer.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1562) cleans up the definitions of the EHCI extended
registers to be consistent with the definitions of the standard
registers. This makes the code look a lot nicer, with no functional
change.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After commit aaa0ef289a "PS3 EHCI QH
read work-around", Terratec Grabby (em28xx) stopped working with AMD
Geode LX 800 (USB controller AMD CS5536). Since this is a PS3 only
fix, the following patch adds a conditional block around it.
Signed-off-by: Ricardo Martins <rasm@fe.up.pt>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 1996e6c572.
It turned out to not be needed, now that the real fix has been
committed.
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The 3d9545cc375d117554a9b35dfddadf9189c62775(EHCI: maintain the
ehci->command value properly) introducs one command register
configuration lost problem by the below line in ehci_reset:
ehci->command = ehci_readl(ehci, &ehci->regs->command);
After writting RESET into command register, it is restored to
its default value per EHCI spec[1], so the previous configuration
will be lost, and may introduce some problems reported recently:
- imx51 Babbage board detect usb hub failed[2], reported
by Richard Zhao.
- mouse and keyboard hangs in linux-next found by
Dan Carpenter and Greg-KH.
So this patch just removes the line to fix these problems, and
keep configurating command register consistent as before the commit
3d9545cc(EHCI: maintain the ehci->command value properly).
[1], 4.1 Host Controller Initialization of EHCI Specification 1.0
[2], failed dmesg log:
usb 1-1: new high-speed USB device number 2 using mxc-ehci
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 7 ports detected
mxc-ehci mxc-ehci.1: fatal error
mxc-ehci mxc-ehci.1: HC died; cleaning up
mxc-ehci mxc-ehci.1: force halt; handshake f5780344 00004000 00004000 -> -110
mxc-ehci mxc-ehci.1: HC died; cleaning up
usb 1-1: USB disconnect, device number 2
Reported-by: Richard Zhao <richard.zhao@freescale.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Chen Peter-B29397 <B29397@freescale.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This adds EHCI host support to the chipidea driver. We want it to be
part of the hdrc driver and not a standalone (sub-)driver module, as
the structure of ehci-hcd.c suggests, so for chipidea controller we
hack it to not provide platform-related code, but only the ehci hcd.
The ehci-platform driver won't work for us here too, because the
controller uses the same registers for both device and host mode and
also otg-related bits, so it's not really possible to put ehci registers
into a separate resource.
This is not a pretty solution, but the alternative is exporting symbols
from the chipidea driver to a ehci-chipidea driver and doing all the
module refcounting.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This resolves the conflict in:
drivers/usb/host/ehci-fsl.c
And picks up loads of xhci bugfixes to make it easier for others to test
with.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add EHCI driver for MIPS SEAD-3 development platform.
Signed-off-by: Chris Dearman <chris@mips.com>
Signed-off-by: Steven J. Hill <sjhill@mips.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1541) corrects a small mistake in ehci-hcd. The IAAD
(Interrupt on Async Advance Doorbell) bit in the USBCMD register is
designed, as its name says, to act as a "doorbell". That is, the
driver activates the bit by setting it to 1, and the hardware
deactivates it later by setting it back to 0. The driver cannot clear
the bit by writing a 0 to it; such writes are simply ignored.
Therefore there is no reason for ehci-hcd to try to clear the bit.
The patch removes the two instances where such attempts occur.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1544) fixes a problem affecting some EHCI controllers.
They can generate interrupts whenever the STS_FLR status bit is turned
on, even though that bit is masked out in the Interrupt Enable
register.
Since the driver doesn't use STS_FLR anyway, the patch changes the
interrupt routine to clear that bit whenever it is set, rather than
leaving it alone.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1542) changes the criterion ehci-hcd uses to tell when
it needs to resume the controller's root hub. A resume is needed when
a port status change is detected, obviously, but only if the root hub
is currently suspended.
Right now the driver tests whether the root hub is running, and that
is not the correct test. In particular, if the controller has died
then the root hub should not be restarted. In addition, some buggy
hardware occasionally requires the root hub to be running and
sending out SOF packets even while it is nominally supposed to be
suspended.
In the end, the test needs to be changed. Rather than checking whether
the root hub is currently running, the driver will now check whether
the root hub is currently suspended. This will yield the correct
behavior in all cases.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Peter Chen <B29397@freescale.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
CC: Chen Peter-B29397 <B29397@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove all #inclusions of asm/system.h preparatory to splitting and killing
it. Performed with the following command:
perl -p -i -e 's!^#\s*include\s*<asm/system[.]h>.*\n!!' `grep -Irl '^#\s*include\s*<asm/system[.]h>' *`
Signed-off-by: David Howells <dhowells@redhat.com>
The ath79 usb driver doesn't do anything special and is now converted
to the generic ehci and ohci driver.
This was tested on a TP-Link TL-WR1043ND (AR9132)
Acked-by: Gabor Juhos <juhosg@openwrt.org>
CC: Imre Kaloz <kaloz@openwrt.org>
CC: linux-mips@linux-mips.org
CC: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This adds a generic driver for platform devices. It works like the PCI
driver and is based on it. This is for devices which do not have an own
bus but their EHCI controller works like a PCI controller. It will be
used for the Broadcom bcma and ssb USB EHCI controller.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since ehci-mv.c can cover Marvell PXA and MMP series including PXA168,
so this driver seems redundant now.
Signed-off-by: Neil Zhang <zhangwm@marvell.com>
Cc: <tanmay.upadhyay@einfochips.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use ehci_setup() in ehci_ls1x_reset().
The Loongson1x SoCs have a built-in EHCI controller.
This patch adds the necessary glue code to make the generic EHCI
driver usable for them.
Signed-off-by: Kelvin Cheung <keguang.zhang@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
module_param(bool) used to counter-intuitively take an int. In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.
It's time to remove the int/unsigned int option. For this version
it'll simply give a warning, but it'll break next kernel version.
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This patch adds support for EHCI compliant HSUSB Host controller found
on Marvell Socs.
It fits both OTG and SPH controller on marvell Socs, including
PXA9xx/MMP2/MMP3/MGx.
Signed-off-by: Neil Zhang <zhangwm@marvell.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
PS3 EHCI HC errata fix 244. The SCC EHCI HC will not correctly perform QH
reads that occur near or span a micro-frame boundry. This is due to a problem
in the Nak Count Reload Control logic (EHCI Specification 1.0 Section 4.9.1).
The work-around for this problem is for the HC driver to set I=1 (inactive) for
QHs with H=1 (list head).
Signed-off-by: Geoff Levand <geoff@infradead.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
The EHCI USB controller of the Cell Super Companion Chip used in the PS3
will stop the root hub after all root hub ports are suspended. When in
this condition the ehci-hcd handshake routine will return -ETIMEDOUT and
the USB runtime suspend sequence will fail. The STS_HLT bit will not be
set, so inspection of the frame index is used to test for the condition.
Add a new routine handshake_for_broken_root_hub() that is called after
an unsuccessful -ETIMEDOUT handshake. On PS3 handshake_for_broken_root_hub()
will test for the condition, and if found will return success to allow the
USB suspend to complete. For all other platforms
handshake_for_broken_root_hub() will return -ETIMEDOUT
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Remove the ehci_reset() call done in the ehci_run() routine of the
USB EHCI host controller driver and add an ehci_reset() call to the
probe processing of all EHCI platform drivers that do not already call
ehci_reset().
The call to ehci_reset() from ehci_run() was problematic for several
platform drivers, and unnecessary for others. This change moves the
decision to call ehci_reset() at driver startup to the platform
driver code.
Signed-off-by: Geoff Levand <geoff@infradead.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Use CONFIG_CPU_XLR instead of CONFIG_NLM_XLR, the NLM_XLR config
option is redundant and is being removed.
Signed-off-by: Jayachandran C <jayachandranc@netlogicmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Now that no driver any longer depends on the CONFIG_SOC_AU1??? symbols,
it's time to get rid of them: Move some of the platform devices to the
boards which can use them, Rename a few (unused) constants in the header,
Replace them with MIPS_ALCHEMY in the various Kconfig files. Finally
delete them altogether from the Alchemy Kconfig file.
Signed-off-by: Manuel Lauss <manuel.lauss@googlemail.com>
To: Linux-MIPS <linux-mips@linux-mips.org>
Patchwork: https://patchwork.linux-mips.org/patch/2707/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
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: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jason N Pitt <jpitt@fhcrc.org>
CC: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
EHCI_SHRINK_JIFFIES should be 5ms, which was just used originally,
and not 200ms, so fix it.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add supprt for on-chip USB controller for Netlogic XLS MIPS64
SoC processor family.
Changes are:
- update ehci-hcd.c and ohci-hcd.c to add XLS hcds
- add ehci-xls.c: EHCI support for Netlogic XLS.
- add ohci-xls.c: OHCI support for Netlogic XLS.
Signed-off-by: Jayachandran C <jayachandranc@netlogicmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6: (115 commits)
EHCI: fix direction handling for interrupt data toggles
USB: serial: add IDs for WinChipHead USB->RS232 adapter
USB: OHCI: fix another regression for NVIDIA controllers
usb: gadget: m66592-udc: add pullup function
usb: gadget: m66592-udc: add function for external controller
usb: gadget: r8a66597-udc: add pullup function
usb: renesas_usbhs: support multi driver
usb: renesas_usbhs: inaccessible pipe is not an error
usb: renesas_usbhs: care buff alignment when dma handler
USB: PL2303: correctly handle baudrates above 115200
usb: r8a66597-hcd: fixup USB_PORT_STAT_C_SUSPEND shift
usb: renesas_usbhs: compile/config are rescued
usb: renesas_usbhs: fixup comment-out
usb: update email address in ohci-sh and r8a66597-hcd
usb: r8a66597-hcd: add function for external controller
EHCI: only power off port if over-current is active
USB: mon: Allow to use usbmon without debugfs
USB: EHCI: go back to using the system clock for QH unlinks
ehci: add pci quirk for Ordissimo and RM Slate 100 too
ehci: refactor pci quirk to use standard dmi_check_system method
...
Fix up trivial conflicts in Documentation/feature-removal-schedule.txt
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 b963801164 (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
b963801164 commit.
This fixes Bugzilla #32432.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@kernel.org>
Tested-by: Matej Kenda <matejken@gmail.com>
Signed-off-by: Greg 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: Kirill Smelkov <kirr@mns.spb.ru>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The only sysfs attr implemented so far is "companion" from ehci-hub.c,
but in the next patch we are going to add another sysfs file, so prior
to that let's structure things and move already-in-there sysfs code to
separate file.
NOTE: All the code I'm moving into this new file was written by Alan
Stern (in 57e06c11 "EHCI: force high-speed devices to run at full
speed"; Jan 16 2007), that's why I'm putting
Copyright (C) 2007 by Alan Stern
there after explicit request from the author.
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Following the loss of David Brownell, I volunteer to maintain the
ohci-hcd and ehci-hcd drivers. This patch (as1472) makes it official.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There is no need to have a "\n" on a MODULE_PARM_DESC, remove it
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Signed-off-by: Greg 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
9b37596a2e (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: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Manuel Lauss <manuel.lauss@googlemail.com>
CC: Rodolfo Giometti <giometti@linux.it>
CC: Olav Kongas <ok@artecdesign.ee>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
