1. 31 3月, 2011 1 次提交
  2. 02 3月, 2011 1 次提交
    • A
      USB host: Move AMD PLL quirk to pci-quirks.c · ad93562b
      Andiry Xu 提交于
      This patch moves the AMD PLL quirk code in OHCI/EHCI driver to pci-quirks.c,
      and exports the functions to be used by xHCI driver later.
      
      AMD PLL quirk disable the optional PM feature inside specific
      SB700/SB800/Hudson-2/3 platforms under the following conditions:
      
      1. If an isochronous device is connected to OHCI/EHCI/xHCI port and is active;
      2. Optional PM feature that powers down the internal Bus PLL when the link is
         in low power state is enabled.
      
      Without AMD PLL quirk, USB isochronous stream may stutter or have breaks
      occasionally, which greatly impair the performance of audio/video streams.
      
      Currently AMD PLL quirk is implemented in OHCI and EHCI driver, and will be
      added to xHCI driver too. They are doing similar things actually, so move
      the quirk code to pci-quirks.c, which has several advantages:
      
      1. Remove duplicate defines and functions in OHCI/EHCI (and xHCI) driver and
         make them cleaner;
      2. AMD chipset information will be probed only once and then stored.
         Currently they're probed during every OHCI/EHCI initialization, move
         the detect code to pci-quirks.c saves the repeat detect cost;
      3. Build up synchronization among OHCI/EHCI/xHCI driver. In current
         code, every host controller enable/disable PLL only according to
         its own status, and may enable PLL while there is still isoc transfer on
         other HCs. Move the quirk to pci-quirks.c prevents this issue.
      Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Cc: Alex He <alex.he@amd.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ad93562b
  3. 18 2月, 2011 1 次提交
  4. 05 2月, 2011 1 次提交
    • A
      USB host: Move AMD PLL quirk to pci-quirks.c · b7d5b439
      Andiry Xu 提交于
      This patch moves the AMD PLL quirk code in OHCI/EHCI driver to pci-quirks.c,
      and exports the functions to be used by xHCI driver later.
      
      AMD PLL quirk disable the optional PM feature inside specific
      SB700/SB800/Hudson-2/3 platforms under the following conditions:
      
      1. If an isochronous device is connected to OHCI/EHCI/xHCI port and is active;
      2. Optional PM feature that powers down the internal Bus PLL when the link is
         in low power state is enabled.
      
      Without AMD PLL quirk, USB isochronous stream may stutter or have breaks
      occasionally, which greatly impair the performance of audio/video streams.
      
      Currently AMD PLL quirk is implemented in OHCI and EHCI driver, and will be
      added to xHCI driver too. They are doing similar things actually, so move
      the quirk code to pci-quirks.c, which has several advantages:
      
      1. Remove duplicate defines and functions in OHCI/EHCI (and xHCI) driver and
         make them cleaner;
      2. AMD chipset information will be probed only once and then stored.
         Currently they're probed during every OHCI/EHCI initialization, move
         the detect code to pci-quirks.c saves the repeat detect cost;
      3. Build up synchronization among OHCI/EHCI/xHCI driver. In current
         code, every host controller enable/disable PLL only according to
         its own status, and may enable PLL while there is still isoc transfer on
         other HCs. Move the quirk to pci-quirks.c prevents this issue.
      Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Cc: Alex He <alex.he@amd.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b7d5b439
  5. 11 12月, 2010 1 次提交
    • A
      USB: EHCI: ASPM quirk of ISOC on AMD SB800 · 05570297
      Alex He 提交于
      When ASPM PM Feature is enabled on UMI link, devices that use ISOC stream of
      data transfer may be exposed to longer latency causing less than optimal per-
      formance of the device. The longer latencies are normal and are due to link
      wake time coming out of low power state which happens frequently to save
      power when the link is not active.
      The following code will make exception for certain features of ASPM to be by
      passed and keep the logic normal state only when the ISOC device is connected
      and active. This change will allow the device to run at optimal performance
      yet minimize the impact on overall power savings.
      Signed-off-by: NAlex He <alex.he@amd.com>
      Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      05570297
  6. 17 11月, 2010 1 次提交
    • A
      USB: EHCI: AMD periodic frame list table quirk · 3d091a6f
      Andiry Xu 提交于
      On AMD SB700/SB800/Hudson-2/3 platforms, USB EHCI controller may read/write
      to memory space not allocated to USB controller if there is longer than
      normal latency on DMA read encountered. In this condition the exposure will
      be encountered only if the driver has following format of Periodic Frame
      List link pointer structure:
      
      For any idle periodic schedule, the Frame List link pointers that have the
      T-bit set to 1 intending to terminate the use of frame list link pointer
      as a physical memory pointer.
      
      Idle periodic schedule Frame List Link pointer shoule be in the following
      format to avoid the issue:
      
      Frame list link pointer should be always contains a valid pointer to a
      inactive QHead with T-bit set to 0.
      Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
      Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3d091a6f
  7. 11 8月, 2010 7 次提交
  8. 21 5月, 2010 2 次提交
    • A
      USB: EHCI: fix controller wakeup flag settings during suspend · 16032c4f
      Alan Stern 提交于
      This patch (as1380) fixes a bug in the wakeup settings for EHCI host
      controllers.  When the controller is suspended, if it isn't enabled
      for remote wakeup then we have to turn off all the port wakeup flags.
      Disabling PCI PME# isn't good enough, because some systems (Intel)
      evidently use alternate wakeup signalling paths.
      
      In addition, the patch improves the handling of the Intel Moorestown
      hardware by performing various power-up and power-down delays just
      once instead of once for each port (i.e., the delays are moved outside
      of the port loops).  This requires extra code, but the total delay
      time is reduced.
      
      There are also a few additional minor cleanups.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NOndrej Zary <linux@rainbow-software.org>
      CC: Alek Du <alek.du@intel.com>
      CC: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      16032c4f
    • A
      USB: remove bogus USB_PORT_FEAT_*_SPEED symbols · 288ead45
      Alan Stern 提交于
      This patch (as1348) removes the bogus
      USB_PORT_FEAT_{HIGHSPEED,SUPERSPEED} symbols from ch11.h.  No such
      features are defined by the USB spec.  (There is a PORT_LOWSPEED
      feature, but the spec doesn't mention it except to say that host
      software should never use it.)  The speed indicators are port
      statuses, not port features.
      
      As a temporary workaround for the xhci-hcd driver, a fictional
      USB_PORT_STAT_SUPER_SPEED symbol is added.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      288ead45
  9. 23 4月, 2010 1 次提交
  10. 19 3月, 2010 1 次提交
  11. 01 12月, 2009 1 次提交
  12. 23 9月, 2009 4 次提交
    • A
      USB: EHCI: rescan the queue after an unlink · 3a44494e
      Alan Stern 提交于
      This patch (as1280) fixes an obscure bug in ehci-hcd's dequeuing logic
      for async URBs.  If a later URB is unlinked and the completion
      routine unlinks an earlier URB, then the earlier URB won't be given
      back in a timely manner because the endpoint queue isn't rescanned as
      it should be.
      
      Similar bugs occur if an endpoint is reset or a halt is cleared while
      a completion routine is running, because the subroutines don't test
      for the COMPLETING state.
      
      All these problems are solved by adding a new needs_rescan flag to the
      ehci_qh structure.  If the flag is set while scanning through an idle
      QH, the scan will be repeated.  If the QH isn't idle then an unlink
      cycle will be initiated, and the proper action will be taken when it
      becomes idle.
      
      Also, an unnecessary test is removed from qh_link_async(): That
      routine is never called if the QH's state isn't IDLE.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: David Brownell <david-b@pacbell.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3a44494e
    • A
      USB: EHCI: Add Intel Moorestown EHCI controller HOSTPCx extensions and support phy low power mode · 331ac6b2
      Alek Du 提交于
      The Intel Moorestown EHCI controller supports non-standard HOSTPCx register
      extension. This register controls the LPM behaviour and controls the behaviour
      of each USB port.
      Signed-off-by: NJacob Pan <jacob.jun.pan@intel.com>
      Signed-off-by: NAlek Du <alek.du@intel.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      331ac6b2
    • A
      USB: EHCI: split ehci_qh into hw and sw parts · 3807e26d
      Alek Du 提交于
      The ehci_qh structure merged hw and sw together which is not good:
      1. More and more items are being added into ehci_qh, the ehci_qh software
         part are unnecessary to be allocated in DMA qh_pool.
      2. If HCD has local SRAM, the sw part will consume it too, and it won't
         bring any benefit.
      3. For non-cache-coherence system, the entire ehci_qh is uncachable, actually
         we only need the hw part to be uncacheable. Spliting them will let the sw
         part to be cacheable.
      Signed-off-by: NAlek Du <alek.du@intel.com>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      CC: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3807e26d
    • A
      USB: EHCI: add need_io_watchdog flag to ehci_hcd · 403dbd36
      Alek Du 提交于
      Basically the io watchdog is only useful for those quirk HCDs. For most
      good ones, it only brings unnecessary wakeups.  At least, I know the
      Intel EHCI HCDs should turn off the flag.
      Signed-off-by: NAlek Du <alek.du@intel.com>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      403dbd36
  13. 21 9月, 2009 1 次提交
  14. 13 7月, 2009 1 次提交
  15. 16 6月, 2009 1 次提交
  16. 25 3月, 2009 3 次提交
  17. 28 2月, 2009 1 次提交
  18. 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
  19. 01 12月, 2008 1 次提交
  20. 18 10月, 2008 3 次提交
  21. 26 7月, 2008 1 次提交
  22. 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
  23. 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
  24. 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
  25. 02 2月, 2008 1 次提交
    • D
      usb: ehci should use u16 for isochronous intervals · c06d4dcf
      David Brownell 提交于
      While most isochronous endpoints have short polling intervals, the
      EHCI driver won't necessarily handle larger ones correctly.
      
      This patch switches to use a "u16" to represent those periods, not
      a u8, since it can always work:  the largest expressible period
      is 2^15 units ... not the previous too-short limit of 128 frames
      (full or low speeds) or microframes (high speed, 32 frames).
      
      This bug is essentially theoretical, since the few ISO endpoints
      I've seen which don't use one transfer per frame are high speed
      ones using more than that (including high bandwidth, 24 KB/msec).
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c06d4dcf