1. 04 5月, 2011 5 次提交
  2. 03 5月, 2011 22 次提交
  3. 30 4月, 2011 4 次提交
  4. 15 4月, 2011 1 次提交
    • G
      Revert "USB: isp1760-hcd: move imask clear after pending work is done" · 753d8534
      Greg Kroah-Hartman 提交于
      This reverts commit 58085446.
      
      To quote Richard:
      	I don't think this should be mainlined. It was a
      	misunderstanding on my part.  If you see all the other hdc
      	drivers in the same location, they all do the same thing (i.e.
      	clear the interrupt status first, then do the work) that
      	"glitch" I think I saw was actually two back-to-back
      	interrupts.
      
      	Sebastian (the original author of isp1760) explained it to me a
      	few days after my submission.
      
      	sorry for the confusion
      
      Cc: Richard Retanubun <RichardRetanubun@ruggedcom.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      753d8534
  5. 14 4月, 2011 8 次提交
    • G
      USB: ohci: add bus glue for the Atheros AR71XX/AR7240 SoCs · 90e6ca5c
      Gabor Juhos 提交于
      The Atheros AR71XX/AR7240 SoCs have a built-in OHCI controller.
      This patch adds the necessary glue code to make the generic OHCI
      driver usable for them.
      Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
      Signed-off-by: NImre Kaloz <kaloz@openwrt.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      90e6ca5c
    • G
      USB: ehci: add workaround for Synopsys HC bug · 2f7ac6c1
      Gabor Juhos 提交于
      A Synopsys USB core used in various SoCs has a bug which might cause
      that the host controller not issuing ping.
      
      When software uses the Doorbell mechanism to remove queue heads, the
      host controller still has references to the removed queue head even
      after indicating an Interrupt on Async Advance. This happens if the last
      executed queue head's Next Link queue head is removed.
      
      Consequences of the defect:
      The Host controller fetches the removed queue head, using memory that
      would otherwise be deallocated.This results in incorrect transactions on
      both the USB and system memory. This may result in undefined behavior.
      
      Workarounds:
      
      1) If no queue head is active (no Status field's Active bit is set)
      after removing the queue heads, the software can write one of the valid
      queue head addresses to the ASYNCLISTADDR register and deallocate the
      removed queue head's memory after 2 microframes.
      
      If one or more of the queue heads is active (the Active bit is set in
      the Status field) after removing the queue heads, the software can delay
      memory deallocation after time X, where X is the time required for the
      Host Controller to go through all the queue heads once. X varies with
      the number of queue heads and the time required to process periodic
      transactions: if more periodic transactions must be performed, the Host
      Controller has less time to process asynchronous transaction processing.
      
      2) Do not use the Doorbell mechanism to remove the queue heads. Disable
      the Asynchronous Schedule Enable bit instead.
      
      The bug has been discussed on the linux-usb-devel mailing-list
      four years ago, the original thread can be found here:
      http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg45345.html
      
      This patch implements the first workaround as suggested by David Brownell.
      
      The built-in USB host controller of the Atheros AR7130/AR7141/AR7161 SoCs
      requires this to work properly.
      Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2f7ac6c1
    • G
      USB: ehci: add bus glue for the Atheros AR71XX/AR724X/AR91XX SoCs · 502fa841
      Gabor Juhos 提交于
      The Atheros AR71XX/AR91XX SoCs have a built-in EHCI controller.
      This patch adds the necessary glue code to make the generic EHCI
      driver usable for them.
      Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
      Signed-off-by: NImre Kaloz <kaloz@openwrt.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      502fa841
    • A
      xHCI: Implement AMD PLL quirk · c41136b0
      Andiry Xu 提交于
      This patch disable the optional PM feature inside the Hudson3 platform under
      the following conditions:
      
      1. If an isochronous device is connected to 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.
      
      The PM feature needs to be disabled to eliminate PLL startup delays when the
      link comes out of low power state. The performance of DMA data transfer could
      be impacted if system delay were encountered and in addition to the PLL start
      up delays. Disabling the PM would leave room for unpredictable system delays
      in order to guarantee uninterrupted data transfer to isochronous audio or
      video stream devices that require time sensitive information. If data in an
      audio/video stream was interrupted then erratic audio or video performance
      may be encountered.
      
      AMD PLL quirk is already implemented in OHCI/EHCI driver. After moving the
      quirk code to pci-quirks.c and export them, xHCI driver can call it directly
      without having the quirk implementation in itself.
      Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      c41136b0
    • S
      xhci: Tell USB core both roothubs lost power. · fedd383e
      Sarah Sharp 提交于
      On a resume, when the power is lost during hibernate, the USB core will
      call hub_reset_resume for the xHCI USB 2.0 roothub, but not for the USB
      3.0 roothub:
      
      [  164.748310] usb usb1: root hub lost power or was reset
      [  164.748353] usb usb2: root hub lost power or was reset
      [  164.748487] usb usb3: root hub lost power or was reset
      [  164.748488] xhci_hcd 0000:01:00.0: Stop HCD
      ...
      [  164.870039] hub 4-0:1.0: hub_resume
      ...
      [  164.870054] hub 3-0:1.0: hub_reset_resume
      
      This causes issues later, because the USB core assumes the USB 3.0 hub
      attached to the USB 3.0 roothub is still active.  It attempts to queue a
      control URB for the external hub, which fails because all the device
      slot contexts were released when the USB 3.0 roothub lost power:
      
      [  164.980044] hub 4-1:1.0: hub_resume
      [  164.980047] xhci_hcd 0000:01:00.0: Get port status returned 0x10101
      [  164.980049] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980053] hub 3-0:1.0: port 1: status 0101 change 0001
      [  164.980056] hub 4-1:1.0: hub_port_status failed (err = -22)
      [  164.980060] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc90008948440, 32'h202e1, 4'hf);
      [  164.980062] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980066] xhci_hcd 0000:01:00.0: clear port connect change, actual port 0 status  = 0x2e1
      [  164.980069] hub 4-1:1.0: hub_port_status failed (err = -22)
      [  164.980072] xhci_hcd 0000:01:00.0: get port status, actual port 1 status  = 0x2a0
      [  164.980074] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980077] xhci_hcd 0000:01:00.0: Get port status returned 0x100
      [  164.980079] hub 4-1:1.0: hub_port_status failed (err = -22)
      [  164.980082] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980085] hub 4-1:1.0: hub_port_status failed (err = -22)
      [  164.980088] hub 4-1:1.0: port 4: status 0000 change 0000
      [  164.980091] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980094] hub 4-1:1.0: activate --> -22
      [  164.980113] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980117] hub 4-1:1.0: hub_port_status failed (err = -22)
      [  164.980119] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980123] hub 4-1:1.0: can't resume port 4, status -22
      [  164.980126] hub 4-1:1.0: port 4 status ffff.ffff after resume, -22
      [  164.980129] usb 4-1.4: can't resume, status -22
      [  164.980131] hub 4-1:1.0: logical disconnect on port 4
      
      This causes issues when a USB 3.0 hard drive is attached to the external
      USB 3.0 hub when the system is hibernated:
      
      [ 6249.849653] sd 8:0:0:0: [sdb] Unhandled error code
      [ 6249.849659] sd 8:0:0:0: [sdb]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
      [ 6249.849663] sd 8:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 2a 08 00 00 02 00
      [ 6249.849671] end_request: I/O error, dev sdb, sector 10760
      
      Make sure to inform the USB core that *both* xHCI roothubs lost power.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      fedd383e
    • D
      USB: xhci - also free streams when resetting devices · 2dea75d9
      Dmitry Torokhov 提交于
      Currently, when resetting a device, xHCI driver disables all but one
      endpoints and frees their rings, but leaves alone any streams that
      might have been allocated. Later, when users try to free allocated
      streams, we oops in xhci_setup_no_streams_ep_input_ctx() because
      ep->ring is NULL.
      
      Let's free not only rings but also stream data as well, so that
      calling free_streams() on a device that was reset will be safe.
      
      This should be queued for stable trees back to 2.6.35.
      Reviewed-by: NMicah Elizabeth Scott <micah@vmware.com>
      Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@kernel.org
      2dea75d9
    • J
      USB: Add initial S5P EHCI driver · 1bcc5aa8
      Joonyoung Shim 提交于
      This patch adds host USB high speed driver for samsung S5P series. This
      is initial driver and we need additional implementation to support some
      functions like power management.
      Signed-off-by: NJingoo Han <jg1.han@samsung.com>
      Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1bcc5aa8
    • F
      USB: Mark ehci_adjust_port_wakeup_flags as __maybe_unused · 0b0cd6c8
      Fabio Estevam 提交于
      Mark ehci_adjust_port_wakeup_flags as __maybe_unused to avoid the following
      warning when building the ehci-mxc driver:
      
        CC      drivers/usb/host/ehci-hcd.o
      drivers/usb/host/ehci-hub.c:130: warning: 'ehci_adjust_port_wakeup_flags' defined but not used
      
      Current ehci-mxc driver implementation does not support suspend/resume.
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0b0cd6c8