High CPU load produced by USB (DW2)

[Minas Harutyunyan]

On 2/19/2018 9:03 PM, Marek Vasut wrote:
> On 02/19/2018 11:11 AM, Minas Harutyunyan wrote:
>> On 2/19/2018 12:51 PM, Marek Vasut wrote:
>>> On 02/19/2018 09:19 AM, Minas Harutyunyan wrote:
>>>> On 2/17/2018 12:07 AM, Marek Vasut wrote:
>>>>> On 02/16/2018 06:59 AM, Minas Harutyunyan wrote:
>>>>>> On 2/15/2018 5:20 PM, Mirza Krak wrote:
>>>>>>> On 14 February 2018 at 13:07, Minas Harutyunyan
>>>>>>> <Minas.Harutyunyan at synopsys.com> wrote:
>>>>>>>> On 2/14/2018 12:57 PM, Mirza Krak wrote:
>>>>>>>>> On 8 February 2018 at 14:53, Minas Harutyunyan
>>>>>>>>> <Minas.Harutyunyan at synopsys.com> wrote:
>>>>>>>
>>>>>>> < snip >
>>>>>>>
>>>>>>>>
>>>>>>>> I reviewed your interrupt count log again. About 140,000 interrupts in 2
>>>>>>>> seconds, obviously it's not SOF only interrupts. More probably, its NAK
>>>>>>>> respond interrupts to SSPLIT/CSPLIT transactions. For this case I can
>>>>>>>> recommend you to apply patch from Douglas Anderson: "[PATCH v2] usb:
>>>>>>>> dwc2: host: Don't retry NAKed transactions right away" which already
>>>>>>>> merged to 4.16-rc1.
>>>>>>>>
>>>>>>>> In your setups you see different behavior on different HUBs. Your HUBs
>>>>>>>> have different "TT think time": 8 and 32. In USB2.0 spec "TT think time"
>>>>>>>> described as follow "TT requires at most 8/32 FS bit times of inter
>>>>>>>> transaction gap on a full-/low-speed downstream bus". So, your "worst"
>>>>>>>> HUB with "TT think time"=8 sending more frequently SSPLIT/CSPLIT
>>>>>>>> transactions which replied by NAK. As result you see about 4 time more
>>>>>>>> interrupts comparing to "good" HUB. Could you please check interrupts
>>>>>>>> count for "good" HUB and check "4 time" hypothesis.
>>>>>>>
>>>>>>> Did some further testing. The "good" HUB is actually as bad as the
>>>>>>> "bad" HUB, and it was my setup that caused the different behavior. Did
>>>>>>> not use the same devices etc.
>>>>>>>
>>>>>>> Once I made sure that the configuration and setup was the same on both
>>>>>>> board I could see that the behaved similarly. And that is the
>>>>>>> following interrupt load:
>>>>>>>
>>>>>>> - BT USB (FS) = ~80k interrupts / second
>>>>>>> - Keyboard (FS) = ~80k interrupts / second
>>>>>>> - WiFI USB (HS) = ~8k interrupts / second
>>>>>>>
>>>>>>> After applying the suggested patch [1], it is steady around 8k
>>>>>>> interrupts / second no matter what device I connect (HS/FS,
>>>>>>> HUB/NO-HUB). Which is acceptable and usable.
>>>>>>
>>>>>> Great!
>>>>>
>>>>> So 8k IRQs per second is what I should expect from this HW with HS
>>>>> device attached, that's normal and cannot be reduced ?
>>>>>
>>>> If core acting as Host in Buffer DMA mode then 8k IRQs per second (SOF
>>>> interrupts) is expected if connected device(s) has periodic endpoint.
>>>
>>> Is there a way to reduce that or is that the absolute minimum in HS mode?
>>>
>> We already discussed, in this email thread earlier, why SOF interrupts
>> required and unmasked.
>> Only in case when connected device with CTRL+BLK EP's only (like flash
>> drive) and directly connected to cores root HUB, SOF's will be masked.
> 
> That's the setup I have on Altera SoCFPGA, yet the SOFs are still present.
> 
Could you please send verbose lsusb on connected to dwc2 device and 
driver debug log.
Thanks,
Minas