1. 04 3月, 2016 1 次提交
  2. 23 12月, 2015 1 次提交
    • D
      usb: dwc2: Avoid double-reset at boot time · 0fe239bc
      Douglas Anderson 提交于
      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: NDouglas Anderson <dianders@chromium.org>
      Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      0fe239bc
  3. 15 12月, 2015 5 次提交
  4. 18 11月, 2015 1 次提交
    • D
      usb: dwc2: host: Fix remote wakeup when not in DWC2_L2 · 1fb7f12d
      Douglas Anderson 提交于
      In commit 734643df ("usb: dwc2: host: add flag to reflect bus
      state") we changed dwc2_port_suspend() not to set the lx_state
      anymore (instead it sets the new bus_suspended variable).  This
      introduced a bug where we would fail to detect device insertions if:
      
      1. Plug empty hub into dwc2
      2. Plug USB flash drive into the empty hub.
      3. Wait a few seconds
      4. Unplug USB flash drive
      5. Less than 2 seconds after step 4, plug the USB flash drive in again.
      
      The dwc2_hcd_rem_wakeup() function should have been changed to look at
      the new bus_suspended variable.
      
      Let's fix it.  Since commit b46146d5 ("usb: dwc2: host: resume root
      hub on remote wakeup") talks about needing the root hub resumed if the
      bus was suspended, we'll include it in our test.
      
      It appears that the "port_l1_change" should only be set to 1 if we were
      in DWC2_L1 (the driver currently never sets this), so we'll update the
      former "else" case based on this test.
      
      Fixes: 734643df ("usb: dwc2: host: add flag to reflect bus state")
      Acked-by: NJohn Youn <johnyoun@synopsys.com>
      Tested-by: NGregory Herrero <gregory.herrero@intel.com>
      Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      1fb7f12d
  5. 17 10月, 2015 1 次提交
  6. 02 10月, 2015 11 次提交
  7. 27 9月, 2015 2 次提交
  8. 07 7月, 2015 2 次提交
  9. 14 5月, 2015 1 次提交
  10. 30 4月, 2015 7 次提交
  11. 10 4月, 2015 1 次提交
  12. 08 4月, 2015 1 次提交
  13. 04 4月, 2015 1 次提交
  14. 20 3月, 2015 1 次提交
    • V
      usb: dwc2: avoid leaking DMA channels on disconnection · 7252f1bf
      Vincent Palatin 提交于
      When the HCD is disconnected, the DMA transfers still in-flight were cleaned-up
      but the count of available DMA channels (e.g. available_host_channels) was not
      reset.
      The pool of DMA channels can be depleted when doing unclean
      disconnection of USB peripherals, and reaches the point where no
      transfer was possible until the next reboot/reload of the driver.
      
      Tested by putting a programmable USB mux on the port and randomly
      plugging/unpluging a USB HUB with USB mass-storage key, USB-audio and
      USB-ethernet dongle connected to its downstream ports, and also doing the
      disconnection early while the devices are still enumerating to get more URBs
      in-flight.
      After the patch, the devices are still enumerating after thousands of cycles,
      while the port was totally dead before.
      Signed-off-by: NVincent Palatin <vpalatin@chromium.org>
      Acked-by: NJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      7252f1bf
  15. 31 1月, 2015 2 次提交
  16. 25 1月, 2015 1 次提交
  17. 20 1月, 2015 1 次提交