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>

All Intel xHCI host controllers support USB 3.0 Link Power Management.

The Panther Point xHCI host controller needs the xHCI driver to
calculate the U1 and U2 timeout values, because it will blindly accept a
MEL that would cause scheduling issues.

The Lynx Point xHCI host controller will reject MEL values that are too
high, but internally it implements the same algorithm that is needed for
Panther Point xHCI.

Simplify the code paths by just having the xHCI driver calculate what
the U1/U2 timeouts should be.  Comments on the policy are in the code.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The choice of U1 and U2 timeouts for USB 3.0 Link Power Management (LPM)
is highly host controller specific.  Here are a few examples of why it's
host specific:

 1. Setting the U1/U2 timeout too short may cause the link to go into
    U1/U2 in between service intervals, which some hosts may tolerate,
    and some may not.

 2. The host controller has to modify its bus schedule in order to take
    into account the Maximum Exit Latency (MEL) to bring all the links
    from the host to the device into U0.  If the MEL is too big, and it
    takes too long to bring the links into an active state, the host
    controller may not be able to service periodic endpoints in time.

 3. Host controllers may also have scheduling limitations that force
    them to disable U1 or U2 if a USB device is behind too many tiers of
    hubs.

We could take an educated guess at what U1/U2 timeouts may work for a
particular host controller.  However, that would result in a binary
search on every new configuration or alt setting installation, with
multiple failed Evaluate Context commands.  Worse, the host may blindly
accept the timeouts and just fail to update its schedule for U1/U2 exit
latencies, which could result in randomly delayed periodic transfers.

Since we don't want to cause jitter in periodic transfers, or delay
config/alt setting changes too much, lay down a framework that xHCI
vendors can extend in order to add their own U1/U2 timeout policies.

To extend the framework, they will need to:

 - Modify the PCI init code to add a new xhci->quirk for their host, and
   set the XHCI_LPM_SUPPORT quirk flag.
 - Add their own vendor-specific hooks, like the ones that will be added
   in xhci_call_host_update_timeout_for_endpoint() and
   xhci_check_tier_policy()
 - Make the LPM enable/disable methods call those functions based on the
   xhci->quirk for their host.

An example will be provided for the Intel xHCI host controller in the
next patch.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

We want to do everything we can to ensure that USB 3.0 Link Power
Management (LPM) can be disabled when it is enabled.  If LPM can't be
disabled, we can't suspend USB 3.0 devices, or reset them.  To make sure
we can submit the command to disable LPM, allocate a command in the
xhci_hcd structure, and reserve one TRB on the command ring.

We only need one command per xHCI driver instance, because LPM is only
disabled or enabled while the USB core is holding the bandwidth_mutex
that is shared between the xHCI USB 2.0 and USB 3.0 roothubs.  The
bandwidth_mutex will be held until the command completes, or times out.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The upcoming USB 3.0 Link PM patches will introduce new API to enable
and disable low-power link states.  We must be able to disable LPM in
order to reset a device, or place the device into U3 (device suspend).
Therefore, we need to make sure the Evaluate Context command to disable
the LPM timeouts can't fail due to there being no room on the command
ring.

Introduce a new flag to the function that queues the Evaluate Context
command, command_must_succeed.  This tells the ring handler that a TRB
has already been reserved for the command (by incrementing
xhci->cmd_ring_reserved_trbs), and basically ensures that prepare_ring()
won't fail.  A similar flag was already implemented for the Configure
Endpoint command queuing function.

All functions that currently call xhci_configure_endpoint() to issue an
Evaluate Context command pass "false" for the "must_succeed" parameter,
so this patch should have no effect on current xHCI driver behavior.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

There are several places where the USB core needs to disable USB 3.0
Link PM:
 - usb_bind_interface
 - usb_unbind_interface
 - usb_driver_claim_interface
 - usb_port_suspend/usb_port_resume
 - usb_reset_and_verify_device
 - usb_set_interface
 - usb_reset_configuration
 - usb_set_configuration

Use the new LPM disable/enable functions to temporarily disable LPM
around these critical sections.

We need to protect the critical section around binding and unbinding USB
interface drivers.  USB drivers may want to disable hub-initiated USB
3.0 LPM, which will change the value of the U1/U2 timeouts that the xHCI
driver will install.  We need to disable LPM completely until the driver
is bound to the interface, and the driver has a chance to enable
whatever alternate interface setting it needs in its probe routine.
Then re-enable USB3 LPM, and recalculate the U1/U2 timeout values.

We also need to disable LPM in usb_driver_claim_interface,
because drivers like usbfs can bind to an interface through that
function.  Note, there is no way currently for userspace drivers to
disable hub-initiated USB 3.0 LPM.  Revisit this later.

When a driver is unbound, the U1/U2 timeouts may change because we are
unbinding the last driver that needed hub-initiated USB 3.0 LPM to be
disabled.

USB LPM must be disabled when a USB device is going to be suspended.
The USB 3.0 spec does not define a state transition from U1 or U2 into
U3, so we need to bring the device into U0 by disabling LPM before we
can place it into U3.  Therefore, call usb_unlocked_disable_lpm() in
usb_port_suspend(), and call usb_unlocked_enable_lpm() in
usb_port_resume().  If the port suspend fails, make sure to re-enable
LPM by calling usb_unlocked_enable_lpm(), since usb_port_resume() will
not be called on a failed port suspend.

USB 3.0 devices lose their USB 3.0 LPM settings (including whether USB
device-initiated LPM is enabled) across device suspend.  Therefore,
disable LPM before the device will be reset in
usb_reset_and_verify_device(), and re-enable LPM after the reset is
complete and the configuration/alt settings are re-installed.

The calculated U1/U2 timeout values are heavily dependent on what USB
device endpoints are currently enabled.  When any of the enabled
endpoints on the device might change, due to a new configuration, or new
alternate interface setting, we need to first disable USB 3.0 LPM, add
or delete endpoints from the xHCI schedule, install the new interfaces
and alt settings, and then re-enable LPM.  Do this in usb_set_interface,
usb_reset_configuration, and usb_set_configuration.

Basically, there is a call to disable and then enable LPM in all
functions that lock the bandwidth_mutex.  One exception is
usb_disable_device, because the device is disconnecting or otherwise
going away, and we should not care about whether USB 3.0 LPM is enabled.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>