Synopsys specification clearly states under section "Device Power-On or
Soft Reset" that DCTL.CSftRst=1 should be first step.  So, just follow
what specification says.
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Before taking core out of reset phy must be stable. So wait for 100ms
after clear phy reset.
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

module.h header file was included twice.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In case of ep_disable and reset interrupt is received and, still there
was at least one request queued for dma transfer, then endpoint is
stopped first. Once endpoint is stopped, callback for all queued
request must be called.
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

It is needed to enumerate recent cores like 2.10a.
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The definition of DWC3_DCTL_HIRD_THRES macro is
completely wrong. It will only work for when we
want to read the register's contents for that bitfield.

Change the macro so that it can be used to writing to
the register, and when we need to read, we can add
extra right shift of 24 bits.
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>

[ balbi@ti.com: add a commit log ]
Signed-off-by: NFelipe Balbi <balbi@ti.com>

By the time we're disabling the endpoint, HW
could already have posted more events to our
event buffer. In that case, we will receive
endpoint events for a disabled endpoint.

In order to protect ourselves from that situation,
we simply ignore endpoint interrupts whenever
the endpoint is disabled.
Tested-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In case we get disconnected, we will call gadget
driver's disconnect method, which should make
sure to disable all endpoints. At that point
we will call stop_active_transfers() to make
sure we didn't leave any pending request on the
controller.
Tested-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

That IRQ is causing way too much trouble. We have
a different handling which was agreed with IP
provider and has been tested with FPGA and OMAP5.
Tested-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We never set CMDIOC bit for Start Transfer
command, so that code will never be used.
Tested-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

If event status says that its last completed TRB but TRB is still owned
by HW then break from the loop, because we are not going to get correct
TRB status from trb control/size register.
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

If an IN transfer is missed on isoc endpoint, then driver must insure
that next ep_queue is properly handled.
This patch fixes this issue by starting a new transfer for next queued
request.
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

SOF Number is bit16:3 of DSTS. Correct the mask accordingly.
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Correct  define for DWC3_TRB_SIZE_TRBSTS.
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Currently in case of isoc, interrupt is programmed after each
TRB_NUM/4 ie 8th TRB. A TRB is programmed against each submitted
request from gadget. If we do not want to limit the minimum number of
necessary request to be submitted from gadget then we must receive
interrupt on each TRB submission. There can be such situation with a
gadget working with ping-pong buffer.

If a gadget does not want to receive interrupt after each request
completion then it may set no_interrupt flag.
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

That's a much more intuitive name as that function
is only called at the completion of a Status Phase.

It also matches dwc3_ep0_complete_data() for
the completion of Data Phase.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

USB is always little endian, but this driver
could run on non little endian cpus. Let's
be carefull with that.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

There's no need for returning early. Instead,
we can call dwc3_ep0_stall_and_restart()
conditionally.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

According to the databook, the DWC3 Core will
reset those bits to 0 on USB Bus Reset. This
means we must re-enable those bits on every
reset interrupt.

Because we will always get a Reset interrupt
after loading a gadget driver, we can, instead
of re-enabling something that was just lost,
move the handling of those bits to the Reset
Interrupt.

This patch fixes USB30CV U1/U2 Test.
Signed-off-by: NGerard CAUVY <g-cauvy1@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

If we get a disconnect IRQ, we should take
the core out of low power mode so we can
reconnect afterwards.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

If we don't read out the contents of the register
(in order to reinitialize 'reg' variable) we will
be writing unknown contents to the DCTL register
whenever we try to use dwc3_gadget_wakeup() function.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The same event buffers will be reused when coming
out of hibernation, so we must reinitialize them
properly to avoid any mistakes.

While at that, also take dwc3_event_buffers_setup()
out of __devinit section.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Recent cores (>= 1.94a) have a set of new features,
commands and a slightly different programming model.

This patch aims to support those changes.
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

those two functions don't power PHYs, they simply
put them in suspend state. Rename to reflect better
what functions actually do.
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

retries is used twice without being reinitialized.
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch adds definitions for some new registers that have been
added to later versions of the controller, up to v2.10a.
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

That semicolon doesn't do anything, it's not
needed and should be removed.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

s/has/have. No functional changes, just
a typo fix on a code comment.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

