1. 22 Dec, 2015 9 commits
    • Douglas Anderson's avatar
      usb: dwc2: Avoid more calls to dwc2_core_reset() · 7d56cc26
      Douglas Anderson authored
      Calls to dwc2_core_reset() are currently very slow, taking at least
      150ms (possibly more).  It behooves us to take as many of these calls
      out as possible.
      
      It turns out that the calls in dwc2_fs_phy_init() and dwc2_hs_phy_init()
      should (as documented in the code) only be needed if we need to do a PHY
      SELECT.  That means that if we see that we can avoid the PHY SELECT then
      we can avoid the reset.
      
      This patch appears to successfully bypass two resets (one per USB
      device) on rk3288-based ARM Chromebooks.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      7d56cc26
    • Yunzhi Li's avatar
      usb: dwc2: reduce dwc2 driver probe time · 20bde643
      Yunzhi Li authored
      I found that the probe function of dwc2 driver takes much time
      when kernel boot up. There are many long delays in the probe
      function these take almost 1 second.
      
      This patch trying to reduce unnecessary delay time.
      
      In dwc2_core_reset() I see it use two at least 20ms delays to
      wait AHB idle and core soft reset, but dwc2 data book said that
      dwc2 core soft reset and AHB idle just need a few clocks (I think
      it refers to AHB clock, and AHB clock run at 150MHz in my RK3288
      board), so 20ms is too long, delay 1us for wait AHB idle and soft
      reset is enough.
      
      And in dwc2_get_hwparams() it takes 150ms to wait ForceHostMode
      and ForceDeviceMode valid but in data book it said software must
      wait at least 25ms before the change to take effect, so I reduce
      this time to 25ms~50ms. By the way, is there any state bit show
      that the force mode take effect ? Could we poll curmod bit for
      figuring out if the change take effect ?
      
      It seems that usleep_range() at boot time will pick the longest
      value in the range. In dwc2_core_reset() there is a very long
      delay takes 200ms, and this function run twice when probe, could
      any one tell me is this delay time resonable ?
      
      I have tried this patch in my RK3288-evb board. It works well.
      Signed-off-by: default avatarYunzhi Li <lyz@rock-chips.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      20bde643
    • Douglas Anderson's avatar
      usb: dwc2: Speed dwc2_get_hwparams() on some host-only ports · f6194731
      Douglas Anderson authored
      On some host-only DWC2 ports (like the one in rk3288) when we set
      GUSBCFG_FORCEHOSTMODE in GUSBCFG and then read back, we don't see the
      bit set.  Presumably that's because the port is always forced to HOST
      mode so there's no reason to implement these status bits.
      
      Since we know dwc2_core_reset() is always called before
      dwc2_get_hwparams() and we know dwc2_core_reset() should have set
      GUSBCFG_FORCEHOSTMODE whenever hsotg->dr_mode == USB_DR_MODE_HOST, we
      can just check hsotg->dr_mode to decide that we can skip the delays in
      dwc2_get_hwparams().
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      f6194731
    • Douglas Anderson's avatar
      usb: dwc2: Avoid double-reset at boot time · 0fe239bc
      Douglas Anderson authored
      In (usb: dwc2: reset dwc2 core before dwc2_get_hwparams()) we added an
      extra reset to the probe path for the dwc2 USB controllers.  This
      allowed proper detection of parameters even if the firmware had already
      used the USB part.
      
      Unfortunately, this extra reset is quite slow and is affecting boot
      speed.  We can avoid the double-reset by skipping the extra reset that
      would happen just after the one we added.  Logic that explains why this
      is safe:
      
      * As of the CL mentioned above, we now always call dwc2_core_reset() in
        dwc2_driver_probe() before dwc2_hcd_init().
      
      * The only caller of dwc2_hcd_init() is dwc2_driver_probe(), so we're
        guaranteed that dwc2_core_reset() was called before dwc2_hdc_init().
      
      * dwc2_hdc_init() is the only caller that passes an irq other than -1 to
        dwc2_core_init().  Thus if dwc2_core_init() is called with an irq
        other than -1 we're guaranteed that dwc2_core_reset was called before
        dwc2_core_init().
      
      ...this allows us to remove the dwc2_core_reset() in dwc2_core_init() if
      irq is not < 0.
      
      Note that since "irq" wasn't used in the function dwc2_core_init()
      anyway and since select_phy was always set at exactly the same times we
      could avoid the reset, we remove "irq" and rename "select_phy" to
      "initial_setup" and adjust the callers accordingly.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      0fe239bc
    • Yunzhi Li's avatar
      usb: dwc2: reset dwc2 core before dwc2_get_hwparams() · cebfdbf3
      Yunzhi Li authored
      We initiate dwc2 usb controller in BIOS, dwc2_core_reset() should
      be called before dwc2_get_hwparams() to reset core registers to
      default value. Without this the FIFO setting might be incorrect
      because calculating FIFO size need power-on value of
      GRXFSIZ/GNPTXFSIZ/HPTXFSIZ registers.
      
      This patch could avoid warnning massage like in rk3288 platform:
      [    2.074764] dwc2 ff580000.usb: 256 invalid for
      host_perio_tx_fifo_size. Check HW configuration.
      Signed-off-by: default avatarYunzhi Li <lyz@rock-chips.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      cebfdbf3
    • Douglas Anderson's avatar
      usb: dwc2: Restore GUSBCFG in dwc2_get_hwparams() · 99182467
      Douglas Anderson authored
      Previously dwc2_get_hwparams() was changing GUSBCFG and not putting it
      back the way it was (specifically it set and cleared FORCEHOSTMODE).
      Since we want to move dwc2_core_reset() _before_ dwc2_get_hwparams() we
      should make sure dwc2_get_hwparams() isn't messing with things in a
      permanent way.
      
      Since we're now looking at GUSBCFG, it's obvious that we shouldn't need
      all the extra delays if FORCEHOSTMODE was already set.  This will avoid
      some delays for any ports that have forced host mode.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      99182467
    • Gregory Herrero's avatar
      usb: dwc2: gadget: don't overwrite DCTL register on NAKEFF interrupts · 3be99cd0
      Gregory Herrero authored
      When receiving GINTSTS_GINNAKEFF or GINTSTS_GOUTNAKEFF interrupt,
      DCTL will be overwritten with DCTL_CGOUTNAK or DCTL_CGNPINNAK values.
      Instead of overwriting it, write only needed bits.
      
      It could cause an issue if GINTSTS_GINNAKEFF or GINTSTS_GOUTNAKEFF
      interrupt is received after dwc2 disabled pullup by writing
      DCTL_SFTDISCON bit.
      Pullup will then be re-enabled whereas it should not.
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarGregory Herrero <gregory.herrero@intel.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      3be99cd0
    • Du, Changbin's avatar
      usb: dwc2: fix transfer stop programming for out endpoint · 0676c7e7
      Du, Changbin authored
      To stop an out endpoint, software should set sets the Global OUT NAK,
      but not the Global Non-periodic IN NAK. This driver bug leads the out-ep
      failed be in disabled state with below error.
      
      dwc2_hsotg_ep_stop_xfr: timeout DOEPCTL.EPDisable
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarDu, Changbin <changbin.du@intel.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      0676c7e7
    • Baolin Wang's avatar
      usb: gadget: Add the console support for usb-to-serial port · a5beaaf3
      Baolin Wang authored
      It dose not work when we want to use the usb-to-serial port based
      on one usb gadget as a console. Thus this patch adds the console
      initialization to support this request.
      
      To avoid the re-entrance when transferring data with usb endpoint,
      it introduces a kthread to do the IO transmission.
      Signed-off-by: default avatarBaolin Wang <baolin.wang@linaro.org>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      a5beaaf3
  2. 17 Dec, 2015 1 commit
    • Felipe Balbi's avatar
      usb: of: fix build breakage on !OF · be99c843
      Felipe Balbi authored
      If OF is disabled, we will try to define a stub for
      of_usb_get_dr_mode_by_phy(), however that missed a
      static inline annotation which made us redefine the
      stub over and over again. Fix that.
      
      Fixes: 98bfb394 ("usb: of: add an api to get
      	dr_mode by the phy node")
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      be99c843
  3. 16 Dec, 2015 20 commits
  4. 15 Dec, 2015 10 commits