This reverts commit 196705c9bb. It was
reported to cause a regression by Daniel Exner, and Arjan van de Ven
points out that we actually already have infrastructure in place for
setting limits on acceptable DMA latency that would be the much more
correct fix for the problem with some Broadcom EHCI controllers.
Fixed up trivial conflicts due to the changes to support big-endian host
controller descriptors in drivers/usb/host/{ehci-sched.c,ehci.h}.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
USB HCD glue updates to reflect the new PS3 unifed device support.
- Fixed remove() routine.
- Added shutdown() routine.
- Added request_mem_region() call.
- Fixed MODULE_ALIAS().
- Made a proper fix for the hack done to support muti-platform in commit
48fda45120.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes the endianness select for transfer buffers in EHCI
controllers that have Transaction Translator built in the hub. Also I
cleaned it up to make rid of magic numbers.
Signed-off-by: Vladimir Barinov <vbarinov@ru.mvista.com>
Cc: <david-b@pacbell.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
For MPC831x support, change the ehci-fsl driver to preserve
bits set in platform code. Add a common CONFIG_USB_EHCI_FSL
to indicate presence of Freescale EHCI SOC. Add FSL_USB2_DR_OTG
operating mode support, thus both host and device can work for the
mini-ab receptacle. Note: this doesn't enable OTG protocol
support.
Signed-off-by: Li Yang <leoli@freescale.com>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds support for the AMCC 440EPx EHCI controller whose
in-memory data structures and the registers are represented in big-
endian format.
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as887) changes the way ehci-hcd and ohci-hcd handle a loss
of VBUS power during suspend. In order for the USB-persist facility
to work correctly, it is necessary for low- and full-speed devices
attached to a high-speed port to be handed back to the companion
controller during resume processing.
This entails three changes: adding code to ehci-hcd to perform the
handover, removing code from ohci-hcd to turn off ports during
root-hub reinit, and adding code to ohci-hcd to turn on ports during
PCI controller resume. (Other bus glue resume methods for platforms
supporting high-speed controllers would need a similar change, if any
existed.)
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch implements supports for EHCI controllers whose in-memory
data structures are represented in big-endian format. This is needed
(unfortunately) for the AMCC PPC440EPx SoC EHCI controller; the EHCI
spec doesn't specify little-endian format, although that's what most
other implementations use.
The guts of the patch are to introduce the hc32 type and change all
references from le32 to hc32. All access routines are converted from
cpu_to_le32(...) to cpu_to_hc32(ehci, ...) and similar for the other
"direction". (This is the same approach used with OHCI.)
David fixed:
Whitespace fixes; refresh against ehci cpufreq patch; move glue
for that PPC driver to the patch adding it; fix free symbol
capture bugs in modified "constant" macros; and make "hc32" etc
be "le32" unless we really need the BE options, so "sparse" can
do some real good.
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
EHCI controllers that don't cache enough microframes can get MMF errors
when CPU frequency changes occur between the start and completion of
split interrupt transactions, due to delays in reading main memory
(caused by CPU cache snoop delays).
This patch adds a cpufreq notifier to the EHCI driver that will
inactivate split interrupt transactions during frequency transitions.
It was tested on Intel ICH7 and Serverworks/Broadcom HT1000 EHCI
controllers.
Signed-off-by: Stuart Hayes <stuart_hayes@dell.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Remove includes of <linux/smp_lock.h> where it is not used/needed.
Suggested by Al Viro.
Builds cleanly on x86_64, i386, alpha, ia64, powerpc, sparc,
sparc64, and arm (all 59 defconfigs).
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There is one significant difference between the behavior of root hubs
(as embodied in host controller hardware) and external hubs: When a
remote-wakeup signal is received, an external hub sends an interrupt
message at the _end_ of the resume sequence but a root hub generates
and interrupt at the _beginning_ of the resume sequence. The host
system must poll for the end of the sequence.
When ehci-hcd was converted to interrupt-driven operation instead of
using polling, the remaining need for this particular poll was
overlooked. This patch (as894) fixes the problem.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as850b) disables remote wakeup (and everything else!) on
all EHCI ports when the shutdown() method is called. If remote wakeup
is left active then some systems will reboot instead of powering off.
This fixes Bugzilla #7828.
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>
Switch ehci-hcd to use the new polling scheme, which reports root
hub status changes via the interrupt handler, in an asynchronous
fashion. Doing so disables polling for status changes (whose handler is
rh_timer_func).
Tested on a Geode GX machine, which is now capable of running at =~ 5
timer interrupts per second (in the -rt tree), resulting in significant
power savings.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as710) adds a sysfs class-device attribute file named
"companion" for EHCI controllers. The file contains a list of port
numbers that are dedicated to the companion controller; by writing a
port number to the file the user can force a high-speed device
attached directly to the computer to run at full speed. (As far as I
know it is not possible to do this for a device attached to an
external hub.) A port is removed from the file by writing the
negative of its port number.
Several users have asked for this facility and it seems like a useful
thing to have. Every now and then one runs across a device which
behaves much better at full speed than at high speed.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch implements supports for EHCI controllers whose MMIO
registers are big endian and enables that functionality for
the Toshiba SCC chip. It does _not_ add support for big endian
in-memory data structures as this is not needed for that chip
and I hope it will never be.
The guts of the patch are to convert readl(...) to
ehci_readl(ehci, ...) and similarly for register writes.
Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Geoff Levand <geoffrey.levand@am.sony.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as738b) fixes numerous problems in the controller/root-hub
suspend/resume/remote-wakeup support in ehci-hcd:
The bus_resume() routine should wake up only the ports that
were suspended by bus_suspend(). Ports that were already
suspended should remain that way.
The interrupt mask is used to detect loss of power in the
bus_resume() routine (if the mask is 0 then power was lost).
However bus_suspend() always sets the mask to 0. Instead the
mask should retain its normal value, with port-change-detect
interrupts disabled if remote wakeup is turned off.
The interrupt mask should be reset to its correct value at the
end of bus_resume() regardless of whether power was lost.
bus_resume() reinitializes the operational registers if power
was lost. However those registers are not in the aux power
well, hence they can lose their values whenever the controller
is put into D3. They should always be reinitialized.
When a port-change interrupt occurs and the root hub is
suspended, the interrupt handler should request a root-hub
resume instead of starting up the controller all by itself.
There's no need for the interrupt handler to request a
root-hub resume every time a suspended port sends a
remote-wakeup request.
The pci_resume() method doesn't need to check for connected
ports when deciding whether or not to reset the controller.
It can make that decision based on whether Vaux power was
maintained.
Even when the controller does not need to be reset,
pci_resume() must undo the effect of pci_suspend() by
re-enabling the interrupt mask.
If power was lost, pci_resume() must not call ehci_run().
At this point the root hub is still supposed to be suspended,
not running. It's enough to rewrite the command register and
set the configured_flag.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Certain boards seem to like to issue false overcurrent notifications, for
example on ports that don't have anything connected to them. This looks
like a hardware error, at the level of noise to those ports' overcurrent
input signals (or non-debounced VBUS comparators). This surfaces to users
as truly massive amounts of syslog spam from khubd (which is appropriate
for real hardware problems, except for the volume from multiple ports).
Using this new "ignore_oc" flag helps such systems work more sanely, by
preventing such indications from getting to khubd (and spam syslog). The
downside is of course that true overcurrent errors will be masked; they'll
appear as spontaneous disconnects, without the diagnostics that will let
users troubleshoot issues like short circuited cables.
Note that the bulk of these reports seem to be with VIA southbridges, but
I think some were with Intel ones.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
of passing regs around manually through all ~1800 interrupt handlers in the
Linux kernel.
The regs pointer is used in few places, but it potentially costs both stack
space and code to pass it around. On the FRV arch, removing the regs parameter
from all the genirq function results in a 20% speed up of the IRQ exit path
(ie: from leaving timer_interrupt() to leaving do_IRQ()).
Where appropriate, an arch may override the generic storage facility and do
something different with the variable. On FRV, for instance, the address is
maintained in GR28 at all times inside the kernel as part of general exception
handling.
Having looked over the code, it appears that the parameter may be handed down
through up to twenty or so layers of functions. Consider a USB character
device attached to a USB hub, attached to a USB controller that posts its
interrupts through a cascaded auxiliary interrupt controller. A character
device driver may want to pass regs to the sysrq handler through the input
layer which adds another few layers of parameter passing.
I've build this code with allyesconfig for x86_64 and i386. I've runtested the
main part of the code on FRV and i386, though I can't test most of the drivers.
I've also done partial conversion for powerpc and MIPS - these at least compile
with minimal configurations.
This will affect all archs. Mostly the changes should be relatively easy.
Take do_IRQ(), store the regs pointer at the beginning, saving the old one:
struct pt_regs *old_regs = set_irq_regs(regs);
And put the old one back at the end:
set_irq_regs(old_regs);
Don't pass regs through to generic_handle_irq() or __do_IRQ().
In timer_interrupt(), this sort of change will be necessary:
- update_process_times(user_mode(regs));
- profile_tick(CPU_PROFILING, regs);
+ update_process_times(user_mode(get_irq_regs()));
+ profile_tick(CPU_PROFILING);
I'd like to move update_process_times()'s use of get_irq_regs() into itself,
except that i386, alone of the archs, uses something other than user_mode().
Some notes on the interrupt handling in the drivers:
(*) input_dev() is now gone entirely. The regs pointer is no longer stored in
the input_dev struct.
(*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does
something different depending on whether it's been supplied with a regs
pointer or not.
(*) Various IRQ handler function pointers have been moved to type
irq_handler_t.
Signed-Off-By: David Howells <dhowells@redhat.com>
(cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
This revamps handling of the hardware "async advance" IRQ, and its watchdog
timer. Basically it dis-entangles that important timeout from the others,
simplifying the associated state and code to make it more robust.
This reportedly improves behavior of EHCI on some systems with VIA chips,
and AFAIK won't affect non-VIA hardware. VIA systems need this code to
recover from silcon bugs whereby the "async advance" IRQ isn't issued.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[ ... when you have an editor set to remind you of whitespace bugs ... ]
Cosmetic EHCI changes: remove end-of-line whitespace, spaces before tabs.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If some problem occurs during ehci startup, for instance, request_irq fails,
echi hcd driver tries it best to cleanup, but fails to unregister reboot
notifier, which in turn leads to crash on reboot/poweroff.
The following patch resolves this problem by not using reboot notifiers
anymore, but instead making ehci/ohci driver get its own shutdown method. For
PCI, it is done through pci glue, for everything else through platform driver
glue.
One downside: sa1111 does not use platform driver stuff, and does not have its
own shutdown hook, so no 'shutdown' is called for it now. I'm not sure if it
is really necessary on that platform, though.
Signed-off-by: Aleks Gorelov <dared1st@yahoo.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In a rare and all-but-unused path, the EHCI driver could reuse a variable
in a way that'd make trouble. Specifically, if the first root hub port
gets an overcurrent event (rare) during a remote wakeup scenario (all but
unused in today's Linux, except for folk working with suspend-to-RAM and
similar sleep states), that would look like a fatal error which would shut
down the controller. Fix by not reusing that variable.
Spotted by Per Hallsmark <saxofon@musiker.nu>
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=6661
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Linus Torvalds
Geoff Levand
Vladimir Barinov
Li Yang
Stefan Roese
Alan Stern
Stuart_Hayes@Dell.com
Randy Dunlap
Ishizaki Kou
Marcelo Tosatti
Benjamin Herrenschmidt
David Brownell
Greg Kroah-Hartman
David Howells
Aleksey Gorelov