Hi,
Am Freitag, 22. Januar 2016, 10:18:35 schrieb Douglas Anderson:
> This is a bit of catchall series for all the bug fix and performance
> patches I've been working on over the last few months. Note that for
> dwc2 we need to do LOTS in software and need super low interrupt
> latency, so most performance improvements actually fix real bugs.
>
> Patches are structured to start with no-brainer stuff that could be
> applied ASAP, especially things I've already gotten Acks for. Things
> get slightly more RFC / RFT like as we get farther down the series.
> Anything that can be landed sooner rather than later (especially those
> Acked long ago) would help in re-posts (I'm not biased, of course).
>
> It's been a few months since my last post of this series. In the
> meantime I've added a bunch of small bugfixes to the start of it and
> also TOTALLY REWROTE the microframe scheduler. I'll say up front: I
> know nothing about USB. I haven't read the whole spec. I'm not
> terribly familiar with the OHCI, EHCI, and XHCI drivers in the kernel.
> ...and I'm pretty clueless overall. Nevertheless, I've attempted to
> write up a fancy scheduler based on the portion of the spec talking
> about microframe scheduling requirements. This rewritten scheduler does
> seem to help when I start jamming lots of USB things into a hub, so
> presumably the code is a reasonably starting point. Given my current
> understanding of USB the old code was fairly insane, so presumably even
> if my new patch isn't perfect it's better than what we had.
I've tested this series (+the low-speed fix from today) on the following
usb-tree on a rk3288-veyron-jerry:
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Video, Driver=, 480M
|__ Port 1: Dev 2, If 1, Class=Video, Driver=, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=zd1211rw, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
|__ Port 3: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 6, If 0, Class=Vendor Specific Class, Driver=, 12M
|__ Port 3: Dev 8, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 10, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 1: Dev 10, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 2: Dev 11, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 2: Dev 11, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 3: Dev 12, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 4: Dev 13, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 4: Dev 9, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 4: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 5: Dev 7, If 0, Class=Mass Storage, Driver=usb-storage, 480M
At first we were maxing out the 9 channels of the otg port, which the
driver didn't seem to care about in 4.4-rc6, but after realizing that and
switching over to the 16ch host-port it ran really nicely, especially wrt
faster handling of all the keyboard input.
When looking over to the other desk and the person using that veyron-
jerry not cursing anymore, it seem to be running fine in a real-world use
for 2 hours now ;-)
So,
Tested-by: Heiko Stuebner <heiko at sntech.de>
> The patches here will speed up the interrupt controller significantly.
> After this series, I have a hard time seeing the interrupt controller
> taking > 20 us and I don't ever see it taking > 30 us ever in my tests
> unless I bring the cpufreq back down. With the cpufreq at 126 MHz I can
> still see the interrupt handler take > 50 us, so I'm sure we could
> improve this further. ...but hey, it's a start.
In the configuration described above, we were still able to run the
interrupt handlers capabilities when the cpufreq is at 126MHz, but
once set to a sane minimum it is running really nice now.
Heiko
