1. 14 Mar, 2011 16 commits
    • Sarah Sharp's avatar
      xhci: Always use usb_hcd in URB instead of converting xhci_hcd. · 214f76f7
      Sarah Sharp authored
      Make sure to call into the USB core's link, unlink, and giveback URB
      functions with the usb_hcd pointer found by using urb->dev->bus.  This
      will avoid confusion later, when the xHCI driver will deal with URBs from
      two separate buses (the USB 3.0 roothub and the faked USB 2.0 roothub).
      
      Assume xhci_urb_dequeue() will be called with the proper usb_hcd.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      214f76f7
    • Sarah Sharp's avatar
      xhci: Modify check for TT info. · aa1b13ef
      Sarah Sharp authored
      Commit d199c96d by Alan Stern ensured that low speed and full speed
      devices below a high speed hub without a transaction translator (TT) would
      never get enumerated.  Simplify the check for a TT in the xHCI virtual
      device allocation to only check if the usb_device references a parent's
      TT.
      
      Make sure not to set the TT information on LS/FS devices directly
      connected to the roothub.  The xHCI host doesn't really have a TT, and the
      host will throw an error when those virtual device TT fields are set for a
      device connected to the roothub.  We need this check because the xHCI
      driver will shortly register two roothubs: a USB 2.0 roothub and a USB 3.0
      roothub.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      aa1b13ef
    • Sarah Sharp's avatar
      usb: Make USB 3.0 roothub have a SS EP comp descriptor. · 22c6a35d
      Sarah Sharp authored
      Make the USB 3.0 roothub registered by the USB core have a SuperSpeed
      Endpoint Companion Descriptor after the interrupt endpoint.  All USB 3.0
      devices are required to have this, and the USB 3.0 bus specification
      (section 10.13.1) says which values the descriptor should have.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      22c6a35d
    • Sarah Sharp's avatar
      USB: Clear "warm" port reset change. · c7061574
      Sarah Sharp authored
      In USB 3.0, there are two types of resets: a "hot" port reset and a "warm"
      port reset.  The hot port reset is always tried first, and involves
      sending the reset signaling for a shorter amount of time.  But sometimes
      devices don't respond to the hot reset, and a "Bigger Hammer" is needed.
      
      External hubs and roothubs will automatically try a warm reset when the
      hot reset fails, and they will set a status change bit to indicate when
      there is a "BH reset" change.  Make sure the USB core clears that port
      status change bit, or we'll get lots of status change notifications on the
      interrupt endpoint of the USB 3.0 hub.
      
      (Side note: you may be confused why the USB 3.0 spec calls the same type
      of reset "warm reset" in some places and "BH reset" in other places.  "BH"
      reset is supposed to stand for "Big Hammer" reset, but it also stands for
      "Brad Hosler".  Brad died shortly after the USB 3.0 bus specification was
      started, and they decided to name the reset after him.  The suggestion was
      made shortly before the spec was finalized, so the wording is a bit
      inconsistent.)
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      c7061574
    • John Youn's avatar
      USB 3.0 Hub Changes · dbe79bbe
      John Youn authored
      Update the USB core to deal with USB 3.0 hubs.  These hubs have a slightly
      different hub descriptor than USB 2.0 hubs, with a fixed (rather than
      variable length) size.  Change the USB core's hub descriptor to have a
      union for the last fields that differ.  Change the host controller drivers
      that access those last fields (DeviceRemovable and PortPowerCtrlMask) to
      use the union.
      
      Translate the new version of the hub port status field into the old
      version that khubd understands.  (Note: we need to fix it to translate the
      roothub's port status once we stop converting it to USB 2.0 hub status
      internally.)
      
      Add new code to handle link state change status.  Send out new control
      messages that are needed for USB 3.0 hubs, like Set Hub Depth.
      
      This patch is a modified version of the original patch submitted by John
      Youn.  It's updated to reflect the removal of the "bitmap" #define, and
      change the hub descriptor accesses of a couple new host controller
      drivers.
      Signed-off-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
      Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
      Cc: Tony Olech <tony.olech@elandigitalsystems.com>
      Cc: "Robert P. J. Day" <rpjday@crashcourse.ca>
      Cc: Max Vozeler <mvz@vozeler.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Cc: Rodolfo Giometti <giometti@linux.it>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Anton Vorontsov <avorontsov@mvista.com>
      Cc: Sebastian Siewior <bigeasy@linutronix.de>
      Cc: Lothar Wassmann <LW@KARO-electronics.de>
      Cc: Olav Kongas <ok@artecdesign.ee>
      Cc: Martin Fuzzey <mfuzzey@gmail.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      dbe79bbe
    • Sarah Sharp's avatar
      xhci: Remove references to HC_STATE_RUNNING. · ad73dff3
      Sarah Sharp authored
      The USB core will set hcd->state to HC_STATE_RUNNING before calling
      xhci_run, so there's no point in setting it twice.  The USB core also
      doesn't pay attention to HC_STATE_RUNNING on the resume path anymore; it
      uses HCD_RH_RUNNING(), which looks at hcd->flags & (1U <<
      HCD_FLAG_RH_RUNNING.  Therefore, it's safe to remove the state set in
      xhci_bus_resume().
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      ad73dff3
    • Sarah Sharp's avatar
      usb: Initialize hcd->state roothubs. · 4814030c
      Sarah Sharp authored
      We would like to allow host controller drivers to stop using hcd->state.
      Unfortunately, some host controller drivers use hcd->state as an
      implicit way of telling the core that a controller has died.  The
      roothub registration functions must assume the host died if hcd->state
      equals HC_STATE_HALT.
      
      To facilitate drivers that don't want to set hcd->state to
      HC_STATE_RUNNING in their initialization routines, we set the state to
      running before calling the host controller's start function.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      4814030c
    • Sarah Sharp's avatar
      xhci: Remove references to HC_STATE_HALT. · ac04e6ff
      Sarah Sharp authored
      The xHCI driver doesn't ever test hcd->state for HC_STATE_HALT.  The USB
      core recently stopped using it internally, so there's no point in setting
      it in the driver.  We still need to set HC_STATE_RUNNING in order to make
      it past the USB core's hcd->state check in register_roothub().
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      ac04e6ff
    • Andiry Xu's avatar
      xHCI: prolong host controller halt time limit · bdfca502
      Andiry Xu authored
      xHCI 1.0 spec specifies the xHC shall halt within 16ms after software clears
      Run/Stop bit. In xHCI 0.96 spec the time limit is 16 microframes (2ms), it's
      too short and often cause dmesg shows "Host controller not halted, aborting
      reset." message when rmmod xhci-hcd.
      
      Modify the time limit to comply with xHCI 1.0 specification and prevents the
      warning message showing when remove xhci-hcd.
      Signed-off-by: default avatarAndiry Xu <andiry.xu@amd.com>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      bdfca502
    • Andiry Xu's avatar
      xHCI: Remove redundant variable in xhci_resume() · 019a35f1
      Andiry Xu authored
      Set hcd->state = HC_STATE_SUSPENDED if there is a power loss during system
      resume or the system is hibernated, otherwise leave it be. The variable
      old_state is redundant and made an unreachable code path, so remove it.
      Signed-off-by: default avatarAndiry Xu <andiry.xu@amd.com>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      019a35f1
    • Sarah Sharp's avatar
      xhci: Rename variables and reduce register reads. · 518e848e
      Sarah Sharp authored
      The xhci_bus_suspend() and xhci_bus_resume() functions are a bit hard to
      read, because they have an ambiguously named variable "port".  Rename it
      to "port_index".  Introduce a new temporary variable, "max_ports" that
      holds the maximum number of roothub ports the host controller supports.
      This will reduce the number of register reads, and make it easy to change
      the maximum number of ports when there are two roothubs.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      518e848e
    • Sarah Sharp's avatar
      xhci: Rework port suspend structures for limited ports. · 1d5810b6
      Sarah Sharp authored
      The USB core only allows up to 31 (USB_MAXCHILDREN) ports under a roothub.
      The xHCI driver keeps track of which ports are suspended, which ports have
      a suspend change bit set, and what time the port will be done resuming.
      It keeps track of the first two by setting a bit in a u32 variable,
      suspended_ports or port_c_suspend.  The xHCI driver currently assumes we
      can have up to 256 ports under a roothub, so it allocates an array of 8
      u32 variables for both suspended_ports and port_c_suspend.  It also
      allocates a 256-element array to keep track of when the ports will be done
      resuming.
      
      Since we can only have 31 roothub ports, we only need to use one u32 for
      each of the suspend state and change variables.  We simplify the bit math
      that's trying to index into those arrays and set the correct bit, if we
      assume wIndex never exceeds 30.  (wIndex is zero-based after it's
      decremented from the value passed in from the USB core.)  Finally, we
      change the resume_done array to only hold 31 elements.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Andiry Xu <andiry.xu@amd.com>
      1d5810b6
    • Sarah Sharp's avatar
      USB: Fix usb_add_hcd() checkpatch errors. · abc4f9b0
      Sarah Sharp authored
      The irq enabling code is going to be refactored into a new function, so
      clean up some checkpatch errors before moving it.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      abc4f9b0
    • Sarah Sharp's avatar
      USB: Remove bitmap #define from hcd.h · da13051c
      Sarah Sharp authored
      Using a #define to redefine a common variable name is a bad thing,
      especially when the #define is in a header.  include/linux/usb/hcd.h
      redefined bitmap to DeviceRemovable to avoid typing a long field in the
      hub descriptor.  This has unintended side effects for files like
      drivers/usb/core/devio.c that include that file, since another header
      included after hcd.h has different variables named bitmap.
      
      Remove the bitmap #define and replace instances of it in the host
      controller code.  Cleanup the spaces around function calls and square
      brackets while we're at it.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
      Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
      Cc: Tony Olech <tony.olech@elandigitalsystems.com>
      Cc: "Robert P. J. Day" <rpjday@crashcourse.ca>
      Cc: Max Vozeler <mvz@vozeler.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Cc: Rodolfo Giometti <giometti@linux.it>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Anton Vorontsov <avorontsov@mvista.com>
      Cc: Sebastian Siewior <bigeasy@linutronix.de>
      Cc: Lothar Wassmann <LW@KARO-electronics.de>
      Cc: Olav Kongas <ok@artecdesign.ee>
      Cc: Martin Fuzzey <mfuzzey@gmail.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      da13051c
    • Sarah Sharp's avatar
      xhci: Remove old no-op test. · 0b8ca72a
      Sarah Sharp authored
      The test of placing a number of command no-ops on the command ring and
      counting the number of no-op events that were generated was only used
      during the initial xHCI driver bring up.  This test is no longer used, so
      delete it.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      0b8ca72a
    • Sarah Sharp's avatar
      usb: Always return 0 or -EBUSY to the runtime PM core. · db7c7c0a
      Sarah Sharp authored
      The PM core reacts badly when the return code from usb_runtime_suspend()
      is not 0, -EAGAIN, or -EBUSY.  The PM core regards this as a fatal error,
      and refuses to run anymore PM helper functions.  In particular,
      usbfs_open() and other usbfs functions will fail because the PM core will
      return an error code when usb_autoresume_device() is called.  This causes
      libusb and/or lsusb to either hang or segfault.
      
      If a USB device cannot suspend for some reason (e.g. a hub doesn't report
      it has remote wakeup capabilities), we still want lsusb and other
      userspace programs to work.  So return -EBUSY, which will fill people's
      log files with failed tries, but will ensure userspace still works.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      db7c7c0a
  2. 11 Mar, 2011 7 commits
  3. 09 Mar, 2011 3 commits
  4. 07 Mar, 2011 7 commits
    • Lars-Peter Clausen's avatar
      ARM: s3c24xx: Switch to common GPIO controlled UDC pullup implementation · e27c3c5c
      Lars-Peter Clausen authored
      Currently all boards using the s3c2410_udc driver use a GPIO to control the
      state of the pullup, as a result the same code is reimplemented in each board
      This patch changes these boards to use the common implementation for GPIO
      controlled pullup in the UDC driver.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Acked-by: default avatarVasily Khoruzhick <anarsoul@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      e27c3c5c
    • Lars-Peter Clausen's avatar
      USB: s3c2410_udc: Add common implementation for GPIO controlled pullups · a74022a5
      Lars-Peter Clausen authored
      Currently all boards using the s3c2410_udc driver use a GPIO to control the
      state of the pullup, as a result the same code is reimplemented in each board
      file.
      This patch adds support for using a GPIO to control the pullup state to the udc
      driver, so the boards can use a common implementation.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      a74022a5
    • Anand Gadiyar's avatar
      arm: omap4: 4430sdp: drop ehci support · 09173b58
      Anand Gadiyar authored
      Most revisions of the OMAP4 Blaze/SDP platform do not have
      the EHCI signals routed by default. The pads are routed
      for the alternate HSI functionality instead, and explicit
      board modifications are needed to route the signals to
      the USB PHY on the board.
      
      Also, turning on the PHY connected to the EHCI port causes
      a board reboot during bootup due to an unintended short
      on the rails - this affects many initial revisions of the
      board, and needs a minor board mod to fix (or as a
      workaround, one should not attempt to power on the
      USB PHY).
      
      Given that these boards need explicit board mods to even
      get EHCI working (separate from the accidental short above),
      we should not attempt to enable EHCI by default.
      
      So drop the EHCI support from the board files for the
      Blaze/SDP platforms.
      Signed-off-by: default avatarAnand Gadiyar <gadiyar@ti.com>
      Cc: Keshava Munegowda <keshava_mgowda@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      09173b58
    • Sergei Shtylyov's avatar
      USB: OHCI: use pci_dev->revision · fa417c36
      Sergei Shtylyov authored
      Commit ab1666c1 (USB: quirk PLL power down mode)
      added code that reads the revision ID from the PCI configuration register while
      it's stored by PCI subsystem in the 'revision' field of 'struct pci_dev'...
      Signed-off-by: default avatarSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      fa417c36
    • Pavankumar Kondeti's avatar
      USB: Rename "msm72k_otg.c" to "msm_otg.c" · dfb2130c
      Pavankumar Kondeti authored
      This driver is used across all MSM SoCs.  Hence give a generic name.
      All Functions and strutures are also using "msm_otg" as prefix.
      Signed-off-by: default avatarPavankumar Kondeti <pkondeti@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      dfb2130c
    • Arvid Brodin's avatar
      usb/isp1760: Fix crash when unplugging bug · d3cf2a8d
      Arvid Brodin authored
      This fixes a problem with my previous patch series where there's a great
      risk that the kernel will crash when unplugging interrupt devices from
      the USB port. These lines must have got missing when I rebased the
      patches from the older kernel I was working with to 2.6.37 and 2.6-next:
      
      This fixes a bug where the kernel may crash if you unplug a USB device
      that has active interrupt transfers.
      Signed-off-by: default avatarArvid Brodin <arvid.brodin@enea.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      d3cf2a8d
    • Alan Stern's avatar
      USB: move usbcore away from hcd->state · 9b37596a
      Alan Stern authored
      The hcd->state variable is a disaster.  It's not clearly owned by
      either usbcore or the host controller drivers, and they both change it
      from time to time, potentially stepping on each other's toes.  It's
      not protected by any locks.  And there's no mechanism to prevent it
      from going through an invalid transition.
      
      This patch (as1451) takes a first step toward fixing these problems.
      As it turns out, usbcore uses hcd->state for essentially only two
      things: checking whether the controller's root hub is running and
      checking whether the controller has died.  Therefore the patch adds
      two new atomic bitflags to the hcd structure, to store these pieces of
      information.  The new flags are used only by usbcore, and a private
      spinlock prevents invalid combinations (a dead controller's root hub
      cannot be running).
      
      The patch does not change the places where usbcore sets hcd->state,
      since HCDs may depend on them.  Furthermore, there is one place in
      usb_hcd_irq() where usbcore still must use hcd->state: An HCD's
      interrupt handler can implicitly indicate that the controller died by
      setting hcd->state to HC_STATE_HALT.  Nevertheless, the new code is a
      big improvement over the current code.
      
      The patch makes one other change.  The hcd_bus_suspend() and
      hcd_bus_resume() routines now check first whether the host controller
      has died; if it has then they return immediately without calling the
      HCD's bus_suspend or bus_resume methods.
      
      This fixes the major problem reported in Bugzilla #29902: The system
      fails to suspend after a host controller dies during system resume.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Tested-by: default avatarAlex Terekhov <a.terekhov@gmail.com>
      CC: <stable@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      9b37596a
  5. 03 Mar, 2011 5 commits
  6. 01 Mar, 2011 2 commits
    • Yoshihiro Shimoda's avatar
      usb: EHCI, OHCI: Add configuration for the SH USB controller · 60b0bf0f
      Yoshihiro Shimoda authored
      The SH EHCI/OHCI driver hardcoded the CPU type in {ehci,ohci}-hcd.c.
      So if we will add the new CPU, we had to add to the hcd driver each time.
      The patch adds the CONFIG_USB_{EHCI,OHCI}_SH configuration. So if we
      want to use the SH EHCI/OHCI, we only enable the configuration.
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      60b0bf0f
    • Andiry Xu's avatar
      USB host: Move AMD PLL quirk to pci-quirks.c · ad93562b
      Andiry Xu authored
      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: default avatarAndiry Xu <andiry.xu@amd.com>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Cc: Alex He <alex.he@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      ad93562b