Commit Graph

244 Commits

Author SHA1 Message Date
John Youn 77966eb85e usb: dwc3: Validate the maximum_speed parameter
Check that dwc->maximum_speed is set to a valid value. Also add an error
when we use it later if we encounter an invalid value.

Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
2016-03-04 15:14:38 +02:00
John Youn 7580862b3e usb: dwc3: Enable SuperSpeedPlus
Enable SuperSpeedPlus by programming the DCFG.speed and after
enumerating, set gadget->speed appropriately.

Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
2016-03-04 15:14:27 +02:00
John Youn ee5cd41c91 usb: dwc3: Update speed checks for SuperSpeedPlus
Update various places where the speed is checked so that it takes into
account SuperSpeedPlus properly.

Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
2016-03-04 15:14:27 +02:00
John Youn c450960187 usb: dwc3: Fix assignment of EP transfer resources
The assignement of EP transfer resources was not handled properly in the
dwc3 driver. Commit aebda61871 ("usb: dwc3: Reset the transfer
resource index on SET_INTERFACE") previously fixed one aspect of this
where resources may be exhausted with multiple calls to SET_INTERFACE.
However, it introduced an issue where composite devices with multiple
interfaces can be assigned the same transfer resources for different
endpoints. This patch solves both issues.

The assignment of transfer resources cannot perfectly follow the data
book due to the fact that the controller driver does not have all
knowledge of the configuration in advance. It is given this information
piecemeal by the composite gadget framework after every
SET_CONFIGURATION and SET_INTERFACE. Trying to follow the databook
programming model in this scenario can cause errors. For two reasons:

1) The databook says to do DEPSTARTCFG for every SET_CONFIGURATION and
SET_INTERFACE (8.1.5). This is incorrect in the scenario of multiple
interfaces.

2) The databook does not mention doing more DEPXFERCFG for new endpoint
on alt setting (8.1.6).

The following simplified method is used instead:

All hardware endpoints can be assigned a transfer resource and this
setting will stay persistent until either a core reset or hibernation.
So whenever we do a DEPSTARTCFG(0) we can go ahead and do DEPXFERCFG for
every hardware endpoint as well. We are guaranteed that there are as
many transfer resources as endpoints.

This patch triggers off of the calling dwc3_gadget_start_config() for
EP0-out, which always happens first, and which should only happen in one
of the above conditions.

Fixes: aebda61871 ("usb: dwc3: Reset the transfer resource index on SET_INTERFACE")
Cc: <stable@vger.kernel.org> # v3.2+
Reported-by: Ravi Babu <ravibabu@ti.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
2016-02-17 10:31:53 +02:00
Jianqiang Tang 6a4290cc28 usb: dwc3: gadget: set the OTG flag in dwc3 gadget driver.
This patch is needed in order to pass one test case
defined in the OTG Automated Compliance Test specification.

Specification location:
http://www.usb.org/developers/onthego/otgeh_compliance_plan_1_2.pdf

This test case uses PET Tool, and PET Tool is one USB hardware
equipment provided by MQP Electronics.

Test case id is 6.8.3 B-UUT Bypass Capacitance.

We must set this otg flag in order to be able to return OTG
descriptor during enumeration, otherwise this test case with
failed with below error: "Get OTG descriptor request stalled".

Signed-off-by: Jianqiang Tang <jianqiang.tang@intel.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
2016-02-03 23:58:20 +02:00
John Youn d9261898a4 usb: dwc3: gadget: don't send extra ZLP
If the request->length is zero, a ZLP should already be sent due to that
and another ZLP is not needed to terminate the transfer.

Fixes: 04c03d10e5 ("usb: dwc3: gadget: handle request->zero")
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-12-22 21:58:26 -06:00
Felipe Balbi 95ca961c75 usb: dwc3: gadget: pass a condition to dev_WARN_ONCE()
instead of using:

	if (condition) {
		dev_WARN_ONCE(dev, true, "foo");
		return -EINVAL;
	}

