- 18 11月, 2016 5 次提交
-
-
由 Janusz Dziedzic 提交于
Seems last time we hit few issues where we get trb_left = 0, mainly because of HWO bit still set in previous TRB. Add warn on once to catch/fix such problems much faster. Signed-off-by: NJanusz Dziedzic <januszx.dziedzic@linux.intel.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Janusz Dziedzic 提交于
After we kick_transfer we should clean DWC3_EP_PENDING_REQUEST endpoint flag. Signed-off-by: NJanusz Dziedzic <januszx.dziedzic@linux.intel.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Janusz Dziedzic 提交于
Use pre-increment and set -ETIMEDOUT correctly. Signed-off-by: NJanusz Dziedzic <januszx.dziedzic@linux.intel.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Janusz Dziedzic 提交于
In case STARTTRANSFER will fail, clean TRB. Seems HW in such case don't clean HWO bit. So, without this cleanup prev_trb still have HWO bit set. In my case (without patch), after first START failed: - dep->enqueue == 1 - dep->dequeue == 1 - prev_trb still have HWO set - left_trb() == 0 No way to send more data. Signed-off-by: NJanusz Dziedzic <januszx.dziedzic@linux.intel.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Janusz Dziedzic 提交于
In case we will fail to STARTTRANSFER we should also decrement queued_requests. Signed-off-by: NJanusz Dziedzic <januszx.dziedzic@linux.intel.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 08 11月, 2016 2 次提交
-
-
由 Felipe Balbi 提交于
Finally get rid of dwc3_trace() hack. If any other message is truly needed, we should add proper tracepoints for them instead of hacking around with dwc3_trace() or similar. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
instead of using a simple trace_printk() wrapper, let's add an actual tracepoint and print further details about the endpoint being operated upon. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 03 11月, 2016 14 次提交
-
-
由 Felipe Balbi 提交于
When we get a half-way processed request, we should make sure to try to prepare further TRBs for it or for any possibly queued up request held in our pending_list. This will make sure our controller is kept busy for as long as possible. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
Say we have three requests prepared to the HW (reqA, reqB, and reqC). All of them are composed of SG-lists with several entries and they all requests interrupt only on last TRBs of the SG-list. When we get interrupt for reqA, it could be that reqB is already half-way transferred and some of its TRBs will have HWO already cleared. It's okay to free up TRBs without HWO bit set, but we need to guarantee we don't giveback a request that's half-way transferred as that will confuse gadget drivers. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
In cases where we're given an SG-list which is longer than the amount of currently available TRBs, we will be left with the same request on started_list and we should prioritize that request over possible new requests on pending_list. That's a way to guarantee requests complete in order. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
This will give us a simpler way of figuring out how many bytes were left in each TRB. It's useful for cases where we queue only part of an SG-list due to amount of available TRBs at the time of kicking the transfer. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
If XferNotReady comes before usb_ep_queue() we will set our PENDING request flag and wait for a request. However, originally, we were assuming usb_ep_queue() would always happen before our first XferNotReady and that causes a corner case where we could try to issue ENDTRANSFER command before STARTTRANSFER. Let's fix that by tracking endpoints which have been started. Reported-by: NJanusz Dziedzic <januszx.dziedzic@intel.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Baolin Wang 提交于
Instead of just delaying for 100us, we should actually wait for End Transfer Command Complete interrupt before moving on. Note that this should only be done if we're dealing with one of the core revisions that actually require the interrupt before moving on. [ felipe.balbi@linux.intel.com: minor improvements ] Signed-off-by: NBaolin Wang <baolin.wang@linaro.org> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Baolin Wang 提交于
When we change the USB function with configfs dynamically, we possibly met this situation: one core is doing the control transfer, another core is trying to unregister the USB gadget from userspace, we must wait for completing this control tranfer, or it will hang the controller to set the DEVCTRLHLT flag. [ felipe.balbi@linux.intel.com: several fixes to the patch - call complete() before starting following SETUP transfer - add a macro for ep0_in_setup's timeout - change commit subject slightly - break lines at 72 characters (git adds an 8-character tab) - avoid changes to dwc3_gadget_run_stop() ] Signed-off-by: NBaolin Wang <baolin.wang@linaro.org> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
That function is unnecessarily called from dwc3_gadget_reset_interrupt(). Gadget drivers (and thus, functions) are required to dequeue all pending requests when they get notified about a USB Bus Reset. Trying to make sure there are no pending requests only serves the purpose of working around possibly bad gadgets. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
We should never kill the machine just because some USB endpoint type is wrong. WARN about it and move on. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
We don't need to know about short packets unless gadget driver told us it's not ok to see them on the bus. In the normal situation we can continue processing the list of requests if we get a Short packet. Also, note that we're making sure ISP is only set for OUT endpoints, where that setting is valid. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
CSP bit is only valid for OUT endpoints. Synopsys databook is unclear if HW ignores CSP for IN endpoints (chances are, it does) but to avoid problems, let's make sure to set CSP only when valid to do so. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
Recent changes have turned this field obsolete. Remove it. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
Cleanup only, no functional changes. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
We can offset the latency of a full Start Transfer command - where we _must_ poll for its completion - to usb_ep_enable() time. This means that once requests start showing up from the gadget driver, we can rely on No Response Update Transfer command - where we don't need to poll for completion. This patch, starts implementing this method for Bulk endpoints, even though, technically, we could extend it to all other endpoints in future commits. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 31 10月, 2016 7 次提交
-
-
由 Felipe Balbi 提交于
With this extra piece of information, it will be easier to find mismatches between driver and HW. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
Removing some trace prints which were made redundant when we started decoding events and TRBs completely within their respective trace points. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
Link State Change events are only needed for debugging and to apply certain workarounds on known errata. Let's save a few cycles by disabling these events completely on working revisions of the core. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
There might be situations where a Start Transfer command might fail, if that ever happens, instead of simply removing the request from our list, we should give the request back to the gadget driver, otherwise we might eventually starve it from requests. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
No Response Update Transfer is a special type of Update Transfer command which can be used whenever we're not relying on XferNotReady to prepare transfers. With this, we don't need to wait for CMDACT to be cleared and issue further commands to the endpoint straight away. Let's start using this version to skip the long-ish wait. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
The cmd argument we pass to dwc3_send_gadget_ep_cmd() could contain extra arguments embedded. When checking for StartTransfer command, we need to make sure to match only lower 4 bits which contain the actual command and ignore the rest. Reported-by: NJanusz Dziedzic <januszx.dziedzic@intel.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
In case of High-Speed, High-Bandwidth endpoints, we need to tell DWC3 that we have more than one packet per interval. We do that by setting PCM1 field of Isochronous-First TRB. Cc: <stable@vger.kernel.org> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 17 10月, 2016 3 次提交
-
-
由 Christophe JAILLET 提交于
In commit 2abd9d5f ("usb: dwc3: ep0: Add chained TRB support"), the size of the memory allocated with 'dma_alloc_coherent()' has been modified but the corresponding calls to 'dma_free_coherent()' have not been updated accordingly. This has been spotted with coccinelle, using the following script: //////////////////// @r@ expression x0, x1, y0, y1, z0, z1, t0, t1, ret; @@ * ret = dma_alloc_coherent(x0, y0, z0, t0); ... * dma_free_coherent(x1, y1, ret, t1); @script:python@ y0 << r.y0; y1 << r.y1; @@ if y1.find(y0) == -1: print "WARNING: sizes look different: '%s' vs '%s'" % (y0, y1) //////////////////// Fixes: 2abd9d5f ("usb: dwc3: ep0: Add chained TRB support") Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
We cannot pre-start isochronous endpoints because we rely on the micro-frame number passed via XferNotReady command for proper Isochronous scheduling. Fixes: 08a36b54 ("usb: dwc3: gadget: simplify __dwc3_gadget_ep_queue()") Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
Some requests could be accounted for multiple times. Let's fix that so each and every requests is accounted for only once. Cc: <stable@vger.kernel.org> # v4.8 Fixes: 55a0237f ("usb: dwc3: gadget: use allocated/queued reqs for LST bit") Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 12 9月, 2016 1 次提交
-
-
由 Lu Baolu 提交于
Commit 50c763f8 ("usb: dwc3: Set the ClearPendIN bit on Clear Stall EP command") sets ClearPendIN bit for all IN endpoints of v2.60a+ cores. This causes ClearStall command fails on 2.60+ cores operating in HighSpeed mode. In page 539 of 2.60a specification: "When issuing Clear Stall command for IN endpoints in SuperSpeed mode, the software must set the "ClearPendIN" bit to '1' to clear any pending IN transcations, so that the device does not expect any ACK TP from the host for the data sent earlier." It's obvious that we only need to apply this rule to those IN endpoints that currently operating in SuperSpeed mode. Fixes: 50c763f8 ("usb: dwc3: Set the ClearPendIN bit on Clear Stall EP command") Cc: <stable@vger.kernel.org> # v4.7+ Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 09 9月, 2016 1 次提交
-
-
由 Arnd Bergmann 提交于
Cleaning up the loop in dwc3_cleanup_done_reqs() introduced a gcc warning if built with "-Wmaybe-uninitialized": drivers/usb/dwc3/gadget.c: In function 'dwc3_endpoint_transfer_complete': drivers/usb/dwc3/gadget.c:2015:9: 'trb' may be used uninitialized in this function [-Wmaybe-uninitialized] I believe it is a false positive and we always have a valid 'trb' pointer at the end of the function, but neither I nor the compiler are able to prove that. This works around the warning by computing a flag earlier in the function when it's guaranteed to be valid, which tells the compiler that it's safe and makes it easier to understand to me. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Fixes: 31162af4 ("usb: dwc3: gadget: avoid while (1) loop on completion") Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 05 9月, 2016 1 次提交
-
-
由 John Youn 提交于
This reverts commit 6f8245b4 ("usb: dwc3: gadget: always decrement by 1"). We can't always decrement this value. We should decrement only if the calculation of free slots results in a LINK TRB being among one of the free slots (dequeue < enqueue). Otherwise, if the LINK TRB is not among the free slots then it should not be decremented. Signed-off-by: NJohn Youn <johnyoun@synopsys.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 25 8月, 2016 6 次提交
-
-
由 Felipe Balbi 提交于
We need to decrement in both cases (enq > deq and enq < deq) Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
In case our TRB ring is full, we can avoid trying to kick transfers which won't start and just add requests to the queue. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
Instead, we can always rely on dwc3_calc_trbs_left() directly. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 John Youn 提交于
ENDXFER polling is available on version 3.10a and later of the DWC_usb3 (USB 3.0) controller. With this feature, the software can poll the CMDACT bit in the DEPCMD register after issuing an ENDXFER command. This feature is enabled by writing GUCTL2[14]. This feature is NOT available on the DWC_usb31 (USB 3.1) IP. Signed-off-by: NJohn Youn <johnyoun@synopsys.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
No functional changes, just a slight cosmetic change. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
We don't use LST bit anymore, so this condition will never trigger. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-