Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 13 4月, 2021 2 次提交
  3. 09 4月, 2021 2 次提交
  5. 27 1月, 2021 2 次提交
  7. 02 10月, 2020 19 次提交
  9. 24 9月, 2020 2 次提交
    • T
      usb: dwc3: gadget: END_TRANSFER before CLEAR_STALL command · d97c78a1
      由 Thinh Nguyen 提交于 
      According the programming guide (for all DWC3 IPs), when the driver
handles ClearFeature(halt) request, it should issue CLEAR_STALL command
_after_ the END_TRANSFER command completes. The END_TRANSFER command may
take some time to complete. So, delay the ClearFeature(halt) request
control status stage and wait for END_TRANSFER command completion
interrupt. Only after END_TRANSFER command completes that the driver
may issue CLEAR_STALL command.

Cc: stable@vger.kernel.org
Fixes: cb11ea56 ("usb: dwc3: gadget: Properly handle ClearFeature(halt)")
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      d97c78a1
    • T
      usb: dwc3: gadget: Resume pending requests after CLEAR_STALL · c503672a
      由 Thinh Nguyen 提交于 
      The function driver may queue new requests right after halting the
endpoint (i.e. queue new requests while the endpoint is stalled).
There's no restriction preventing it from doing so. However, dwc3
currently drops those requests after CLEAR_STALL. The driver should only
drop started requests. Keep the pending requests in the pending list to
resume and process them after the host issues ClearFeature(Halt) to the
endpoint.

Cc: stable@vger.kernel.org
Fixes: cb11ea56 ("usb: dwc3: gadget: Properly handle ClearFeature(halt)")
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      c503672a
  11. 17 8月, 2020 3 次提交
  13. 24 7月, 2020 3 次提交
  15. 15 7月, 2020 1 次提交
  17. 24 6月, 2020 1 次提交
  19. 25 5月, 2020 5 次提交
    • T
      usb: dwc3: gadget: Check for prepared TRBs · 63c7bb29
      由 Thinh Nguyen 提交于 
      There are cases where the endpoint needs to be restarted. For example,
it may need to restart for NoStream rejection to reinitiate stream. If
so, check and make sure we don't prepare beyond the current transfer
when we restart the endpoint.

DWC_usb32 internal burst transfer feature will look into TRBs beyond a
transfer. Other controllers will stop on the last TRB, but not
DWC_usb32. This may cause the controller to incorrectly process TRBs of
a different transfer. Make sure to explicitly prevent preparing TRBs of
a different transfer.

This should only affect DWC_usb32 releases prior to v1.00a since it
doesn't use SET_ENDPOINT_PRIME to reinitiate stream. However, it's
better to be cautious in case users don't want to use SET_ENDPOINT_PRIME
command. Also, it's possible other controller IPs may share the same
features as DWC_usb32 in new releases.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      63c7bb29
    • Y
      usb: dwc3: Increase timeout for CmdAct cleared by device controller · 1c0e69ae
      由 Yu Chen 提交于 
      If the SS PHY is in P3, there is no pipe_clk, HW may use suspend_clk
for function, as suspend_clk is slow so EP command need more time to
complete, e.g, imx8M suspend_clk is 32K, set ep configuration will
take about 380us per below trace time stamp(44.286278 - 44.285897
= 0.000381):

configfs_acm.sh-822   [000] d..1    44.285896: dwc3_writel: addr
000000006d59aae1 value 00000401
configfs_acm.sh-822   [000] d..1    44.285897: dwc3_readl: addr
000000006d59aae1 value 00000401
... ...
configfs_acm.sh-822   [000] d..1    44.286278: dwc3_readl: addr
000000006d59aae1 value 00000001
configfs_acm.sh-822   [000] d..1    44.286279: dwc3_gadget_ep_cmd:
ep0out: cmd 'Set Endpoint Configuration' [401] params 00001000
00000500 00000000 --> status: Successful

This was originally found on Hisilicon Kirin Soc that need more time
for the device controller to clear the CmdAct of DEPCMD.
Signed-off-by: NYu Chen <chenyu56@huawei.com>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NLi Jun <jun.li@nxp.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      1c0e69ae
    • T
      usb: dwc3: gadget: Use SET_EP_PRIME for NoStream · b10e1c25
      由 Thinh Nguyen 提交于 
      DWC_usb32 v1.00a and later can use SET_EP_PRIME command to reinitiate a
stream. Use the command to handle NoStream rejection instead of ending
and restarting the endpoint.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      b10e1c25
    • T
      usb: dwc3: gadget: Handle stream transfers · 140ca4cf
      由 Thinh Nguyen 提交于 
      Overview of stream transfer requirement:
 * A transfer will have a set of TRBs of the same stream ID.
 * A transfer is started with a stream ID in START_TRANSFER command.
 * A new stream will only start when the previous completes.

Overview of stream events:
 * A "prime" from host indicates that its endpoints are active
   (buffers prepared and ready to receive/transmit data). The controller
   automatically initiates stream if it sees this.
 * A "NoStream" rejection event indicates that the host isn't ready.
   Host will put the endpoint back to idle state. Device may need to
   reinitiate the stream to start transfer again.
 * A Stream Found event means host accepted device initiated stream.
   Nothing needs to be done from driver.

To initiate a stream, the driver will issue START_TRANSFER command with
a stream ID. To reinitiate the stream, the driver must issue
END_TRANSFER and restart the transfer with START_TRANSFER command with
the same stream ID.

This implementation handles device-initated streams (e.g. UASP driver).
It also handles some hosts' quirky behavior where they only prime each
endpoint once.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      140ca4cf
    • T
      usb: dwc3: gadget: Don't prepare beyond a transfer · aefe3d23
      由 Thinh Nguyen 提交于 
      Don't prepare TRBs beyond a transfer. In DWC_usb32, its transfer burst
capability may try to read and use TRBs beyond the active transfer. For
other controllers, they don't process the next transfer TRBs until the
current transfer is completed. Explicitly prevent preparing TRBs ahead
for all controllers.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      aefe3d23