1. 05 Nov, 2014 7 commits
    • Sebastian Andrzej Siewior's avatar
      usb: musb: try a race-free wakeup · baadd52f
      Sebastian Andrzej Siewior authored
      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: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      baadd52f
    • Sebastian Andrzej Siewior's avatar
      usb: musb: core: check link status on resume · b87fd2f7
      Sebastian Andrzej Siewior authored
      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: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      b87fd2f7
    • Jingoo Han's avatar
      usb: dwc3: exynos: remove non-DT support for Exynos Specific Glue layer · b4c9f578
      Jingoo Han authored
      DWC3 Exynos Specific Glue layer can be used only for Exynos SoCs.
      In addition, non-DT for EXYNOS SoCs is not supported from v3.11;
      thus, there is no need to support non-DT for DWC3 Exynos Specific
      Glue layer.
      
      The 'linux/platform_data/dwc3-exynos.h' file has been used for
      non-DT support. Thus, the 'dwc3-exynos.h' file is removed, because
      it is not used anymore.
      Signed-off-by: default avatarJingoo Han <jg1.han@samsung.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      b4c9f578
    • Yoshihiro Shimoda's avatar
      usb: renesas_usbhs: fix usbhs_pipe_clear() for DCP PIPE · cdeb7943
      Yoshihiro Shimoda authored
      Since the DCPCTR doesn't have the ACLRM bit, the usbus_pipe_clear()
      should not call the usbhsp_pipectrl_set() with ACLRM.
      So, this patch fixes this issue to add the usbhs_fifo_clear_dcp()
      in fifo.c because the controller needs the CFIFO to clear the
      the DCP PIPE.
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      cdeb7943
    • Yoshihiro Shimoda's avatar
      usb: renesas_usbhs: fix the timing of dcp_control_transfer_done · 4ef35b10
      Yoshihiro Shimoda authored
      According to the datasheet, this driver should clear the INTSTS0.CTRT
      bit before this controller detects the next stage transition. Otherwise,
      the driver may not be able to clear the bit after the controller went to
      the next stage transition. After that, the driver will not be able to
      clear the INTSTS0.VALID, and a usb control transfer will not finish
      finally.
      
      If we use the testusb tool, it is easy to reproduce this issue:
      
       # testusb -a -t 10
      
      Since the previous code handled a data stage and a status stage in
      the usbhsf_pio_try_push(), it may not clear the INTSTS0.CTRT at the
      right timing.
      So, this patch change the timing of usbhs_dcp_control_transfer_done()
      to the usbhsg_irq_ctrl_stage().
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      4ef35b10
    • Takeshi Kihara's avatar
      usb: renesas_usbhs: gadget: fix the behavior of pullup · 04a5def3
      Takeshi Kihara authored
      This patch fixes an issue that this driver always enable the D+ pullup
      after it detected the VBUS connection even though this usb controller
      can control the D+ pullup timing by software. So, this driver should
      enable the D+ pullup after a gadget driver called usb_gadget_connect().
      Signed-off-by: default avatarTakeshi Kihara <takeshi.kihara.df@renesas.com>
      Signed-off-by: default avatarKazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      04a5def3
    • Kazuya Mizuguchi's avatar
      usb: renesas_usbhs: gadget: fix NULL pointer dereference in ep_disable() · 11432050
      Kazuya Mizuguchi authored
      This patch fixes an issue that the NULL pointer dereference happens
      when we uses g_audio driver. Since the g_audio driver will call
      usb_ep_disable() in afunc_set_alt() before it calls usb_ep_enable(),
      the uep->pipe of renesas usbhs driver will be NULL. So, this patch
      adds a condition to avoid the oops.
      Signed-off-by: default avatarKazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
      Signed-off-by: default avatarTakeshi Kihara <takeshi.kihara.df@renesas.com>
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Fixes: 2f98382d (usb: renesas_usbhs: Add Renesas USBHS Gadget)
      Cc: <stable@vger.kernel.org> # v3.0+
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      11432050
  2. 03 Nov, 2014 33 commits