let's use:

	if (dev_WARN_ONCE(dev, condition, "foo"))
		return -EINVAL;

Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-12-16 10:07:27 -06:00
Felipe Balbi 04c03d10e5 usb: dwc3: gadget: handle request->zero
So far, dwc3 has always missed request->zero
handling for every endpoint. Let's implement
that so we can handle cases where transfer must
be finished with a ZLP.

Note that dwc3 is a little special. Even though
we're dealing with a ZLP, we still need a buffer
of wMaxPacketSize bytes; to hide that detail from
every gadget driver, we have a preallocated buffer
of 1024 bytes (biggest bulk size) to use (and
share) among all endpoints.

Reported-by: Ravi B <ravibabu@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-12-15 09:12:41 -06:00
Felipe Balbi b5d335e5ea usb: dwc3: ep0: fix setup_packet_pending initialization
It just ocurred to me that dwc3 already gives a
really hint of when a setup packet is pending and
that's the SETUP_PENDING TRB Status for EP0 IRQs.

Fix setup_packet_pending initialization based on
that. While at that, also make sure the comment in
gadget.c matches what code is doing.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-12-15 09:12:41 -06:00
Felipe Balbi ac7bdcc1b3 usb: dwc3: gadget: simplify next_request() return check
In dwc3_cleanup_done_reqs() we expect that all
iterations of our while (1) loop will find a valid
struct dwc3_request *. In case we don't, we're
dumping a WARN_ON_ONCE() splat so that people report
the failure.

This patch is a simple cleanup converting:

	if (!req) {
		WARN_ON_ONCE(1);
		return 1;
	}

to:

	if (WARN_ON_ONCE(!req))
		return 1;

which is a little easier to read.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-12-15 09:12:41 -06:00
Felipe Balbi ec5e795cde usb: dwc3: gadget: purge dev_dbg() calls
The last few dev_dbg() messages are converted to
tracepoints and we can finally ignore dev_dbg()
messages during debug sessions.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-12-15 09:12:41 -06:00
Felipe Balbi bb423984c2 usb: dwc3: gadget: simplify dwc3_gadget_ep_queue()
By moving our sanity checks our internal function
__dwc3_gadget_ep_queue() we can simplify the
externally visible API while also making sure that
callers of __dwc3_gadget_ep_queue() also make use of
the same checks.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-12-15 09:12:41 -06:00
Felipe Balbi 62e345ae5b usb: dwc3: gadget: don't prestart interrupt endpoints
Because interrupt endpoints usually transmit such
small amounts of data, it seems pointless to prestart
transfers and try to get speed improvements. This
patch also sorts out a problem with CDC ECM function
where its notification endpoint gets stuck in busy
state and we continuously issue Update Transfer
commands.

Fixes: 8a1a9c9e45 ("usb: dwc3: gadget: start transfer on XFER_COMPLETE")
Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-11-30 15:35:14 -06:00
Ben McCauley b9e51b2b1f usb: dwc3: gadget: let us set lower max_speed
In some SoCs, dwc3 is implemented as a USB2.0 only
core, meaning that it can't ever achieve SuperSpeed.

Currect driver always sets gadget.max_speed to
USB_SPEED_SUPER unconditionally. This can causes
issues to some Host stacks where the host will issue
a GetBOS() request and we will reply with a BOS
containing Superspeed Capability Descriptor.

At least Windows seems to be upset by this fact and
prints a warning that we should connect $this device
to another port.

[ balbi@ti.com : rewrote entire commit, including
source code comment to make a lot clearer what the
problem is ]

Cc: <stable@vger.kernel.org>
Signed-off-by: Ben McCauley <ben.mccauley@garmin.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-11-17 11:35:48 -06:00
Ville Syrjälä d115d7050a Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"
This reverts commit 8f2c9544ab.

