linux-toradex.git/drivers/usb/dwc2/core.c, branch v4.10

usb: dwc2: Declare the core params struct statically

2016-11-18T11:54:11+00:00

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: John Youn 
Signed-off-by: Felipe Balbi

usb: dwc2: Add params.c file

2016-11-18T11:54:10+00:00

Add a params.c file and move all driver parameter code there, including
all the static parameter definitions.

Signed-off-by: John Youn 
Signed-off-by: Felipe Balbi

usb: dwc2: Add msleep for host-only

2016-10-17T09:30:29+00:00

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: John Youn 
Signed-off-by: Heiko Stuebner 
Signed-off-by: Felipe Balbi

usb: dwc2: Properly account for the force mode delays

2016-09-08T11:02:54+00:00

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: Stefan Wahren 
Signed-off-by: John Youn 
Signed-off-by: Felipe Balbi

usb: dwc2: Add delay to core soft reset

2016-09-08T11:02:52+00:00

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: Stefan Wahren 
Signed-off-by: John Youn 
Signed-off-by: Felipe Balbi

usb: dwc2: Move host-specific core functions into hcd.c

2016-03-04T13:14:46+00:00

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: Douglas Anderson 
Reviewed-by: Douglas Anderson 
Signed-off-by: John Youn 
Signed-off-by: Felipe Balbi

usb: dwc2: Move register save and restore functions

2016-03-04T13:14:46+00:00

Move the register save and restore functions into the host and gadget
specific files.

Tested-by: Douglas Anderson 
Reviewed-by: Douglas Anderson 
Signed-off-by: John Youn 
Signed-off-by: Felipe Balbi

usb: dwc2: host: Properly set even/odd frame

2016-03-04T13:14:44+00:00

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: John Youn 
Signed-off-by: Douglas Anderson 
Tested-by: Heiko Stuebner 
Tested-by: Stefan Wahren 
Signed-off-by: Felipe Balbi

usb: dwc2: host: Properly set the HFIR

2016-03-04T13:14:42+00:00

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: John Youn 
Signed-off-by: Douglas Anderson 
Tested-by: Heiko Stuebner 
Signed-off-by: Felipe Balbi

usb: dwc2: host: fix split transfer schedule sequence

2016-03-04T13:14:40+00:00

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: John Youn 
Signed-off-by: Douglas Anderson 
Signed-off-by: Yunzhi Li 
Reviewed-by: Kever Yang 
Tested-by: Heiko Stuebner 
Tested-by: Kever Yang 
Tested-by: Stefan Wahren 
Signed-off-by: Felipe Balbi