This patch (as1256) changes ehci-hcd and all the other drivers in the
EHCI family to make use of the new clear_tt_buffer callbacks. When a
Clear-TT-Buffer request is in progress for a QH, the QH is not allowed
to be linked into the async schedule until the request is finished.
At that time, if there are any URBs queued for the QH, it is linked
into the async schedule.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1245) fixes a bug in ehci-hcd. When an URB is queued
for an endpoint whose QH is already in the LINKED state, the QH
doesn't get refreshed. As a result, if usb_clear_halt() was called
during the time that the QH was linked but idle, the data toggle value
in the QH doesn't get reset.
The symptom is that after a clear_halt, data gets lost and transfers
time out. This problem is starting to show up now because the
"ehci-hcd unlink speedups" patch causes QHs with no queued URBs to
remain linked for a suitable time.
The patch utilizes the new endpoint_reset mechanism to fix the
problem. When an endpoint is reset, the new method forcibly unlinks
the QH (if necessary) and safely updates the toggle value. This
allows qh_update() to be simplified and avoids using usb_device's
toggle bits in a rather unintuitive way.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: David Brownell <david-b@pacbell.net>
Tested-by: David <david@unsolicited.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
A published errata for ppc440epx states, that when running Linux with
both EHCI and OHCI modules loaded, the EHCI module experiences a fatal
error when a high-speed device is connected to the USB2.0, and
functions normally if OHCI module is not loaded.
There used to be recommendation to use only hi-speed or full-speed
devices with specific conditions, when respective module was unloaded.
Later, it was observed that ohci suspend is enough to keep things
going, and it was turned into workaround, as explained below.
Quote from original descriprion:
The 440EPx USB 2.0 Host controller is an EHCI compliant controller. In
USB 2.0 Host controllers, each EHCI controller has one or more companion
controllers, which may be OHCI or UHCI. An USB 2.0 Host controller will
contain one or more ports. For each port, only one of the controllers
is connected at any one time. In the 440EPx, there is only one OHCI
companion controller, and only one USB 2.0 Host port.
All ports on an USB 2.0 controller default to the companion
controller. If you load only an ohci driver, it will have control of
the ports and any deviceplugged in will operate, although high speed
devices will be forced to operate at full speed. When an ehci driver
is loaded, it explicitly takes control of the ports. If there is a
device connected, and / or every time there is a new device connected,
the ehci driver determines if the device is high speed or not. If it
is high speed, the driver retains control of the port. If it is not,
the driver explicitly gives the companion controller control of the
port.
The is a software workaround that uses
Initial version of the software workaround was posted to
linux-usb-devel:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg54019.html
and later available from amcc.com:
http://www.amcc.com/Embedded/Downloads/download.html?cat=1&family=15&ins=2
The patch below is generally based on the latter, but reworked to
powerpc/of_device USB drivers, and uses a few devicetree inquiries to
get rid of (some) hardcoded defines.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1096) fixes an annoying problem: When a full-speed or
low-speed device is plugged into an EHCI controller, it fails to
enumerate at high speed and then is handed over to the companion
controller. But usbcore logs a misleading and unwanted error message
when the high-speed enumeration fails.
The patch adds a new HCD method, port_handed_over, which asks whether
a port has been handed over to a companion controller. If it has, the
error message is suppressed.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: David Brownell <david-b@pacbell.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1095) cleans up the HCD glue and several of the EHCI
bus-glue files. The ehci->is_tdi_rh_tt flag is redundant, since it
means the same thing as the hcd->has_tt flag, so it is removed and the
other flag used in its place.
Some of the bus-glue files didn't get the relinquish_port method added
to their hc_driver structures. Although that routine currently
doesn't do anything for controllers with an integrated TT, in the
future it might. So the patch adds it where it is missing.
Lastly, some of the bus-glue files have erroneous entries for their
hc_driver's suspend and resume methods. These method pointers are
specific to PCI and shouldn't be used otherwise.
(The patch also includes an invisible whitespace fix.)
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
This adds device-tree-aware ehci-ppc-of driver.
The code is based on the ehci-ppc-soc driver by
Stefan Roese <sr@denx.de>.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Stefan Roese <sr@denx.de>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alan Stern