As it breaks g_ether on my Baytrail FFRD8 device. Everything starts out
fine, but after a bit of data has been transferred it just stops
flowing.

Note that I do get a bunch of these "NOHZ: local_softirq_pending 08"
when booting the machine, but I'm not really sure if they're related
to this problem.

Cc: Felipe Balbi <balbi@ti.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-10-12 13:36:13 -05:00
Felipe Balbi e5f68b4a3e Revert "usb: dwc3: gadget: remove unnecessary _irqsave()"
This reverts commit 70f3a9caa1.

That commit was causing a lockdep splat with g_ether and that
was interfering with proper functionality.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-10-12 13:32:05 -05:00
Felipe Balbi 70f3a9caa1 usb: dwc3: gadget: remove unnecessary _irqsave()
We *know* our threads executes with our IRQs
disabled. We really don't need to use the _irqsave()
variant of spin_lock().

Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-09-28 15:19:31 -05:00
Felipe Balbi e6e709b7ab usb: dwc3: gadget: use Update Transfer from Xfer In Progress
Instead of limiting __dwc3_gadget_kick_transfer() to
Xfer Complete, we can try to issue Update Transfer
command from Xfer In Progress too.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-09-28 15:19:31 -05:00
Felipe Balbi 6bb4fe12ea usb: dwc3: gadget: use update transfer command
If we get a Xfer Not Ready event with reason
"Transfer Active" it means endpoint is still
transferring data and we can use that to issue
update transfer for this particular endpoint
in case we have pending requests in our queue.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-09-28 15:19:31 -05:00
Felipe Balbi 8a1a9c9e45 usb: dwc3: gadget: start transfer on XFER_COMPLETE
if by the time we get to XFER_COMPLETE we have
pending requests to be processed, instead of waiting
for a following XFER_NOT_READY, let's start the request
right away and, maybe, save the time of a few NAKs
due to lack of started transfers.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-09-28 14:17:26 -05:00
Felipe Balbi a8f32817ee usb: dwc3: gadget: improve ep_queue's error reporting
We shouldn't return -EBUSY, that's used only internally
when the core still has transfers in flight on a given
endpoint.

Also, combine the error reporting so that we don't have
to duplicate it.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-09-27 10:54:31 -05:00
Felipe Balbi 89185916d2 usb: dwc3: gadget: clear DWC3_PENDING_REQUEST when request is queued
Instead of clearing DWC3_PENDING_REQUEST when
we start transfer, let's do it when the request
is actually queued, that way we know for sure
that we're clearing in the right time.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-09-27 10:54:31 -05:00
Felipe Balbi 1d6a39186b usb: dwc3: gadget: start requests as soon as they come
In an attempt to make dwc3 slightly faster, let's
start usb_requests as soon as they come as that will
let us avoid a XFER_NOT_READY event and save a little
bit of time.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-09-27 10:54:31 -05:00
Felipe Balbi fe84f522ed usb: dwc3: gadget: move trace_dwc3_ep_queue()
by moving trace_dwc3_ep_queue() from dwc3_gadget_ep_queue()
to __dwc3_gadget_ep_queue() after usb_request is properly
initialized, makes for a better output always showing a
request with 0 actual and -115 (-EINPROGRESS) status.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-09-27 10:54:31 -05:00
Roger Quadros a66c275b3d usb: dwc3: gadget: Fix BUG in RT config
Using spin_lock() in hard irq handler is pointless
and causes a BUG() in RT (real-time) configuration
so get rid of it.

