linux-stable.git/drivers/usb/dwc2, branch v4.6

usb: dwc2: do not override forced dr_mode in gadget setup

2016-04-04T12:18:48+00:00

The host/device mode set with dr_mode should be kept all the time,
not being changed to OTG in gadget setup (by overriding CFGUSB_FORCEDEVMODE
and CFGUSB_FORCEHOSTMODE bits).

Acked-by: John Youn 
Tested-by: John Youn 
Signed-off-by: Przemek Rudy 
Signed-off-by: Felipe Balbi

usb: dwc2: Fix issues in dwc2_complete_non_isoc_xfer_ddma()

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

Fixes a static analysis issue in dwc2_complete_non_isoc_xfer_ddma(). The
qtd was being passed to a function after being freed. It was not being
used in the function so this doesn't fix any bugs. But it fixes up the
warning and makes the code safer by setting qtd to NULL and not using it
at all.

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

usb: dwc2: Add support for Lantiq ARX and XRX SoCs

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

Add support for Lantiq ARX and XRX SoC families to the dwc2 driver.

Acked-by: John Youn 
Signed-off-by: Antti Seppälä 
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: Use kmem_cache_free()

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

Here, free memory is allocated using kmem_cache_zalloc.  So, use
kmem_cache_free instead of kfree.

This is done using Coccinelle and semantic patch used
is as follows:

//
@@
expression x,E,c;
@@
 x =
\(kmem_cache_alloc\|kmem_cache_zalloc\|kmem_cache_alloc_node\)(c,...)
 ... when != x = E
     when != &x
?-kfree(x)
+kmem_cache_free(c,x)
//

Acked-by: John Youn 
Signed-off-by: Amitoj Kaur Chawla 
Signed-off-by: Felipe Balbi

usb: dwc2: host: If using uframe scheduler, end splits better

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

The microframe scheduler figured out exactly how many transfers we need
for a split transaction.  Let's use this knowledge to know when to end
things.

Without this I found that certain devices would just keep responding
with tons of NYET resonses on their INT_IN endpoint.  These would just
keep going and going and eventually we'd decide to terminate the
transfer (because the whole frame changed), but by that time the
scheduler would decide that we "missed" the start of the next transfer.
I can also imagine that if we blow past the end of our scheduled time we
may mess up other things that were scheduled to happen.

No known test cases are improved by this patch except that the scheduler
code doesn't yell about MISSES constantly anymore.

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: Totally redo the microframe scheduler

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

This totally reimplements the microframe scheduler in dwc2 to attempt to
handle periodic splits properly.  The old code didn't even try, so this
was a significant effort since periodic splits are one of the most
complicated things in USB.

I've attempted to keep the old "don't use the microframe" schduler
around for now, but not sure it's needed.  It has also only been lightly
tested.

I think it's pretty certain that this scheduler isn't perfect and might
have some bugs, but it seems much better than what was there before.
With this change my stressful USB test (USB webcam + USB audio + some
keyboards) crackles less.

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 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: Add dwc2_hcd_get_future_frame_number() call

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

As we start getting more exact about our scheduling it's becoming more
and more important to know exactly how far through the current frame we
are.  This lets us make decisions about whether there's still time left
to start a new transaction in the current frame.

We'll add dwc2_hcd_get_future_frame_number() which will tell you what
the frame number will be a certain number of microseconds (us) from
now.  We can use this information to help decide if there's enough time
left in the frame for a transaction that will take a certain duration.

This is expected to be used by a future change ("usb: dwc2: host:
Properly set even/odd frame").

Acked-by: John Youn 
Signed-off-by: Douglas Anderson 
Tested-by: Heiko Stuebner 
Tested-by: Stefan Wahren 
Signed-off-by: Felipe Balbi