Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 9月, 2009 3 次提交
  3. 16 6月, 2009 1 次提交
  5. 08 1月, 2009 2 次提交
    • V
      USB: powerpc: Workaround for the PPC440EPX USBH_23 errata [take 3] · 796bcae7
      由 Vitaly Bordug 提交于 
      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: NVitaly Bordug <vitb@kernel.crashing.org>
Signed-off-by: NStefan Roese <sr@denx.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      796bcae7
    • V
      USB: Avoid 20ms delay in EHCI resume · 3a4e72cb
      由 Vikram Pandita 提交于 
      For function ehci_bus_resume()
- Added flag resume_needed
  No need to wait for 20ms if no port was suspended

- Change mdelay to msleep

- release and reacquire the spinlock around mdelay
Signed-off-by: Nvikram pandita <vikram.pandita@ti.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3a4e72cb
  7. 18 10月, 2008 1 次提交
  9. 30 5月, 2008 2 次提交
  11. 29 4月, 2008 2 次提交
  13. 25 4月, 2008 5 次提交
    • A
      USB: fix compile problems in ehci-hcd · aff6d18f
      由 Alan Stern 提交于 
      This patch (as1072) fixes some recently-introduced compile problems
that show up in ehci-hcd when CONFIG_PM is turned off.

	PORT_WAKE_BITS needs to be defined always.

	ehci_port_power() is called during initialization by all the
	EHCI variants other than the PCI version, in which it is
	"defined but not used".  So add a call to it.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      aff6d18f
    • A
      USB: HCDs use the do_remote_wakeup flag · 58a97ffe
      由 Alan Stern 提交于 
      When a USB device is suspended, whether or not it is enabled for
remote wakeup depends on the device_may_wakeup() setting.  The setting
is then saved in the do_remote_wakeup flag.

Later on, however, the device_may_wakeup() value can change because of
user activity.  So when testing whether a suspended device is or
should be enabled for remote wakeup, we should always test
do_remote_wakeup instead of device_may_wakeup().  This patch (as1076)
makes that change for root hubs in several places.

The patch also adjusts uhci-hcd so that when an autostopped controller
is suspended, the remote wakeup setting agrees with the value recorded
in the root hub's do_remote_wakeup flag.

And the patch adjusts ehci-hcd so that wakeup events on selectively
suspended ports (i.e., the bus itself isn't suspended) don't turn on
the PME# wakeup signal.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      58a97ffe
    • D
      USB: ehci: minor cleanups · 9776afc8
      由 David Brownell 提交于 
      Minor cleanups to the EHCI code:  revision history is what source
code repositories should have.  Switch to a more standard way to
kick in verbose debugging -- don't be EHCI-specific.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      9776afc8
    • A
      USB: remove CONFIG_USB_PERSIST setting · feccc30d
      由 Alan Stern 提交于 
      This patch (as1047) removes the USB_PERSIST Kconfig option, enabling
it permanently.  It also prevents the power/persist attribute from
being created for hub devices; there's no point in having it since
USB-PERSIST is always turned on for hubs.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      feccc30d
    • A
      USB: EHCI: carry out port handover during each root-hub resume · 3bb1af52
      由 Alan Stern 提交于 
      This patch (as1044) causes EHCI port handover for non-high-speed
devices to occur during every root-hub resume, not just in cases where
the controller lost power or was reset.  This is necessary because:

	When some machines go into suspend, they remove power from
	on-board USB devices while retaining suspend current for USB
	controllers.

	The user might well unplug a USB device while the system is
	suspended and then plug it back in before resuming.

A corresponding change is made to the core resume routine; now
high-speed root hubs will always be resumed when the system wakes up,
even if they were suspended before the system went to sleep.  If this
weren't done then EHCI port handover wouldn't work, since it is called
when the EHCI root hub is resumed.

Finally, a comment is added to the hub driver explaining the khubd has
to be freezable; if it weren't frozen then it could interfere with
port handover.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3bb1af52
  15. 03 4月, 2008 1 次提交
  17. 02 2月, 2008 6 次提交
  19. 20 10月, 2007 1 次提交
  21. 13 7月, 2007 4 次提交
  23. 28 4月, 2007 1 次提交
  25. 10 3月, 2007 1 次提交
  27. 17 2月, 2007 1 次提交
  29. 08 2月, 2007 5 次提交
  31. 02 12月, 2006 3 次提交
    • A
      EHCI: Fix root-hub and port suspend/resume problems · 8c03356a
      由 Alan Stern 提交于 
      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: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8c03356a
    • D
      USB: add ehci_hcd.ignore_oc parameter · 93f1a47c
      由 David Brownell 提交于 
      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: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      93f1a47c
    • D
      USB: EHCI hooks for high speed electrical tests · f0d7f273
      由 David Brownell 提交于 
      EHCI hooks for high speed electrical tests of the root hub ports.

The expectation is that a usermode program actually triggers the test,
making the same control request it would make for an external hub.
Tests for peripheral upstream ports would issue a different request.
In all cases, the hardware needs re-initialization before it could
be used "normally" again (e.g. unplug/replug, rmmod/modprobe).
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      f0d7f273
  33. 18 10月, 2006 1 次提交