Re: [PATCH v5 0/21] usb: dwc2: host: Fix and speed up all the stuff, especially with splits

[Doug Anderson]

Hi,

On Sat, Jan 23, 2016 at 3:09 PM, Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
> Heiko,
>
> On Sat, Jan 23, 2016 at 9:52 AM, Heiko Stuebner <heiko@xxxxxxxxx> wrote:
>> 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.
>
> Actually, I should probably fix this in the patch ("usb: dwc2: host:
> Totally redo the microframe scheduler").  While trying to make things
> work originally I had moved the "dwc2_periodic_channel_available()" to
> always happen even with the microframe scheduler, but I don't think
> there's any strong reason for that.  I think we could just undo it and
> everything would work just as well or better.
>
> I'll try to do some testing with that fix next week and then try to
> send up a spun series.  Note that the reason why ("usb: dwc2: host:
> Totally redo the microframe scheduler") was near the end of the series
> was that I'd expected that things earlier than it were in a pretty
> good shape to land while I was expecting that the microframe rewrite
> might need a spin or two.

I can't do more than cursory testing without being at work and able to
plug / unplug peripherals, but I'd expect that this should fix the
problem:

https://chromium-review.googlesource.com/#/c/323326/

I won't plan on spinning the series with that patch until at least a
week has passed.  I believe that John is out right now and I don't
want to spam a 21-part series too many times.

-Doug