The reason it's pointless is because the driver is
basically accessing register which is, anyways,
atomic.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-09-21 14:42:36 -05:00
Robert Baldyga a474d3b73b usb: dwc3: gadget: add ep capabilities support
Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-08-04 12:25:59 -05:00
Kishon Vijay Abraham I 2abd9d5fa6 usb: dwc3: ep0: Add chained TRB support
Add chained TRB support to ep0. Now TRB's can be chained just by
invoking _dwc3_ep0_start_trans_ with 'chain' parameter set to true.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-07-30 11:43:34 -05:00
Felipe Balbi aa7399744d usb: dwc3: gadget: defer endpoint name change
We should only change endpoint names when we
actually manage to enable/disable it.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-07-29 09:59:19 -05:00
Felipe Balbi 7eaeac5c0e usb: dwc3: gadget: add a trace when disabling EPs
We have a "Enabling %s" trace when enabling an endpoint
but that message felt lonely without a matching
"Disabling %s". Add it.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-07-29 09:59:19 -05:00
Felipe Balbi e18b7975c8 usb: dwc3: gadget: don't clear EP_BUSY too early
In case of non-Isochronous transfers, we don't
want to clear DWC3_EP_BUSY flag until XferComplete
event. That's because XferInProgress was only enabled
so we can recycle TRBs and usb_requests quicker, but
there are still other pending requests being transferred.

In order to make sure we don't allow for another StartTransfer
command while the HW is still processing other transfers,
we must keep DWC3_EP_BUSY flag set and this what this patch
does.

Fixes: f3af36511e (usb: dwc3: gadget: always enable IOC on
	bulk/interrupt transfers)
Cc: <stable@vger.kernel.org> # v3.15+
Reported-by: sundeep subbaraya <sundeep.lkml@gmail.com>
Tested-by: sundeep subbaraya <sundeep.lkml@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-05-29 10:19:51 -05:00
Subbaraya Sundeep Bhatta 76e838c9f7 usb: dwc3: gadget: return error if command sent to DEPCMD register fails
We need to return error to caller if command is not sent to
controller succesfully.

Signed-off-by: Subbaraya Sundeep Bhatta <sbhatta@xilinx.com>
Fixes: 72246da40f (usb: Introduce DesignWare USB3 DRD Driver)
Cc: <stable@vger.kernel.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-05-26 10:39:29 -05:00
Subbaraya Sundeep Bhatta 891b1dc022 usb: dwc3: gadget: return error if command sent to DGCMD register fails
We need to return error to caller if command is not sent to
controller succesfully.

Signed-off-by: Subbaraya Sundeep Bhatta <sbhatta@xilinx.com>
Fixes: b09bb64239 (usb: dwc3: gadget: implement Global Command support)
Cc: <stable@vger.kernel.org> #v3.5+
Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-05-26 10:39:23 -05:00
Felipe Balbi 8f2c9544ab usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs
Now that we're using XFERINPROGRESS for all endpoint
types (except Control), we will *always* be completing
one TRB at a time, so it's safe to remove the loop
from dwc3_cleanup_done_reqs.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-03-09 10:38:49 -05:00
Peter Chen bcdea50312 usb: dwc3: gadget: use common is_selfpowered
Delete private selfpowered variable, and use common one.

Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-01-29 10:35:40 -06:00
Felipe Balbi 5c7b3b02de usb: dwc3: gadget: add missing spin_lock()
commit 8e74475b0e (usb: dwc3: gadget: use udc-core's
reset notifier) added support for the new UDC core's
reset notifier to dwc3 but while at it, it removed
a spin_lock() from dwc3_reset_gadget() which might
cause an unbalanced spin_unlock() further down the line

