kernel.git/drivers/usb/dwc2/core.c, branch linux-4.8.y

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

2016-03-04T13:14:46Z

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:46Z

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:44Z

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:42Z

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:40Z

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

usb: dwc2: host: Get aligned DMA in a more supported way

2016-03-04T13:14:39Z

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

usb: dwc2: Add extra delay when forcing dr_mode

2016-02-17T08:31:42Z

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: 09c96980dc72 ("usb: dwc2: Add functions to set and clear force mode") Reported-by: Caesar Wang Reported-by: Michael Niewoehner Tested-by: Heiko Stuebner Tested-by: Caesar Wang Signed-off-by: John Youn Signed-off-by: Felipe Balbi

usb: dwc2: Fix probe problem on bcm2835

2016-02-03T18:15:49Z

Fixes an issue found on Raspberry PI platform that prevents probe. Don't skip setting the force mode if it's already set. Fixes: 09c96980dc72 ("usb: dwc2: Add functions to set and clear force mode") Tested-by: Heiko Stuebner Tested-by: Douglas Anderson Signed-off-by: John Youn Reported-by: Stefan Wahren Reported-by: Remi Pommarel Tested-by: Stefan Wahren Tested-by: Remi Pommarel Signed-off-by: Felipe Balbi

Revert "usb: dwc2: Move reset into dwc2_get_hwparams()"

2016-02-03T18:15:19Z

This reverts commit 263b7fb557f7 ("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: Heiko Stuebner Tested-by: Douglas Anderson Signed-off-by: John Youn Reported-by: Stefan Wahren Reported-by: Remi Pommarel Tested-by: Stefan Wahren Tested-by: Remi Pommarel Signed-off-by: Felipe Balbi

usb: dwc2: Reduce delay when forcing mode in reset

2015-12-22T18:01:32Z

The delay for force mode is only 25ms according to the databook. Signed-off-by: John Youn Signed-off-by: Felipe Balbi