1. 23 9月, 2009 1 次提交
  2. 21 9月, 2009 1 次提交
  3. 13 7月, 2009 1 次提交
  4. 16 6月, 2009 1 次提交
  5. 25 3月, 2009 3 次提交
  6. 28 2月, 2009 1 次提交
  7. 08 1月, 2009 1 次提交
    • 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
  8. 01 12月, 2008 1 次提交
  9. 18 10月, 2008 3 次提交
  10. 26 7月, 2008 1 次提交
  11. 22 7月, 2008 1 次提交
    • D
      USB: ehci-hcd unlink speedups · b9638011
      David Brownell 提交于
      This patch fixes some performance bugs observed with some workloads
      when unlinking EHCI queue header (QH) descriptors from the async ring
      (control/bulk schedule).
      
      The mechanism intended to defer unlinking an empty QH (so there is no
      penalty in common cases where it's quickly reused) was not working as
      intended.  Sometimes the unlink was scheduled:
      
       - too quickly ... which can be a *strong* negative effect, since
         that QH becomes unavailable for immediate re-use;
      
       - too slowly ... wasting DMA cycles, usually a minor issue except
         for increased bus contention and power usage;
      
      Plus there was an extreme case of "too slowly":  a logical error in the
      IAA watchdog-timer conversion meant that sometimes the unlink never
      got scheduled.
      
      The fix replaces a simple counter with a timestamp derived from the
      controller's 8 KHz microframe counter, and adjusts the timer usage
      for some issues associated with HZ being less than 8K.
      
      (Based on a patch originally by Alan Stern, and good troubleshooting
      from  Leonid.)
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Leonid <leonidv11@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b9638011
  12. 04 7月, 2008 1 次提交
    • D
      USB: ehci - fix timer regression · 056761e5
      David Brownell 提交于
      This patch fixes a regression in the EHCI driver's TIMER_IO_WATCHDOG
      behavior.  The patch "USB: EHCI: add separate IAA watchdog timer" changed
      how that timer is handled, so that short timeouts on the remaining
      timer (unfortunately, overloaded) would never be used.
      
      This takes a more direct approach, reorganizing the code slightly to
      be explicit about only the I/O watchdog role now being overridable.
      It also replaces a now-obsolete comment describing older timer behavior.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Leonid <leonidv11@gmail.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      056761e5
  13. 30 5月, 2008 2 次提交
    • A
      USB: EHCI: fix remote-wakeup regression · d1f114d1
      Alan Stern 提交于
      This patch (as1097) fixes a bug in the remote-wakeup handling in
      ehci-hcd.  The driver currently does not keep track of whether the
      change-suspend feature is enabled for each port; the feature is
      automatically reset the first time it is read.  But recent changes to
      the hub driver require that the feature be read at least twice in
      order to work properly.
      
      A bit-vector is added for storing the change-suspend feature values.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d1f114d1
    • A
      USB: EHCI: fix up root-hub TT mess · a8e51775
      Alan Stern 提交于
      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: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      a8e51775
  14. 02 2月, 2008 6 次提交
  15. 21 8月, 2007 1 次提交
    • L
      Revert "USB: EHCI cpufreq fix" · 8eb891fc
      Linus Torvalds 提交于
      This reverts commit 196705c9.  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: NLinus Torvalds <torvalds@linux-foundation.org>
      8eb891fc
  16. 13 7月, 2007 5 次提交
  17. 10 2月, 2007 1 次提交
  18. 08 2月, 2007 3 次提交
  19. 02 12月, 2006 1 次提交
    • 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
  20. 18 10月, 2006 1 次提交
  21. 28 9月, 2006 3 次提交
  22. 21 3月, 2006 1 次提交