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>
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>
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>
vbus power routine can be different based on platform. If vbus power
sequence is provided using platform data(pdata), disconnect of OTG cable
doesn't turn off the VBUS related regulators and required other
interfaces. This issue is seen as vbus_is_on variable remains always zero
for pdata based vbus routine, and msm_hsusb_vbus_power(motg, 0) doesn't
invoke the required vbus power routine. Hence update the vbus_is_on
variable based on return value of pdata based vbus routine. With this
change, it is mandatory that pdata based vbus routine should return the
success/failure result.
CRs-Fixed: 332434
Change-Id: I4c7ce48057f65227b09aac788d0ad24d0f30ed7e
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
BAM DMUX driver gives the data to the USB in work context and USB
is once again scheduling work for sending the data to the host.
This change avoid's the double work queue scheduling for the data
received from BAM DMUX, which might reduce the cpu usage and improve
the throughputs.
Change-Id: Ib66bc7f46f9436704e0d28b72771de50462ddf4b
Signed-off-by: Chiranjeevi Velempati <cvelempa@codeaurora.org>
Till now, we are communicating only the amount of the current that
should be drawn by the PMIC for charging from the OTG driver through
power supply class driver. With this change, we notify the type of the
charger connected as well, so that userspace can benefit for dispalying
the charger type in the UI.
CRs-Fixed: 329868
Change-Id: Ibe92c4450bc9b4b023b9aceab57b624bde39a4fe
Signed-off-by: Chiranjeevi Velempati <cvelempa@codeaurora.org>
Add a retry to handle the case where the SMD port is
closed and a re-open is attempted before the SMD port
close event has been processed by the remote processor.
CRs-Fixed: 327710
Change-Id: I112dc3ff3712d2a8900e4e02bcd296b50dfe0b24
Signed-off-by: Eric Holmberg <eholmber@codeaurora.org>
The D0 clock buffer is ignored by the RPM and thus the RPM turns
off D0 even when Linux has requested it. Vote on CXO_CLK instead
until the RPM properly handles D0+CXO_CLK resources.
Change-Id: Ie69b7aebabf9638878a75026a99be76eeed7ecd8
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
During subsystem restart, SMD_EVENT_CLOSE is sent via callback,
which the DUN and RMNET control modules mistakenly interpret as the
channel being closed automatically. This causes a problem when the
modem comes back online and notifies via SMD_EVENT_OPEN: the gadget
driver now has a handle to an open SMD channel even without a USB
connection. Then when the USB cable is reconnected, due to disconnect
being called first, it accidentally closes the re-opened channel,
causing the following smd_open() to fail because it is busy being
closed.
Instead, simply always call smd_close() on actual disconnect,
so that the subsequent connect will successfully be able to open the
channel.
CRs-fixed: 327710
Change-Id: Ia7b3e52638f9bdc96c083cb16e0231e7af7ff884
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Some Windows hosts are not dropping DTR during suspend, but are
setting DTR as part of resume. Hence, send DTR set to zero to
the Modem when the rmnet interface is suspended.
Change-Id: I9137021e2c4074c71e9142e7dbac2042311b3c4d
Signed-off-by: Chiranjeevi Velempati <cvelempa@codeaurora.org>
This change adds support to keep track of total time spent by a SKB in
UL and DL directions. Timestamps are recorded per SKB for the complete
life cycle at following stages:-
1) Creation: At the time of SKB allocation.
2) Submission: While SKB being submitted to HSIC HW by bridge driver/
HSUSB Core by rmnet gadget driver.
3) Completion: In completion handler of the driver(bridge driver/
gadget rmnet driver).
4) Sent: While sending SKB to bridge driver/rmnet gadget driver.
5) Queued: While SKB being queued to HSIC HW by bridge driver/
HSUSB Core by rmnet gadget driver.
6) Done: In completion handler while freeing the SKB.
debugfs node /sys/kernel/debug/data_hsic_bridge/timestamp represents the
listing of timestamp for last 34 SKBs submitted in UL direction.
debugfs node /sys/kernel/debug/ghsic_data_xport/timestamp represents the
listing of timestamp for last 34 SKBs submitted in DL direction.
Recording of the time stamp is controlled by the module parameter in
rmnet bridge driver and rmnet gadget driver.
To enable the recording of timestamp in rmnet bridge driver
echo 1 > /sys/module/mdm_bridge/parameters/record_timestamp
To enable the recording of timestamp in rmnet gadget driver
echo 1 > /sys/module/g_android/parameters/record_timestamp
Change-Id: I10e7c171eec6a01afbd48328ba006f776370ac92
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Rmnet bridge driver sets IOC bit for every URB having IP
packet data in TX direction. This causes the driver to spend
more time in servicing interrupts which degrades the over all
performance of the driver. Hence reduce the number of interrupts
in TX data path by setting URB_NO_INTERRUPT flag for certain number
of urbs submitted.
Change-Id: I784ffca6d97acffd6eed49f68f0b8c30a9b2f0e4
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
