1. 23 2月, 2015 3 次提交
  2. 05 2月, 2015 1 次提交
    • B
      usb: musb: fix device hotplug behind hub · 9298b4aa
      Bin Liu 提交于
      The commit 889ad3b "usb: musb: try a race-free wakeup" breaks device
      hotplug enumeraitonn when the device is connected behind a hub while usb
      autosuspend is enabled.
      
      Adding finish_resume_work into runtime resume callback fixes the issue.
      
      Also resume root hub is required to resume the bus from runtime suspend,
      so move musb_host_resume_root_hub() back to its original location, where
      handles RESUME interrupt.
      Signed-off-by: NBin Liu <b-liu@ti.com>
      Tested-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      9298b4aa
  3. 03 2月, 2015 1 次提交
  4. 30 1月, 2015 3 次提交
    • A
      usb: musb: add omap-control dependency · fbba7db3
      Arnd Bergmann 提交于
      The omap musb front-end calls into the phy driver directly
      instead of using a generic phy interface, which causes a link
      error when the specific driver is not built-in:
      
      drivers/built-in.o: In function `omap2430_musb_disable':
      usb/musb/omap2430.c:480: undefined reference to `omap_control_usb_set_mode'
      drivers/built-in.o: In function `omap2430_musb_enable':
      usb/musb/omap2430.c:466: undefined reference to `omap_control_usb_set_mode'
      usb/musb/omap2430.c:447: undefined reference to `omap_control_usb_set_mode'
      drivers/built-in.o: In function `omap_musb_set_mailbox':
      usb/musb/omap2430.c:273: undefined reference to `omap_control_usb_set_mode'
      usb/musb/omap2430.c:304: undefined reference to `omap_control_usb_set_mode'
      drivers/built-in.o:(.debug_addr+0xbd9e0): more undefined references to `omap_control_usb_set_mode' follow
      
      This adds an explicit dependency.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: ca784be3 ("usb: start using the control module driver")
      Cc: <stable@vger.kernel.org> # v3.9+
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      fbba7db3
    • A
      usb: musb: add generic usb phy dependencies · a0cb12e2
      Arnd Bergmann 提交于
      Multiple musb glue drivers depend on the generic usb phy support,
      but fail to list it as a dependency in Kconfig. This results
      in build erros like:
      
      drivers/built-in.o: In function `am35x_remove':
      :(.text+0xadacc): undefined reference to `usb_phy_generic_unregister'
      drivers/built-in.o: In function `am35x_probe':
      :(.text+0xae1c8): undefined reference to `usb_phy_generic_register'
      :(.text+0xae244): undefined reference to `usb_phy_generic_unregister'
      drivers/built-in.o: In function `jz4740_remove':
      :(.text+0xaf648): undefined reference to `usb_phy_generic_unregister'
      drivers/built-in.o: In function `jz4740_musb_init':
      :(.text+0xaf694): undefined reference to `usb_phy_generic_register'
      
      This adds the ones that are missing.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      a0cb12e2
    • P
      usb: musb: gadget: use common is_selfpowered · dadac986
      Peter Chen 提交于
      Delete private selfpowered variable, and use common one.
      Signed-off-by: NPeter Chen <peter.chen@freescale.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      dadac986
  5. 27 1月, 2015 3 次提交
  6. 25 1月, 2015 1 次提交
  7. 15 1月, 2015 1 次提交
  8. 23 12月, 2014 5 次提交
    • S
      usb: musb: stuff leak of struct usb_hcd · 68693b8e
      Sebastian Andrzej Siewior 提交于
      since the split of host+gadget mode in commit 74c2e936 ("usb: musb:
      factor out hcd initalization") we leak the usb_hcd struct. We call now
      musb_host_cleanup() which does basically usb_remove_hcd() and also sets
      the hcd variable to NULL. Doing so makes the finall call to
      musb_host_free() basically a nop and the usb_hcd remains around for ever
      without anowner.
      This patch drops that NULL assignment for that reason.
      
      Fixes: 74c2e936 ("usb: musb: factor out hcd initalization")
      Cc: <stable@vger.kernel.org> # v3.11+
      Cc: Daniel Mack <zonque@gmail.com>
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      68693b8e
    • T
      usb: musb: Fix randconfig build issues for Kconfig options · c0442479
      Tony Lindgren 提交于
      Commit 82c02f58 ("usb: musb: Allow multiple glue layers to be
      built in") enabled selecting multiple glue layers, which in turn
      exposed things more for randconfig builds. If NOP_USB_XCEIV is
      built-in and TUSB6010 is a loadable module, we will get:
      
      drivers/built-in.o: In function `tusb_remove':
      tusb6010.c:(.text+0x16a817): undefined reference to `usb_phy_generic_unregister'
      drivers/built-in.o: In function `tusb_probe':
      tusb6010.c:(.text+0x16b24e): undefined reference to `usb_phy_generic_register'
      make: *** [vmlinux] Error 1
      
      Let's fix this the same way as commit 70c1ff4b ("usb: musb:
      tusb-dma can't be built-in if tusb is not").
      
      And while at it, let's not allow selecting the glue layers except
      on platforms really using them unless COMPILE_TEST is specified:
      
      - TUSB6010 is in practise only used on omaps
      
      - DSPS is only used on TI platforms
      
      - UX500 is only used on STE platforms
      
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Reported-by: NJim Davis <jim.epost@gmail.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      c0442479
    • R
      usb: musb: Fix a few off-by-one lengths · e87c3f80
      Rasmus Villemoes 提交于
      !strncmp(buf, "force host", 9) is true if and only if buf starts with
      "force hos". This was obviously not what was intended. The same error
      exists for "force full-speed", "force high-speed" and "test
      packet". Using strstarts avoids the error-prone hardcoding of the
      prefix length.
      
      For consistency, also change the other occurences of the !strncmp
      idiom.
      Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      e87c3f80
    • F
      usb: musb: blackfin: fix build break · b1d34783
      Felipe Balbi 提交于
      commit cc92f681 (usb: musb: Populate new IO
      functions for blackfin) added a typo which
      prevented MUSB's blackfin glue layer from being
      built. Due to lack of tests and compilers for
      that architecture, the typo ended up being
      merged and causing a build regression.
      
      Fix that here
      
      Cc: Tony Lindgren <tony@atomide.com>
      Reported-by: NFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      b1d34783
    • F
      usb: musb: debugfs: cope with blackfin's oddities · 449a7e99
      Felipe Balbi 提交于
      Blackfin's MUSB implementation lacks a bunch of
      registers which they end up not defining a macro
      for. In order to avoid build breaks, let's ifdef
      out some of the registers from our regdump debugfs
      utility so that we don't try to use those on
      Blackfin builds.
      Reported-by: NFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      449a7e99
  9. 25 11月, 2014 8 次提交
  10. 18 11月, 2014 4 次提交
    • G
      usb: musb: core: Disable the Interrupts till BABBLE is fully handled · f905bc68
      George Cherian 提交于
      Disable the MUSB interrupts till MUSB is recovered fully from BABBLE
      condition. There are chances that we could get multiple interrupts
      till the time the babble recover work gets scheduled. Sometimes
      this could even end up in an endless loop making MUSB itself unusable.
      Reported-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGeorge Cherian <george.cherian@ti.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      f905bc68
    • S
      usb: musb: musb_cppi41: recognize HS devices in hostmode · 1eec34e9
      Sebastian Andrzej Siewior 提交于
      There is a poll loop for max 25us for HS devices. Now guess what, I
      tested it in gadget mode and forgot about the little detail. Nobody seem
      to have it noticed…
      This patch adds the missing logic for hostmode so it is recognized in
      host and device mode properly.
      
      Fixes: 50aea6fc ("usb: musb: cppi41: fire hrtimer according to
      programmed channel length")
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      1eec34e9
    • R
      usb: musb: replace hard coded registers with defines · c2365ce5
      Roman Byshko 提交于
      musb registers can be dumped using the file regdump
      which is created in debugfs. Up to now  hard coded
      register addresses are used for that. Different glue
      layers however have different register addresses. The
      patch addresses this issue by substituting bare register
      addresses with defines.
      Signed-off-by: NRoman Byshko <rbyshko@gmail.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      c2365ce5
    • S
      usb: musb: core: make sure musb is in RPM_ACTIVE on resume · a1fc1920
      Sebastian Andrzej Siewior 提交于
      On am335x-evm with musb in host mode and using it as a wakeup source the
      following happens once the CPU comes out of suspend to ram:
      |PM: Wakeup source MPU_WAKE
      |PM: noirq resume of devices complete after 15.453 msecs
      |PM: early resume of devices complete after 2.222 msecs
      |PM: resume of devices complete after 507.351 msecs
      |Restarting tasks ...
      |------------[ cut here ]------------
      |WARNING: CPU: 0 PID: 322 at drivers/usb/core/urb.c:339 usb_submit_urb+0x494/0x4c8()
      |URB cc0db380 submitted while active
      |[<c0348e64>] (usb_submit_urb) from [<c0340f94>] (hub_activate+0x2b8/0x49c)
      |[<c0340f94>] (hub_activate) from [<c03411dc>] (hub_resume+0x14/0x1c)
      |[<c03411dc>] (hub_resume) from [<c034be10>] (usb_resume_interface.isra.4+0xdc/0x110)
      |[<c034be10>] (usb_resume_interface.isra.4) from [<c034beb0>] (usb_resume_both+0x6c/0x13c)
      |[<c034beb0>] (usb_resume_both) from [<c034cca4>] (usb_runtime_resume+0x10/0x14)
      |[<c034cca4>] (usb_runtime_resume) from [<c02bbd80>] (__rpm_callback+0x2c/0x60)
      |[<c02bbd80>] (__rpm_callback) from [<c02bbdd4>] (rpm_callback+0x20/0x74)
      |[<c02bbdd4>] (rpm_callback) from [<c02bcc48>] (rpm_resume+0x380/0x548)
      |[<c02bcc48>] (rpm_resume) from [<c02bcb00>] (rpm_resume+0x238/0x548)
      |[<c02bcb00>] (rpm_resume) from [<c02bd08c>] (__pm_runtime_resume+0x64/0x94)
      |[<c02bd08c>] (__pm_runtime_resume) from [<c034b5a4>] (usb_autopm_get_interface+0x18/0x5c)
      |[<c034b5a4>] (usb_autopm_get_interface) from [<c03438b8>] (hub_thread+0x10c/0x115c)
      |[<c03438b8>] (hub_thread) from [<c005a70c>] (kthread+0xbc/0xd8)
      |---[ end trace 036aa5fe78203142 ]---
      |hub 1-0:1.0: activate --> -16
      |hub 2-0:1.0: activate --> -16
      
      The reason for this backtrace is the attempt of the USB code to resume
      the HUB twice and thus enqueue the status URB twice.
      Alan Stern was a great help by explaining how the USB code supposed to
      work and what is most likely the problem. The root problem is that after
      resume the musb runtime-suspend state remains RPM_SUSPENDED.
      According to git log it RPM was added for the omap2430 platform. If I
      understand it correct the omap2430 invokes a get on musb once a cable is
      connected and a put once the cable is gone. In between the device could
      go auto-idle/off. Not sure what happens when the device goes into suspend
      but then I guess it was gadget only.
      On DSPS I see only a get in probe and put in remove function. This would
      forbid RPM from working but then the devices enterns suspended state
      anyway :)
      
      To get rid of this warning, I set the device state to RPM_ACTIVE which
      the expected state.
      
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      a1fc1920
  11. 11 11月, 2014 1 次提交
  12. 08 11月, 2014 2 次提交
  13. 06 11月, 2014 2 次提交
    • S
      usb: musb: try a race-free wakeup · baadd52f
      Sebastian Andrzej Siewior 提交于
      Attaching a keyboard, using it as a wakeup via
      |for f in $(find /sys/devices/ocp.3/47400000.usb -name wakeup)
      |do
      |	echo enabled > $f
      |done
      
      going into standby
      |  echo standby >  /sys/power/state
      
      and now a wake up by a pressing a key.
      What happens is that the system wakes up but the USB device is dead. The
      USB stack tries to send a few control URBs but nothing comes back.
      Eventually it gaves up and the device remains dead:
      |[  632.559678] PM: Wakeup source USB1_PHY
      |[  632.581074] PM: noirq resume of devices complete after 21.261 msecs
      |[  632.607521] PM: early resume of devices complete after 10.360 msecs
      |[  632.616854] net eth2: initializing cpsw version 1.12 (0)
      |[  632.704126] net eth2: phy found : id is : 0x4dd074
      |[  636.704048] libphy: 4a101000.mdio:00 - Link is Up - 1000/Full
      |[  638.444620] usb 1-1: reset low-speed USB device number 2 using musb-hdrc
      |[  653.713435] usb 1-1: device descriptor read/64, error -110
      |[  669.093435] usb 1-1: device descriptor read/64, error -110
      |[  669.473424] usb 1-1: reset low-speed USB device number 2 using musb-hdrc
      |[  684.743436] usb 1-1: device descriptor read/64, error -110
      |[  690.065097] PM: resume of devices complete after 57450.744 msecs
      |[  690.076601] PM: Finishing wakeup.
      |[  690.076627] Restarting tasks ...
      
      It seems that since we got woken up via MUSB_INTR_RESUME the
      musb_host_finish_resume() callback is executed before the
      resume-callbacks of the PHY and glue layer are invoked. If I delay it
      until the glue layer resumed then I don't see this problem.
      
      I also move musb_host_resume_root_hub() into that callback since I don't
      see any reason in doing anything resume-link if there are still pieces
      not restored.
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      baadd52f
    • S
      usb: musb: core: check link status on resume · b87fd2f7
      Sebastian Andrzej Siewior 提交于
      The am335x-evmsk support two kinds of suspend:
      - standby
        the USB device remains powered while the system goes into suspend
      
      - mem
        the USB device becomes powerless while the system goes into suspend.
      
      In the "standby" case the device resumes quickly. In the "mem" case the
      system hangs for a few seconds. It seems to me that the USB-device has
      no address (it was disconnected) and the USB stack thinks that it is
      fully operational and GetPortStatus returns the status from before the
      suspend so it is not a big help here.
      
      This adds a check in the resume path to see if the device mode (A or B)
      and the speed is the same. If the device went missing between
      suspend/resume (VBUS went down) then MUSB seems to go into B mode and
      HS/FS bits are cleared. In that case we clear the port1_status bits and
      assume a disconnect. Once the stack learns this it does a "logical
      disconnect" and removes the USB-device quickly. Should the device remain
      connected during the suspend then MUSB will receives a "CONNECT" interrupt.
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      b87fd2f7
  14. 04 11月, 2014 5 次提交