On our Transfer Not Ready handlers, only
dwc3_ep0_do_control_status() had a different
list of parameters.

Align on the parameters in order to keep consistency.

No functional changes.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

IS_ALIGNED provides a much faster operation for
checking proper size alignment then a modulo
operation. Let's use it.
Reported-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When DWC3_EP_PENDING_REQUEST flag is set for a Control OUT Data
phase transfer, we would be missing the proper handling for
unaligned OUT requests, thus hanging a transfer.

Since proper handling is already done on dwc3_ep0_do_control_data(),
we simply re-factor that function so it can be re-used from
__dwc3_gadget_ep0_queue().
Reported-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

we're now have DWC3_EP0_BOUNCE_SIZE to tell
us the actual size of the bufer. Let's use that
instead of ep0 wMaxPacketSize.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Fengguang reports that the xHCI driver isn't linked properly on his
machine:

ERROR: "__udivdi3" [drivers/usb/host/xhci-hcd.ko] undefined!
ERROR: "handle_edge_irq" [drivers/gpio/gpio-pch.ko] undefined!
ERROR: "irq_to_desc" [drivers/gpio/gpio-pch.ko] undefined!

The driver compiles fine on my 64-bit box (gcc version 4.6.1).
Fengguang thinks it's because the xHCI driver was using DIV_ROUND_UP()
instead of DIV_ROUND_UP_ULL() with arguments that were unsigned long
long variables.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NWu Fengguang <wfg@linux.intel.com>

The USB 2.0 Link PM code is conditionally compiled when
CONFIG_USB_SUSPEND=y.  I believe that's a mistake, since Link PM is not
directly related to USB device suspend and Link PM is implemented
without relying on any of the suspend code in the USB core.  For now,
keep the USB 2.0 Link PM code conditionally compiled if
CONFIG_USB_SUSPEND=y.

This patch does move the code to implement USB 3.0 Link PM out of the
xHCI driver #ifdefs for CONFIG_USB_SUSPEND and moves it into a section
dependent on CONFIG_PM.  The USB core functions for USB 3.0 Link PM are
already conditionally compiled when CONFIG_PM=y.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

When CONFIG_PM=n, make sure that the usb_[unlocked_][en/dis]able_lpm
declarations are visible in include/linux/usb.h, and exported from
drivers/usb/core/hub.c.

Before this patch, if CONFIG_USB_SUSPEND was turned off, it would cause
build errors:

drivers/usb/core/hub.c: In function 'usb_disable_lpm':
drivers/usb/core/hub.c:3394:2: error: implicit declaration of function 'usb_enable_lpm' [-Werror=implicit-function-declaration]
drivers/usb/core/hub.c: At top level:
drivers/usb/core/hub.c:3424:6: warning: conflicting types for 'usb_enable_lpm' [enabled by default]
drivers/usb/core/hub.c:3394:2: note: previous implicit declaration of 'usb_enable_lpm' was here
drivers/usb/core/driver.c: In function 'usb_probe_interface':
drivers/usb/core/driver.c:339:2: error: implicit declaration of function 'usb_unlocked_disable_lpm' [-Werror=implicit-function-declaration]
drivers/usb/core/driver.c:364:3: error: implicit declaration of function 'usb_unlocked_enable_lpm' [-Werror=implicit-function-declaration]
drivers/usb/core/message.c: In function 'usb_set_interface':
drivers/usb/core/message.c:1314:2: error: implicit declaration of function 'usb_disable_lpm' [-Werror=implicit-function-declaration]
drivers/usb/core/message.c:1323:3: error: implicit declaration of function 'usb_enable_lpm' [-Werror=implicit-function-declaration]
drivers/usb/core/message.c:1368:2: error: implicit declaration of function 'usb_unlocked_enable_lpm' [-Werror=implicit-function-declaration]
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Reported-by: NChen Peter-B29397 <B29397@freescale.com>

This reverts commit 1996e6c5.

It turned out to not be needed, now that the real fix has been
committed.
Reported-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The 3d9545cc(EHCI: maintain the
ehci->command value properly) introducs one command register
configuration lost problem by the below line in ehci_reset:

	ehci->command = ehci_readl(ehci, &ehci->regs->command);

