1. 08 3月, 2011 5 次提交
    • A
      arm: omap4: 4430sdp: drop ehci support · 09173b58
      Anand Gadiyar 提交于
      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: NAnand Gadiyar <gadiyar@ti.com>
      Cc: Keshava Munegowda <keshava_mgowda@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      09173b58
    • S
      USB: OHCI: use pci_dev->revision · fa417c36
      Sergei Shtylyov 提交于
      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: NSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      fa417c36
    • P
      USB: Rename "msm72k_otg.c" to "msm_otg.c" · dfb2130c
      Pavankumar Kondeti 提交于
      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: NPavankumar Kondeti <pkondeti@codeaurora.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      dfb2130c
    • A
      usb/isp1760: Fix crash when unplugging bug · d3cf2a8d
      Arvid Brodin 提交于
      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: NArvid Brodin <arvid.brodin@enea.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d3cf2a8d
    • A
      USB: move usbcore away from hcd->state · 9b37596a
      Alan Stern 提交于
      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: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NAlex Terekhov <a.terekhov@gmail.com>
      CC: <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      9b37596a
  2. 03 3月, 2011 5 次提交
  3. 02 3月, 2011 2 次提交
    • Y
      usb: EHCI, OHCI: Add configuration for the SH USB controller · 60b0bf0f
      Yoshihiro Shimoda 提交于
      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: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      60b0bf0f
    • 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
  4. 01 3月, 2011 28 次提交