Fixes: 8e74475b0e (usb: dwc3: gadget: use udc-core's reset notifier)
Cc: <stable@vger.kernel.org> # v3.19
Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-01-29 10:29:18 -06:00
Felipe Balbi 73815280a5 usb: dwc3: remove reliance on dev_vdbg()
By moving all dev_vdbg() to tracepoints, we
can finally get rid of dev_vdbg() usage from
dwc3.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-01-27 14:00:10 -06:00
Felipe Balbi e9f2aa871c usb: dwc3: gadget: WARN() in case of unknown IRQ
if an unknown IRQ event is triggered, that means
the HW is really misbehaving. Instead of printing
a debug message, let's WARN() so users report
when that happens.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-01-27 13:56:10 -06:00
Felipe Balbi 4cd8f6d055 usb: dwc3: gadget: avoid variable shadowing
We already have both ret and dwc defined in this
same function.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-01-27 13:25:09 -06:00
Felipe Balbi d1fc4440d7 Linux 3.19-rc5
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQEcBAABAgAGBQJUu0x7AAoJEHm+PkMAQRiGH/8H/14SgHC8A+tGEY1Hmgr7Y6ah
 kAcev/QMIxvtxKK0zdhgSILiBUrbK1CAXFGbueUAHgSaCucry5rpJvhFCIzSaCmm
 60yLZKvNrxXX4Zc1SYxxW+2EfDCNd0tO6uZK30kyzYYmw6fCgLMEXL6pFI0wFJRg
 G41yL7MogjJJP0JFGjwrFTeJ6ZBahErOmMpx1qrHuDN8cbdZvG8w6A0KP7ch6Ct1
 qdwcpOK4L9AXG+fbE7AJCSBkVev4KqwknPSWQ+jWX7ftw3q0P1O6dXY94ob3PqVi
 jsWmraOCd5uJrX9uSiOJCsbwoaHHMTNOsEF71qQKDrQzcGCPJAxd1Mi696JdDAQ=
 =jNTS
 -----END PGP SIGNATURE-----

Merge tag 'v3.19-rc5' into next

Linux 3.19-rc5

Conflicts:
	drivers/usb/dwc2/gadget.c
	drivers/usb/gadget/udc/bdc/bdc_ep.c
2015-01-19 09:57:20 -06:00
Amit Virdi 39e60635a0 usb: dwc3: gadget: Stop TRB preparation after limit is reached
DWC3 gadget sets up a pool of 32 TRBs for each EP during initialization. This
means, the max TRBs that can be submitted for an EP is fixed to 32. Since the
request queue for an EP is a linked list, any number of requests can be queued
to it by the gadget layer.  However, the dwc3 driver must not submit TRBs more
than the pool it has created for. This limit wasn't respected when SG was used
resulting in submitting more than the max TRBs, eventually leading to
non-transfer of the TRBs submitted over the max limit.

Root cause:
When SG is used, there are two loops iterating to prepare TRBs:
 - Outer loop over the request_list
 - Inner loop over the SG list
The code was missing break to get out of the outer loop.

Fixes: eeb720fb21 (usb: dwc3: gadget: add support for SG lists)
Cc: <stable@vger.kernel.org> # v3.9+
Signed-off-by: Amit Virdi <amit.virdi@st.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-01-14 11:29:05 -06:00
Amit Virdi ec512fb8e5 usb: dwc3: gadget: Fix TRB preparation during SG
When scatter gather (SG) is used, multiple TRBs are prepared from one DWC3
request (dwc3_request). So while preparing TRBs, the 'last' flag should be set
only when it is the last TRB being prepared from the last dwc3_request entry.

The current implementation uses list_is_last to check if the dwc3_request is the
last entry from the request_list. However, list_is_last returns false for the
last entry too. This is because, while preparing the first TRB from a request,
the function dwc3_prepare_one_trb modifies the request's next and prev pointers
while moving the URB to req_queued. Hence, list_is_last always returns false no
matter what.

The correct way is not to access the modified pointers of dwc3_request but to
use list_empty macro instead.

Fixes: e5ba5ec833 (usb: dwc3: gadget: fix scatter gather implementation)
Signed-off-by: Amit Virdi <amit.virdi@st.com>
Cc: <stable@vger.kernel.org> # v3.9+
Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-01-14 11:28:23 -06:00
Amit Virdi 110381e11b usb: dwc3: gadget: Remove redundant check
dwc3_gadget_init_hw_endpoints calls dwc3_alloc_trb_pool only if epnum is not
equal to 0 or 1. Hence, rechecking it in the called function is redundant.

Signed-off-by: Amit Virdi <amit.virdi@st.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-01-12 12:13:24 -06:00
Mickael Maison dc93b41a15 usb: dwc3: Fixed a typo in comments
Fixed a typo in comments

Signed-off-by: Mickael Maison <mickael.maison@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-01-12 12:13:24 -06:00
Felipe Balbi 8e74475b0e usb: dwc3: gadget: use udc-core's reset notifier
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
2014-11-10 17:19:34 -06:00
Huang Rui 460d098cb6 usb: dwc3: make HIRD threshold configurable
HIRD threshold should be configurable by different platforms.

From DesignWare databook:
When HIRD_Threshold[4] is set to 1b1 and HIRD value is greater than or
equal to the value in HIRD_Threshold[3:0], dwc3 asserts output signals
utmi_l1_suspend_n to put PHY into Deep Low-Power mode in L1.

When HIRD_Threshold[4] is set to 1b0 or the HIRD value is less than
HIRD_Threshold[3:0], dwc3 asserts output signals utmi_sleep_n on L1.

Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
2014-11-03 10:03:41 -06:00
Huang Rui 80caf7d21a usb: dwc3: add lpm erratum support
When parameter DWC_USB3_LPM_ERRATA_ENABLE is enabled in Andvanced
Configuration of coreConsultant, it supports of xHCI BESL Errata Dated
10/19/2011 is enabled in host mode. In device mode it adds the capability
to send NYET response threshold based on the BESL value received in the LPM
token, and the threhold is configurable for each soc platform.

This patch adds an entry that soc platform is able to define the lpm
capacity with their own device tree or bus glue layer.

[ balbi@ti.com : added devicetree documentation, spelled threshold
		completely, made sure threshold is only applied to
		proper core revisions. ]

Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
2014-11-03 10:03:36 -06:00
Felipe Balbi 22835b807e usb: gadget: remove unnecessary 'driver' argument
now that no UDC driver relies on the extra
'driver' argument to ->udc_stop(), we can
safely remove it.

This commit is based on previous work by
Robert Baldyga <r.baldyga@samsung.com> which
can be found at [1]; however that patch turned
out to have a high probability of regressing
many UDC drivers because of a blind search & replace
s/driver/$udc->driver/ which caused the 'driver'
argument to stop_activity() to be a valid non-NULL
pointer when it should be NULL, thus causing UDCs
to mistakenly call gadget driver's ->disconnect()
callback.

[1] http://markmail.org/message/x5zneg4xea4zntab

Acked-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
2014-11-03 10:01:16 -06:00
Felipe Balbi 73359cef4f usb: dwc3: gadget: WARN() on bogus usb_ep_queue()
Some gadget/function drivers might want to do
improper request recycling by allocating a single
request from one particular endpoint and queueing
it to another completely unrelated endpoint.

One such case was found with f_loopback.c.

To prevent such cases from happening again, let's
WARN() so we get a loud enough failure and persuade
users to report errors.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2014-11-03 10:01:00 -06:00
Felipe Balbi 06a374ed13 usb: dwc3: gadget: set state to NOT_ATTACHED on disconnect_irq
whenever we get a Disconnect Interrupt, we should
make sure to update out udc state to NOT_ATTACHED,
otherwise sysfs will show wrong values.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2014-11-03 10:01:00 -06:00
Felipe Balbi 0b0231aa24 usb: dwc3: get rid of ->prepare()/->complete()
Using ->prepare()/->complete() to mask/unmask
IRQs is wrong at least for dwc3. We need to
make sure that by the end of ->resume(), IRQs
are working and ready to fire because a child
device may need working IRQs for its own ->resume()
method.

Signed-off-by: Felipe Balbi <balbi@ti.com>
2014-11-03 10:00:58 -06:00