After writting RESET into command register, it is restored to
its default value per EHCI spec[1], so the previous configuration
will be lost, and may introduce some problems reported recently:
	- imx51 Babbage board detect usb hub failed[2], reported
	by Richard Zhao.
	- mouse and keyboard hangs in linux-next found by
	Dan Carpenter and Greg-KH.

So this patch just removes the line to fix these problems, and
keep configurating command register consistent as before the commit
3d9545cc(EHCI: maintain the ehci->command value properly).

[1], 4.1 Host Controller Initialization of EHCI Specification 1.0
[2], failed dmesg log:
	usb 1-1: new high-speed USB device number 2 using mxc-ehci
	hub 1-1:1.0: USB hub found
	hub 1-1:1.0: 7 ports detected
	mxc-ehci mxc-ehci.1: fatal error
	mxc-ehci mxc-ehci.1: HC died; cleaning up
	mxc-ehci mxc-ehci.1: force halt; handshake f5780344 00004000 00004000 -> -110
	mxc-ehci mxc-ehci.1: HC died; cleaning up
	usb 1-1: USB disconnect, device number 2
Reported-by: NRichard Zhao <richard.zhao@freescale.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Reported-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Chen Peter-B29397 <B29397@freescale.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There exist races in devio.c, below is one case,
and there are similar races in destroy_async()
and proc_unlinkurb().  Remove these races.

 cancel_bulk_urbs()        async_completed()
-------------------                -----------------------
 spin_unlock(&ps->lock);

                           list_move_tail(&as->asynclist,
		                    &ps->async_completed);

                           wake_up(&ps->wait);

                           Lead to free_async() be triggered,
                           then urb and 'as' will be freed.

 usb_unlink_urb(as->urb);
 ===> refer to the freed 'as'
Signed-off-by: NHuajun Li <huajun.li.lee@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Oncaphillis <oncaphillis@snafu.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The update_device callback is not needed and the function used here is
from the pci ehci driver. Without this patch we get a compile error if
ehci-platform is compiled without ehci-pci.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Cc: stable <stable@vger.kernel.org> [3.4]
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Hub-initiated LPM is not good for USB communications devices.  Comms
devices should be able to tell when their link can go into a lower power
state, because they know when an incoming transmission is finished.
Ideally, these devices would slam their links into a lower power state,
using the device-initiated LPM, after finishing the last packet of their
data transfer.

If we enable the idle timeouts for the parent hubs to enable
hub-initiated LPM, we will get a lot of useless LPM packets on the bus
as the devices reject LPM transitions when they're in the middle of
receiving data.  Worse, some devices might blindly accept the
hub-initiated LPM and power down their radios while they're in the
middle of receiving a transmission.

The Intel Windows folks are disabling hub-initiated LPM for all USB
communications devices under a xHCI USB 3.0 host.  In order to keep
the Linux behavior as close as possible to Windows, we need to do the
same in Linux.

Set the disable_hub_initiated_lpm flag for for all USB communications
drivers.  I know there aren't currently any USB 3.0 devices that
implement these class specifications, but we should be ready if they do.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: Hansjoerg Lipp <hjlipp@web.de>
Cc: Tilman Schmidt <tilman@imap.cc>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: Peter Korsgaard <jacmet@sunsite.dk>
Cc: Jan Dumon <j.dumon@option.com>
Cc: Petko Manolov <petkan@users.sourceforge.net>
Cc: Steve Glendinning <steve.glendinning@smsc.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
Cc: Jouni Malinen <jouni@qca.qualcomm.com>
Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Cc: Christian Lamparter <chunkeey@googlemail.com>
Cc: Brett Rudley <brudley@broadcom.com>
Cc: Roland Vossen <rvossen@broadcom.com>
Cc: Arend van Spriel <arend@broadcom.com>
Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
Cc: Kan Yan <kanyan@broadcom.com>
Cc: Dan Williams <dcbw@redhat.com>
Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Cc: Ivo van Doorn <IvDoorn@gmail.com>
Cc: Gertjan van Wingerde <gwingerde@gmail.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: Herton Ronaldo Krzesinski <herton@canonical.com>
Cc: Hin-Tak Leung <htl10@users.sourceforge.net>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Chaoming Li <chaoming_li@realsil.com.cn>
Cc: Daniel Drake <dsd@gentoo.org>
Cc: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>