- 12 12月, 2011 12 次提交
-
-
由 Felipe Balbi 提交于
RTL revisions <1.83a have an issue where, depending on the link partner, the USB link might do multiple entry/exit of low power states before a transfer takes place causing degraded throughput. The suggested workaround is to clear bits 12:9 of DCTL register if we see a transition from U1|U2 to U0 and only re-enable that on a transfer complete IRQ and we have no pending transfers on any of the enabled endpoints. Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
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: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
There are two where need to set operational mode: - during initialization while we decide to run in host,device or DRD mode - at runtime via the debugfs interface. This patch provides a new function which sets the operational mode and moves its initialiation to the mode switch instead in the gadget code itself. Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Felipe Balbi 提交于
hardware will tell us how many event buffers we need to support, so let's allocate the array dynamically too. Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Felipe Balbi 提交于
if we want to support situations where we have both SoC and PCIe versions of the IP on the same platform, we need to have sequential numbers between them, otherwise we will still have name collisions. Because of that, we need to move dwc3_get/put_device_id() to core.c and export that symbol to be used by glue layers. Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
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: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Felipe Balbi 提交于
This makes testing a lot easier when trying to switch between host and device modes. Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Felipe Balbi 提交于
host prototypes are there, let's move gadget's closer. Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Felipe Balbi 提交于
The Designware USB3 IP can be configured with an internal xHCI. If we're running on such a version, let's start the xHCI stack. Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Felipe Balbi 提交于
There's no need to add driver_data for something we can fetch from HW. This also makes our id_table unnecessary - at least for now -, so we also remove it on the same patch. Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Felipe Balbi 提交于
This will allow us to only allocate memory when we actually need. Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Felipe Balbi 提交于
this is mainly for testing. In order to be able to test if we're enumerating correctly on all speeds, let that be controlled by a module parameter. Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
- 05 10月, 2011 5 次提交
-
-
由 Felipe Balbi 提交于
The dwc3 core has internal clock gating support. Let's allow that to happen by clearing the disable bit in GCTL register. Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Felipe Balbi 提交于
That structure will hold a copy of readonly GHWPARAMS* registers for ease accessing by the driver. Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Felipe Balbi 提交于
The following patch adds support for streams to dwc3 driver. While at that, also fix one small issue on endpoint disable where we should clear all flags not only ENABLED. Reviewied-by: NPaul Zimmerman <paulz@synopsys.com> Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Paul Zimmerman 提交于
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: NPaul Zimmerman <paulz@synopsys.com> Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
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: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 09 9月, 2011 11 次提交
-
-
由 Felipe Balbi 提交于
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: NFelipe Balbi <balbi@ti.com>
-
由 Felipe Balbi 提交于
We must ensure that those bits aren't set as they should only be used in simulation. Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Felipe Balbi 提交于
that should be 1 << 16, not 16. Caused so many problems and we never caught it before. Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Felipe Balbi 提交于
this field will hold the next expected event. In certain cases, host might fall into some error condition and ask from us the wrong Control phase. On such situations, we should stall and restart. Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Felipe Balbi 提交于
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: NFelipe Balbi <balbi@ti.com>
-
- since a while we are disabling an endpoint and purging every requests on RESET and DISCONNECT which leads to a warning since the endpoint was disabled twice (once by the UDC, and second time by the gadget). I think UDC should nuke all requests because all those requests become invalid. It's gadget driver's responsability, though, to disable its used endpoints. This is done by merging dwc3_stop_active_transfer() and dwc3_gadget_nuke_reqs() into dwc3_remove_requests(). - dwc3_stop_active_transfer() is now no longer called unconditionaly. This has the advantage that it is always called to disable an active transfer which means if res_trans_idx 0 than something went wrong and it is an error condition because we can't clean up the requests. - Remove the DWC3_EP_WILL_SHUTDOWN which was introduced while introducing the command complete part for dequeue. All requests on req_queued list should be removed during the dwc3_cleanup_done_reqs() callback so there is no reason to go through the list again. We consider it an error condition if requests are still on this list since we never queue TRB without LST=1 (the last requests has always LST=1, there are no requests with LST=0 behind it). [ balbi@ti.com : reworked commit log a bit, made patch apply ] Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Felipe Balbi 提交于
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: NFelipe Balbi <balbi@ti.com>
-
由 Felipe Balbi 提交于
Add a flag to keep track of ep0 direction. This flag will be used on a following patch. Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Felipe Balbi 提交于
This core cannot handle OUT transfers which aren't aligned to wMaxPacketSize, but that can happen at least on control endpoint with the USB Audio Class. This patch adds a bounce buffer to be used on the case of a non-aligned ep0out request is queued. Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Felipe Balbi 提交于
The status field of the Transfer Not Read event is different on Control Endpoints. On this patch we are just adding the defines to be used on a later patch which will re-work the control endpoint handling. Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Felipe Balbi 提交于
trivial patch, no functional changes Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
- 23 8月, 2011 1 次提交
-
-
由 Felipe Balbi 提交于
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: NFelipe Balbi <balbi@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-