ulseep_range() uses hrtimers and provides no advantage over msleep()
for larger delays. Fix up the 100ms delays here passing the adjusted "min"
value to msleep(). This helps reduce the load on the hrtimer subsystem.

Link: http://lkml.org/lkml/2017/1/11/377
Fixes: commit 2938fc63 ("usb: dwc2: Properly account for the force mode delays")
Signed-off-by: NNicholas Mc Guire <hofrat@osadl.org>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Basically when plugging in various cables in different orders, I'm
occasionally seeing the following BUG splat:

[   86.215403] BUG: scheduling while atomic: kworker/u16:2/53/0x00000002
[   86.219164] usb 1-1: USB disconnect, device number 9
[   86.226845] Preemption disabled at:[   86.230218]
[<ffffff8008673558>] dwc2_conn_id_status_change+0x120/0x250
[   86.236894] CPU: 0 PID: 53 Comm: kworker/u16:2 Tainted: G        W
     4.9.0-rc8-00051-gd5a7979-dirty #1702
[   86.246836] Hardware name: HiKey Development Board (DT)
[   86.252100] Workqueue: dwc2 dwc2_conn_id_status_change
[   86.257279] Call trace:
[   86.259771] [<ffffff8008087c28>] dump_backtrace+0x0/0x1a0
[   86.265210] [<ffffff8008087ddc>] show_stack+0x14/0x20
[   86.270308] [<ffffff80084343f0>] dump_stack+0x90/0xb0
[   86.275401] [<ffffff80080d8d94>] __schedule_bug+0x6c/0xb8
[   86.280841] [<ffffff8008a07220>] __schedule+0x4f8/0x5b0
[   86.286099] [<ffffff8008a073e8>] schedule+0x38/0xa0
[   86.291017] [<ffffff8008a0a6cc>] schedule_hrtimeout_range_clock+0x8c/0xf0
[   86.297846] [<ffffff8008a0a740>] schedule_hrtimeout_range+0x10/0x18
[   86.304150] [<ffffff8008a0a4a0>] usleep_range+0x50/0x58
[   86.309418] [<ffffff800866d8dc>] dwc2_wait_for_mode.isra.4+0x54/0xd0
[   86.315815] [<ffffff800866f058>] dwc2_core_reset+0xe0/0x168
[   86.321431] [<ffffff800867e364>] dwc2_hsotg_core_init_disconnected+0x2c/0x310
[   86.328602] [<ffffff8008673568>] dwc2_conn_id_status_change+0x130/0x250
[   86.335254] [<ffffff80080ccd48>] process_one_work+0x118/0x370
[   86.341035] [<ffffff80080ccfe8>] worker_thread+0x48/0x498
[   86.346473] [<ffffff80080d2eb0>] kthread+0xd0/0xe8
[   86.351299] [<ffffff8008082e80>] ret_from_fork+0x10/0x50

This seems to be caused by the dwc2_wait_for_mode() calling
usleep_range() while the hstog->lock spinlock is held, since
we take that before calling dwc2_hsotg_core_init_disconnected().

This patch avoids the issue by adding an extra argument to
dwc2_core_reset(), as suggested by John Youn, which allows us to
skip the waiting, which should be unnecessary when calling from
dwc2_hsotg_core_init_disconnected().

Cc: Wei Xu <xuwei5@hisilicon.com>
Cc: Guodong Xu <guodong.xu@linaro.org>
Cc: Amit Pundir <amit.pundir@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: John Youn <johnyoun@synopsys.com>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Chen Yu <chenyu56@huawei.com>
Cc: Vardan Mikayelyan <mvardan@synopsys.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Check these parameters only for true or false. There is no need to check
for greater or less than 0.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The otg_ver parameter only controls the SRP pulsing method and defaults
to the 1.3 behavior. It is unused and can be removed.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This commmit is the result of running checkpatch --fix.

The results were verified for correctness. Some of the fixes result in
line over 80 char which we will fix manually later.

The following is a summary of what was done by checkpatch:
* Remove externs on function prototypes.
* Replace symbolic permissions with octal.
* Align code to open parens.
* Replace 'unsigned' with 'unsigned int'.
* Remove unneccessary blank lines.
* Add blank lines after declarations.
* Add spaces around operators.
* Remove unnecessary spaces after casts.
* Replace 'x == NULL' with '!x'.
* Replace kzalloc() with kcalloc().
* Concatenate multi-line strings.
* Use the BIT() macro.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This makes it consistent with the hw_params struct and simplifies the
memory management for future refactoring. Fix up usage in all files.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Add a params.c file and move all driver parameter code there, including
all the static parameter definitions.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Although a host-only controller should not have any associated delay,
some rockchip SOC platforms will not show the correct host-values of
registers until after a delay.

