An error occurred fetching the project authors.
- 06 Feb, 2012 3 commits
-
-
Felipe Balbi authored
We need to dynamically re-size TxFifos for the cases where default values will not do. While at that, we create a simple function which, for now, will just allocate one full packet fifo space for each of the enabled endpoints. This can be improved later in order to allow for better throughput by allocating more space for endpoints which could make good use of that like isochronous and bulk. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
Mass Storage gadget will take some time to handle the SetConfiguration request, but even on those cases we should move to CONFIGURED state. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
There are some situations were we might need to enable USB Test Modes without having access to a Host stack. In such situations we cannot rely solely on USB Control Messages to enable test features. For those cases, we will also allow test mode to be enabled via debugfs and this patch is a preparation for that. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
- 24 Jan, 2012 2 commits
-
-
Felipe Balbi authored
commit 34c60a7 (usb: dwc3: ep0: tidy up Pending Request handling) introduced a compile warning by leaving an unused variable. This patch fixes that warning: drivers/usb/dwc3/ep0.c: In function ‘__dwc3_gadget_ep0_queue’: drivers/usb/dwc3/ep0.c:129:8: warning: unused variable ‘type’ [-Wunused-variable] Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
The way our code was written, we should never have a DWC3_EP_PENDING_REQUEST flag set out of a Data Phase and the code in __dwc3_gadget_ep0_queue() did not reflect that situation properly. Tidy up that case to avoid any possible mistakes when starting requests for IRQs which are long gone. Cc: stable@vger.kernel.org Signed-off-by: Felipe Balbi <balbi@ti.com>
-
- 12 Dec, 2011 14 commits
-
-
Felipe Balbi authored
There is a very small possibility (previously unimagined by us) that the whole Mass Storage delayed status happens rather early, before we even get our XferNotReady event. In that case, we will be queueing a request to ep0 while we're still on Setup Phase and we would be waiting for another usb_ep_queue() forever. Handle such cases by clearing dwc->delayed_status so that we start control status from the next XferNotReady like there was no wait for Delayed Status. Tested against Linux 3.2-rc3 and USB30CV tool from USB-IF (on a Windows XP with USB3 PCIe card). Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
previous commit fixed part of it but it was still calling usb_ep_queue() from IRQ context without loosing locks. That cannot be done otherwise we will have a recursive locking. Also, we need to assign the 'dep' pointer on dwc->ep0_usb_req otherwise we will have a NULL pointer dereference on dwc3_map_buffer_to_dma(). Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Sebastian Andrzej Siewior authored
Instead of special functions and shortcuts for sending our internal answers to the host we started doing what the gadget does and used the public API for this. Since we only were using a few fields the usb_request was enough. Later added the list handling in order to synchronize the host / gadget events and now we require to have the dwc3_request struct around our usb_request or else we touch memory that does not belong to us. So this patch does this. Reported-by: Partha Basak <p-basak2@ti.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
DWC3 revisions <1.88a have an issue which would case a missing Disconnect event if cable is disconnected while there's a Setup packet pending the FIFO. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Sebastian Andrzej Siewior authored
Since the re-worked ep0 handling (which uses HW's hints to recognize the ep0 status) we lost the delayed status handling. This is used by the file and mass storage gadget to gain some extra time so setup its internal status before it can proceed further requests. In particular the storage gadget does nothing on USB_REQ_SET_CONFIGURATION but wakes up a thread which handles the request. If the udc driver continues ep0 handling before the thread did its work then then endpoint is not yet configured and further requests will fail. Once the gadget is ready, it will enqueue an empty packet which is used for synchronization. In order to fix this issue, the patch does the following: Set ->delayed_status once the delayed_status has been notices and do not continue on the next XferNotReady event. We will continues ep0 processing once the gadget enqueued the zero packet for synchronization. A cleaner approach would be to enforce the gadget to enqueue an empty (zero) request even for the status phase but this would do for now. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Sebastian Andrzej Siewior authored
We wait for the XferNotReady before we start the transfer and by then we know ep0 state in which we supposed to be. This is some cleanup work for the following patch in which we require to know the ep0 state before the transfer completes. While here, also change the argument to dwc3_ep0_do_control_status() so we don't require the complete event structure but only the required piece of information. Inspired-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
sparse caught three mistakes on this driver, fix them: drivers/usb/dwc3/ep0.c:806:29: warning: duplicate const drivers/usb/dwc3/debugfs.c:481:15: warning: symbol 'dwc3_debugfs_init' \ was not declared. Should it be static? drivers/usb/dwc3/debugfs.c:518:16: warning: symbol 'dwc3_debugfs_exit' \ was not declared. Should it be static? Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
There were a few coding style issues with this driver which are now fixed: drivers/usb/dwc3/debugfs.c:48: WARNING: Use #include \ <linux/uaccess.h> instead of <asm/uaccess.h> drivers/usb/dwc3/debugfs.c:484: ERROR: space required \ before the open brace '{' drivers/usb/dwc3/ep0.c:261: WARNING: line over 80 characters drivers/usb/dwc3/ep0.c:287: WARNING: suspect code indent \ for conditional statements (16, 23) drivers/usb/dwc3/gadget.c:749: WARNING: line over 80 characters drivers/usb/dwc3/gadget.c:1267: WARNING: line over 80 characters drivers/usb/dwc3/gadget.h:116: WARNING: line over 80 characters drivers/usb/dwc3/io.h:42: WARNING: Use #include \ <linux/io.h> instead of <asm/io.h> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Sebastian Andrzej Siewior authored
In "usb: dwc3: remove special status request handling in ep0" I simplied a few things and used the generic API for the status transfers. The bug I introcuded here is that we queue now requests to dep[1] but we don't clear that list in the stall+start case. Actually we don't need to use dep[1] at all. We only did in the past to talk to the correct endpoint (i.e. in or out). This is now take care of in a diffent place within the ep0 code. So we could queue the in transfers to dep[0] and don't use dep[1] at all. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Sebastian Andrzej Siewior authored
The first access was correct, the second was wrong. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Sebastian Andrzej Siewior authored
The GetStatus (STD)-request is handled the driver and uses a tiny hack to send the two bytes long answer. This patch removes the custom hack uses the normal usb_ep_queue() for that. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Sebastian Andrzej Siewior authored
If we stall and restart we have to reset also this flag to 0 as there is nothing pending anymore. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
Sometimes the host might be trying to initiate Data or Status phase for an older Control transfer. In such situations we must STALL that transfer and restart the state machine rather than letting such situation go through the wire. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
I have talked to USB-IF about USB30CV issuing SetAddres() with a device on Configured state and they have agreed on changing USB30CV not to do so. Adding back the STALL reply in such case and while at that, also add a debugging message for an address which is too large. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
- 04 Oct, 2011 8 commits
-
-
Felipe Balbi authored
our parameter structures need to be written to HW, so instead of assuming little endian, we convert those into bit shifts. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Paul Zimmerman authored
DEPSTARTCFG for non-EP0 EPs must only be sent once per config [ balbi@ti.com : changed config_start to start_config_issued ] Signed-off-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Sebastian Andrzej Siewior authored
Some people think that this line is not compatible with the GPL. The statement was required due to the Buenos Aires Convention and is now deprecated. I remove it because it is said that it is pointless nowdays. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Sebastian Andrzej Siewior authored
Use "ep0in" and "ep0out" instead "ep1in" and "ep0out" which is confusing and not consistent with the remaining output. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Sebastian Andrzej Siewior authored
We already give requests back in dwc3_ep0_stall_and_restart() so doing it again here will most likely corrupt the list. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Felipe Balbi authored
The way it was before was really meaningless. Now it looks saner. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Felipe Balbi authored
We don't need to care about direction on a two stage transfer. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Felipe Balbi authored
According to USB 3.0 Specification, a SetAddress() while device is in Configured State has an unspecified behavior (see Section 9.4.6). Still USB30CV wasn't happy with my Stall reply. To make that thing happy, just accept the SetAddress() always. No problems have been observed thus far. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
- 09 Sep, 2011 9 commits
-
-
Felipe Balbi authored
This flag will tell us which direction we're expecting on the next (data or status) phase. It will help us catching errors of host going crazy and requesting data of the wrong direction. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
if we don't, the list will be busy forever. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
Start tracking the next expected event and act on the error conditions as suggested by databook. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
Whenever we issue a Set Stall command on EP0, the state machine will be restarted and Stall is cleared automatically, when core receives the next SETUP packet. There's no need to track that EP0_STALL state. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
when we're going to issue Set Stall command, we should clear DWC3_EP_STALL flag, but also we should clear BUSY, HALTED and all others. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
data was prepared on setup_buf but transfer was started on ctrl_req, fix it. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
The DesignWare USB3 core tells us which phase of a control transfer should be started, it also tells us which physical endpoint needs that transfer. With these two informations, we have all we need to simply EP0 handling quite a lot and get rid rid of the SW state machine tracking ep0 states. For achieving this perfectly, we needed to add support for situations where we get XferNotReady while endpoint is still busy and XferNotReady while gadget driver still hasn't queued a request. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
In case we have transfers which aren't aligned to wMaxPacketSize, we need to be careful with how we start the transfer with the HW. OUT transfers _must_ be aligned with wMaxPacketSize and in order to guarantee that, we use a bounce buffer. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
trivial patch. No functional changes. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
- 22 Aug, 2011 1 commit
-
-
Felipe Balbi authored
The DesignWare USB3 is a highly configurable IP Core which can be instantiated as Dual-Role Device (DRD), Peripheral Only and Host Only (XHCI) configurations. Several other parameters can be configured like amount of FIFO space, amount of TX and RX endpoints, amount of Host Interrupters, etc. The current driver has been validated with a virtual model of version 1.73a of that core and with an FPGA burned with version 1.83a of the DRD core. We have support for PCIe bus, which is used on FPGA prototyping, and for the OMAP5, more adaptation (or glue) layers can be easily added and the driver is half prepared to handle any possible configuration the HW engineer has chosen considering we have the information on one of the GHWPARAMS registers to do runtime checking of certain features. More runtime checks can, and should, be added in order to make this driver even more flexible with regards to number of endpoints, FIFO sizes, transfer types, etc. While this supports only the device side, for now, we will add support for Host side (xHCI - see the updated series Sebastian has sent [1]) and OTG after we have it all stabilized. [1] http://marc.info/?l=linux-usb&m=131341992020339&w=2Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-