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: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
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>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
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>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
data was prepared on setup_buf but transfer
was started on ctrl_req, fix it.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
There are two spots where we wait until the HW finishes processing a
certain command. Initially we had a few problems and we used 500ms as a
limit to be on a the safe side. Paul Zimmerman mentioned this is little too
much. After a debugging session, we noticed that we hardly ever go over 20us
and didn't pass 30usec so far. Using mdelay() seems way overloaded.
Giving the current numbers 500usec as the upper limit is more than enough.
Should it ever timeout then something is definitely wrong.
While here, also replace the type with u32 since long does not really
fit here.
Cc: Paul Zimmerman <paul.zimmerman@synopsys.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
- 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: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
We read the DWC3_GSNPSID register to make sure we got the correct
register offset passed. One of the recent commits moved the soft reset
before this so in case of the wrong offset we end up with "reset timed
out". This patch moves the "id" check before the reset again.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
There are some issues around for enabling/disabling this mode and
handling it. It does not work perfectly (yet). However we have a few
gadgets tested successfuly so far. That means we are quite confident
that we won't need this in near future.
So I'm for removing it and bringing a working version back once there is
a need for it.
Thanks to Dan Carpenter who spotted the wrong memory handling here.
[ balbi@ti.com : made it actually apply ]
Cc: Dan Carpenter <error27@gmail.com>
Cc: wharms@bfs.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
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>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
Add a flag to keep track of ep0 direction.
This flag will be used on a following patch.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
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>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
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: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
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: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
the previous message had too little meaning. Make
it more human readable and use the macro we already
had for extracting the command completion status out
of DEPCMDn register.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
if we don't set DMA address to invalid when unmapping,
we might fall in a situation where request buffer
can't be mapped to DMA again.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
We may as well fix this potential leak so we don't have to listen to
the static checkers complain.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
Without this patch we won't clear that bit and instead will
clear all other bits on our endpoint flag.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
Type 6 should be used for the first transfer during an interval. This is
also what the reference driver is using. Type 7 seems to be for following
or additional transfers within the same interval.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
If we collected two requests together (i.e. only the last of them has
LST=1) then we only have to stop transfer once: The clean-up code will
cleanup everything until first TRB with the LST bit set.
After XferComplete this index should be no longer valid since there is
no transfer pending.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
A TRB which is dequeued seems to have its HWO bits set to 1. Therefore
we ignore it if we dequeue it after the command is completed.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
Fixes this build error:
drivers/usb/dwc3/dwc3-pci.c: In function 'dwc3_pci_init':
drivers/usb/dwc3/dwc3-pci.c:211:9: error: 'THIS_MODULE' undeclared (first use in this function)
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
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=2
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[idos@codeaurora.org: gadget_chips.h: Use 'gadget_is_dwc3(g)' only if
CONFIG_USB_GADGET_DWC3 is defined.]
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
USB battery charging specification defines that device should
not start charging from SDP (or host port) before connecting
i.e. pulling high data line.
Hence, instead of charging immediately after performing detection,
wait till device configuration is selected by host.
Change-Id: I77dd29d1b4fbb57bc2f4362ef77d6a9c73ab6653
CRs-Fixed: 333556
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
RMNET driver uses SMD channels to communicate with modem.
Opening of SMD channels can fail if modem is not up by
the time smd_open is called by rmnet. This driver currently
attepts to open SMD channel only once at USB cable connect
and doesn't retry incase of failure.
In such scenarios RMNET connection works only after USB cable
is plugged-in again. Hence, register a platform driver so that
RMNET can retry opening of SMD channel once modem is up or
rather corresponding SMD channel is ready to be opened.
CRs-Fixed: 333051
Change-Id: I353fb6b48b226c2a186142663839ef18907458e3
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
wait_for_completion_timeout() may timeout before
overlay1_done interrupt when one vsync timeout is specified.
This cause mdp4_overlay_dtv_ wait4_ov_done() to return prematurely
which causes a falsely increased FPS. This patch increases the timeout
value to 2 vsync to prevent premature timeout.
Crs-fixed: 330723
Change-Id: Iac516525f328be01cf81ce3f4e95e5d6a4ab80ca
Signed-off-by: kuogee hsieh <khsieh@codeaurora.org>
Unable to open smd channel if smd_open is called right after
smd_close resulting in rmnet tethered call failure. To avoid
such failures, retry opening smd channel based on return type.
Change-Id: I2c37a6c8bc9b5707de1ce5b9eec8f884c1ab30bd
Signed-off-by: Chiranjeevi Velempati <cvelempa@codeaurora.org>
Insert break statement at appropriate case statement
in a switch condition. If no break statement resulting
in corruption for next case statement.
CRs-fixed: 333684
Change-Id: Icc617ac11d90ccfdcd33ea1d5a3f421935f595ad
Signed-off-by: Maheshwar Ajja <majja@codeaurora.org>
The sole purpose of android composite driver registering as a
platform driver is to receive a board file callback which updates
the USB serial number in a memory accessible to boot loader.
This driver is using platform_driver_probe() method to register
as a platform driver. This API expects the platform device to
be registered before calling this API. This driver init function
is failing on boards which does not have android platform device
registered. As android platform device registration is optional,
use platform_driver_register API.
Change-Id: I3aa75d70f691021cb5d6ada29677a19e3ad9821b
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
USB S/W on 9x15 is designed to handle 65K packet size for
flashless boot and efs-sync functions. Match buffers on 8064
usb host mode driver to achieve better throughput.
Change-Id: I6f5b50d08ad4ea59e770e2a3e8ad00d944f05e54
Signed-off-by: Vamsi Krishna <vskrishn@codeaurora.org>
Not all chargers can support 1500mA. If a high current is drawn from
such a charger, it drops its voltage rapidly. The vin_min regulation
loop does not kick in because of such rapid decline in the voltage.
This drop causes the pmic to see that the charger is removed and it
stops drawing any current from it. This in turn causes the charger to
raise its voltage but the pmic again draws a high current causing it
to collapse. This collapse and build up or removal and reinsertion
continues indefinitely.
Use the max_current module parameter to set the max
current drawn from charger to prevent it from collapsing voltage.
Also an issue was noticed when sometimes the system enters suspend
while the wall charger is plugged in and charging starts while the
device is suspended. Make the fastchg interrupt wake able so that the
driver can start end of charge worker.
Change-Id: I03f7f60d0bc8a87f7da59af947649a8190ab7994
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