So add a 50 ms sleep when in host-only mode.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

When a force mode bit is set and the IDDIG debounce filter is enabled,
there is a delay for the forced mode to take effect. This delay is due
to the IDDIG debounce filter and is variable depending on the platform's
PHY clock speed. To account for this delay we can poll for the expected
mode.

On a clear force mode, since we don't know what mode to poll for, delay
for a fixed 100 ms. This is the maximum delay based on the slowest PHY
clock speed.
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Add a delay to the core soft reset function to account for the IDDIG
debounce filter.

If the current mode is host, either due to the force mode bit being
set (which persists after core reset) or the connector id pin, a core
soft reset will temporarily reset the mode to device and a delay from
the IDDIG debounce filter will occur before going back to host mode.
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Move host core initialization and host channel routines into hcd.c. This
allows these functions to only be compiled in host-enabled driver
configurations (DRD or host-only).
Tested-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

Move the register save and restore functions into the host and gadget
specific files.
Tested-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

When setting up ISO and INT transfers dwc2 needs to specify whether the
transfer is for an even or an odd frame (or microframe if the controller
is running in high speed mode).

The controller appears to use this as a simple way to figure out if a
transfer should happen right away (in the current microframe) or should
happen at the start of the next microframe.  Said another way:

- If you set "odd" and the current frame number is odd it appears that
  the controller will try to transfer right away.  Same thing if you set
  "even" and the current frame number is even.
- If the oddness you set and the oddness of the frame number are
  _different_, the transfer will be delayed until the frame number
  changes.

As I understand it, the above technique allows you to plan ahead of time
where possible by always working on the next frame.  ...but it still
allows you to properly respond immediately to things that happened in
the previous frame.

The old dwc2_hc_set_even_odd_frame() didn't really handle this concept.
It always looked at the frame number and setup the transfer to happen in
the next frame.  In some cases that meant that certain transactions
would be transferred in the wrong frame.

We'll try our best to set the even / odd to do the transfer in the
scheduled frame.  If that fails then we'll do an ugly "schedule ASAP".
We'll also modify the scheduler code to handle this and not try to
schedule a second transfer for the same frame.

Note that this change relies on the work to redo the microframe
scheduler.  It can work atop ("usb: dwc2: host: Manage frame nums better
in scheduler") but it works even better after ("usb: dwc2: host: Totally
redo the microframe scheduler").

With this change my stressful USB test (USB webcam + USB audio +
keyboards) has less audio crackling than before.
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

According to the most up to date version of the dwc2 databook, the FRINT
field of the HFIR register should be programmed to:
* 125 us * (PHY clock freq for HS) - 1
* 1000 us * (PHY clock freq for FS/LS) - 1

This is opposed to older versions of the doc that claimed it should be:
* 125 us * (PHY clock freq for HS)
* 1000 us * (PHY clock freq for FS/LS)

In case you didn't spot it, the difference is the "- 1".

Let's add the "- 1" to match the newest user manual.  It's presumed that
the "- 1" should have always been there and that this was always a
documentation error.  If some hardware needs the "- 1" and other
hardware doesn't, we'll have to add a configuration parameter for it in
the future.

I checked things before and after this patch on rk3288 using a Total
Phase Beagle 5000 analyzer.

Before this patch, a low speed mouse shows constant Frame Timing Jitter
errors.  After this patch errors have gone away.

Before this patch SOF packets move forward about 1 us per 4 ms.  After
this patch the SOF packets move backward about 1 us per 255 ms.  Some
specific SOF timestamps from the analyzer are below.

Before:
  6.603.790
  6.603.916
  6.604.041
  6.604.166
  ...
  6.607.541
  6.607.667
  6.607.792
  6.607.917
  ...
  6.611.417
  6.611.543
  6.611.668
  6.611.793

After:
  6.215.159
  6.215.284
  6.215.408
  6.215.533
  6.215.658
  ...
  6.470.658
  6.470.783
  6.470.907
  ...
  6.726.032
  6.726.157
  6.725.281
  6.725.406
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

We're supposed to keep outstanding splits in order.  Keep track of a
list of the order of splits and process channel interrupts in that
order.

Without this change and the following setup:
* Rockchip rk3288 Chromebook, using port ff540000
  -> Pluggable 7-port Hub with Charging (powered)
     -> Microsoft Wireless Keyboard 2000 in port 1.
     -> Das Keyboard in port 2.

...I find that I get dropped keys on the Microsoft keyboard (I'm sure
there are other combinations that fail, but this documents my test).
Specifically I've been typing "hahahahahahaha" on the keyboard and often
see keys dropped or repeated.

After this change the above setup works properly.  This patch is based
on a previous patch proposed by Yunzhi Li ("usb: dwc2: hcd: fix periodic
transfer schedule sequence")
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NYunzhi Li <lyz@rock-chips.com>
Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NKever Yang <kever.yang@rock-chips.com>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

All other host controllers who want aligned buffers for DMA do it a
certain way.  Let's do that too instead of working behind the USB core's
back.  This makes our interrupt handler not take forever and also rips
out a lot of code, simplifying things a bunch.

This also has the side effect of removing the 65535 max transfer size
limit.

NOTE: The actual code to allocate the aligned buffers is ripped almost
completely from the tegra EHCI driver.  At some point in the future we
may want to add this functionality to the USB core to share more code
everywhere.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NJohn Youn <johnyoun@synopsys.com>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

Fixes an issue found on rockchip rk3036 and rk3188 SOC platforms. For
some reason, the existing msleep(25) is not enough after the force mode.
The following patch was reported to fix the issue.

This does increase the probe delay again slightly, but not up to the
level it was before the original series of patches that this fixes. It
does not cause any other issues when tested on Synopsys HAPS and Altera
socfpga platforms.

Need to revisit this series next release to see if we can address these
issues without having an unconditional delay.

Fixes: 09c96980 ("usb: dwc2: Add functions to set and clear force mode")
Reported-by: NCaesar Wang <caesar.upstream@gmail.com>
Reported-by: NMichael Niewoehner <linux@mniewoehner.de>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NCaesar Wang <caesar.upstream@gmail.com>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

Fixes an issue found on Raspberry PI platform that prevents probe. Don't
skip setting the force mode if it's already set.

Fixes: 09c96980 ("usb: dwc2: Add functions to set and clear force mode")
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Reported-by: NStefan Wahren <stefan.wahren@i2se.com>
Reported-by: NRemi Pommarel <repk@triplefau.lt>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Tested-by: NRemi Pommarel <repk@triplefau.lt>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

This reverts commit 263b7fb5 ("usb: dwc2: Move reset into
dwc2_get_hwparams()") due to regression found on bcm2835 platform. USB
ethernet fails, due to being unable to pick up proper parameters when
performing a plain reset before reading hw params.

Below shows the results of the gnptxfsiz and hptxfsiz with and before
and after reverting this (from Stefan Wahren):

So here is the probe result before Patch 1 is applied:

[    1.283148] dwc2 20980000.usb: Configuration mismatch. dr_mode forced to host
[    1.313894] dwc2 20980000.usb: gnptxfsiz=00201000
[    1.314104] dwc2 20980000.usb: hptxfsiz=00000000
[    1.353908] dwc2 20980000.usb: 256 invalid for host_nperio_tx_fifo_size. Check HW configuration.
[    1.354262] dwc2 20980000.usb: 512 invalid for host_perio_tx_fifo_size. Check HW configuration.
[    1.394249] dwc2 20980000.usb: DWC OTG Controller
[    1.394561] dwc2 20980000.usb: new USB bus registered, assigned bus number 1
[    1.394917] dwc2 20980000.usb: irq 33, io mem 0x00000000

And here is the probe result after Patch 1 is applied:

[    1.280107] dwc2 20980000.usb: Configuration mismatch. dr_mode forced to host
[    1.353949] dwc2 20980000.usb: gnptxfsiz=01001000
[    1.354166] dwc2 20980000.usb: hptxfsiz=02002000
[    1.434301] dwc2 20980000.usb: DWC OTG Controller
[    1.434616] dwc2 20980000.usb: new USB bus registered, assigned bus number 1
[    1.434973] dwc2 20980000.usb: irq 33, io mem 0x00000000
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Reported-by: NStefan Wahren <stefan.wahren@i2se.com>
Reported-by: NRemi Pommarel <repk@triplefau.lt>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Tested-by: NRemi Pommarel <repk@triplefau.lt>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

The delay for force mode is only 25ms according to the databook.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Adds separate functions to get the host and device specific hardware
parameters. The functions check whether the parameters need to be read
at all, depending on dr_mode, and forces the mode only if necessary.
This saves some delays during probe. This also adds two device mode
parameters that will be used by the gadget.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Added functions to set force mode for host and device. These functions
will check the current mode and only force if needed thus avoiding
unnecessary force mode delays. However clearing the mode is currently
done unconditionally and with the delay in place. This is needed during
the connector ID status change interrupt in order to ensure that the
mode has changed properly. This preserves the old behavior only for this
case. The warning comment about this is moved into the clear mode
condition.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The reset is required to get reset values of the hardware parameters but
the force mode is not. Move the base reset into dwc2_get_hwparams() and
do the reset and force mode afterwards.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Added functions to query the GHWCFG2.OTG_MODE. This tells us whether the
controller hardware is configured for OTG, device-only, or host-only.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

dwc2_core_reset() was previously renamed to
dwc2_core_reset_and_dr_force_mode(). Now add back dwc2_core_reset() which
performs only a basic core reset without forcing the mode.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Renamed dwc2_core_reset() to dwc2_core_reset_and_force_dr_mode(). This
describes what it is doing more accurately. This is in preparation of
introducing a plain dwc2_core_reset() function that only performs the
reset and doesn't force the mode.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

According to the databook, the core soft reset should be done before
checking for AHBIDLE. The gadget version of core reset had it correct
but the hcd version did not. This fixes the hcd version.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Calls to dwc2_core_reset() are currently very slow, taking at least
150ms (possibly more).  It behooves us to take as many of these calls
out as possible.

It turns out that the calls in dwc2_fs_phy_init() and dwc2_hs_phy_init()
should (as documented in the code) only be needed if we need to do a PHY
SELECT.  That means that if we see that we can avoid the PHY SELECT then
we can avoid the reset.

This patch appears to successfully bypass two resets (one per USB
device) on rk3288-based ARM Chromebooks.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

I found that the probe function of dwc2 driver takes much time
when kernel boot up. There are many long delays in the probe
function these take almost 1 second.

This patch trying to reduce unnecessary delay time.

In dwc2_core_reset() I see it use two at least 20ms delays to
wait AHB idle and core soft reset, but dwc2 data book said that
dwc2 core soft reset and AHB idle just need a few clocks (I think
it refers to AHB clock, and AHB clock run at 150MHz in my RK3288
board), so 20ms is too long, delay 1us for wait AHB idle and soft
reset is enough.

And in dwc2_get_hwparams() it takes 150ms to wait ForceHostMode
and ForceDeviceMode valid but in data book it said software must
wait at least 25ms before the change to take effect, so I reduce
this time to 25ms~50ms. By the way, is there any state bit show
that the force mode take effect ? Could we poll curmod bit for
figuring out if the change take effect ?

It seems that usleep_range() at boot time will pick the longest
value in the range. In dwc2_core_reset() there is a very long
delay takes 200ms, and this function run twice when probe, could
any one tell me is this delay time resonable ?

I have tried this patch in my RK3288-evb board. It works well.
Signed-off-by: NYunzhi Li <lyz@rock-chips.com>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

On some host-only DWC2 ports (like the one in rk3288) when we set
GUSBCFG_FORCEHOSTMODE in GUSBCFG and then read back, we don't see the
bit set.  Presumably that's because the port is always forced to HOST
mode so there's no reason to implement these status bits.

Since we know dwc2_core_reset() is always called before
dwc2_get_hwparams() and we know dwc2_core_reset() should have set
GUSBCFG_FORCEHOSTMODE whenever hsotg->dr_mode == USB_DR_MODE_HOST, we
can just check hsotg->dr_mode to decide that we can skip the delays in
dwc2_get_hwparams().
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In (usb: dwc2: reset dwc2 core before dwc2_get_hwparams()) we added an
extra reset to the probe path for the dwc2 USB controllers.  This
allowed proper detection of parameters even if the firmware had already
used the USB part.

Unfortunately, this extra reset is quite slow and is affecting boot
speed.  We can avoid the double-reset by skipping the extra reset that
would happen just after the one we added.  Logic that explains why this
is safe:

* As of the CL mentioned above, we now always call dwc2_core_reset() in
  dwc2_driver_probe() before dwc2_hcd_init().

* The only caller of dwc2_hcd_init() is dwc2_driver_probe(), so we're
  guaranteed that dwc2_core_reset() was called before dwc2_hdc_init().

* dwc2_hdc_init() is the only caller that passes an irq other than -1 to
  dwc2_core_init().  Thus if dwc2_core_init() is called with an irq
  other than -1 we're guaranteed that dwc2_core_reset was called before
  dwc2_core_init().

...this allows us to remove the dwc2_core_reset() in dwc2_core_init() if
irq is not < 0.

Note that since "irq" wasn't used in the function dwc2_core_init()
anyway and since select_phy was always set at exactly the same times we
could avoid the reset, we remove "irq" and rename "select_phy" to
"initial_setup" and adjust the callers accordingly.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We initiate dwc2 usb controller in BIOS, dwc2_core_reset() should
be called before dwc2_get_hwparams() to reset core registers to
default value. Without this the FIFO setting might be incorrect
because calculating FIFO size need power-on value of
GRXFSIZ/GNPTXFSIZ/HPTXFSIZ registers.

This patch could avoid warnning massage like in rk3288 platform:
[    2.074764] dwc2 ff580000.usb: 256 invalid for
host_perio_tx_fifo_size. Check HW configuration.
Signed-off-by: NYunzhi Li <lyz@rock-chips.com>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Previously dwc2_get_hwparams() was changing GUSBCFG and not putting it
back the way it was (specifically it set and cleared FORCEHOSTMODE).
Since we want to move dwc2_core_reset() _before_ dwc2_get_hwparams() we
should make sure dwc2_get_hwparams() isn't messing with things in a
permanent way.

Since we're now looking at GUSBCFG, it's obvious that we shouldn't need
all the extra delays if FORCEHOSTMODE was already set.  This will avoid
some delays for any ports that have forced host mode.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In some cases, like when you've got a "Microsoft Wireless Keyboard 2000"
connected to dwc2 with a hub, expected that we'll get some transfer
errors sometimes.  The controller is expected to try at least 3 times
before giving up.  See figure "Figure A-67. Normal HS CSPLIT 3 Strikes
Smash" in the USB spec.

The dwc2 controller has a way to support this by using the "EC_MC"
field.  The Raspberry Pi driver has logic for setting this right.  See
fiq_fsm_queue_split_transaction() in their "dwc_otg_hcd.c".  Let's use
the same logic.

After making this change, we no longer get dropped characters from the
above mentioned keyboard.  Other devices on the same bus as the keyboard
also behave more properly.

Thanks for Julius Werner for the expert analysis and suggestions.
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Masks for HCDMA.CTD and HCDMA.DMAAddr are incorrect. As we always
start from first descriptor, no need to mask the address anyway.
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Signed-off-by: NGregory Herrero <gregory.herrero@intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Use Streaming DMA mappings to handle cache coherency of frame list and
descriptor list. Cache are always flushed before controller access it
or before cpu access it.
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NGregory Herrero <gregory.herrero@intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

As descriptor dma mode does not support split transfers, it can't be
enabled for high speed devices. Add a core parameter to enable it for
full speed devices.

Ensure frame list and descriptor list are correctly freed during
disconnect.
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Signed-off-by: NGregory Herrero <gregory.herrero@intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Fix a duplicate argument warning reported by 0-DAY kernel test
infrastructure in the following patch:
77dbf713 usb: dwc2: host: add disconnect interrupt to host only interrupts
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

If an interrupt rises during hibernation process, dwc2 will assert
interrupt line to interrupt controller. If interrupt is level
sensitive, interrupt handler will be called in a loop because dwc2
will not be able to clear it while controller is hibernated.
Thus, clear all controller interrupts before hibernation entry.
Signed-off-by: NGregory Herrero <gregory.herrero@intel.com>
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Tested-by: NRobert Baldyga <r.baldyga@samsung.com>
Tested-by: NDinh Nguyen <dinguyen@opensource.altera.com>
Tested-by: NJohn Youn <johnyoun@synopsys.com>
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

GINTSTS.DisconnInt is host only interrupt and should be disable after
dwc2_disable_host_interrupts is called.
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Tested-by: NRobert Baldyga <r.baldyga@samsung.com>
Tested-by: NDinh Nguyen <dinguyen@opensource.altera.com>
Tested-by: NJohn Youn <johnyoun@synopsys.com>
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>