High CPU load produced by USB (DW2)

High CPU load produced by USB (DW2)

[Mirza Krak]

Hi.

I initially started a thread on a different mailing list [1], and you
can take look there for some additional background.

I am using a 4.14.15 stable kernel on a RK3288 SoC (FireFly RK3288
board) which uses the DW2 USB core. I have noticed that when
connecting a USB device there is unreasonable high CPU load produced
by the USB interrupts.

Here is one example with a MIDI keyboard connected on USB (not really
doing anything on it)

   79     2 root     SW       0   0%  19% [irq/45-dwc2_hso]
   78     2 root     SW       0   0%  11% [irq/45-ff540000]

Can also see that there is a "HIGH" interrupt count

root@esp5-d1:~# watch cat /proc/interrupts | grep usb
 45:   43681938          0          0          0     GIC-0  57 Level
  ff540000.usb, dwc2_hsotg:usb1
 46:          0          0          0          0     GIC-0  55 Level
  ff580000.usb, ff580000.usb, dwc2_hsotg:usb2
 45:   43829473          0          0          0     GIC-0  57 Level
  ff540000.usb, dwc2_hsotg:usb1
 46:          0          0          0          0     GIC-0  55 Level
  ff580000.usb, ff580000.usb, dwc2_hsotg:usb2
 45:   43972333          0          0          0     GIC-0  57 Level
  ff540000.usb, dwc2_hsotg:usb1
 46:          0          0          0          0     GIC-0  55 Level
  ff580000.usb, ff580000.usb, dwc2_hsotg:usb2
 45:   44118769          0          0          0     GIC-0  57 Level
  ff540000.usb, dwc2_hsotg:usb1
 46:          0          0          0          0     GIC-0  55 Level
  ff580000.usb, ff580000.usb, dwc2_hsotg:usb2
 45:   44267876          0          0          0     GIC-0  57 Level
  ff540000.usb, dwc2_hsotg:usb1
 46:          0          0          0          0     GIC-0  55 Level
  ff580000.usb, ff580000.usb, dwc2_hsotg:usb2

Again not really doing anything with the device, it is just connected.
I have also tested with server different devices with same result (BT
and WLAN).

The CPU load is exposed when I add "threadirqs" to kernel arguments,
otherwise it does not seem that it accounted for (not see in "top")
but the number of interrupts is still high.

Any thoughts on this? Please let me know if there is additional
information that I can provide to help debug this.


[1]. https://www.spinics.net/lists/linux-rt-users/msg18341.html

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: High CPU load produced by USB (DW2)

[gregkh]

On Wed, Feb 07, 2018 at 10:48:57AM +0100, Mirza Krak wrote:
> Hi.
> 
> I initially started a thread on a different mailing list [1], and you
> can take look there for some additional background.
> 
> I am using a 4.14.15 stable kernel on a RK3288 SoC (FireFly RK3288
> board) which uses the DW2 USB core. I have noticed that when
> connecting a USB device there is unreasonable high CPU load produced
> by the USB interrupts.

That's a normal problem with that kind of hardware.  I've seen devices
with that type of USB core take a 30% cpu usage just when you plug a USB
keyboard into the device.

There's not much the kernel can do about horrible hardware, sorry, go
complain to the device manufacturer :(

> Here is one example with a MIDI keyboard connected on USB (not really
> doing anything on it)
> 
>    79     2 root     SW       0   0%  19% [irq/45-dwc2_hso]
>    78     2 root     SW       0   0%  11% [irq/45-ff540000]

It doesn't matter if anything is happening on the device, USB goes and
polls the device all the time, that's just the way that the protocol
works.  With hardware like this, that polling is done by the kernel
driver/CPU and does not have offload capability to the USB controller to
handle this type of housekeeping.  Because of that, you see tons of CPU
interrupts and a high load.

Again, not much we can do about that, sorry :(

good luck!

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: High CPU load produced by USB (DW2)

[Minas Harutyunyan]

On 2/7/2018 6:28 PM, gregkh wrote:
> On Wed, Feb 07, 2018 at 10:48:57AM +0100, Mirza Krak wrote:
>> Hi.
>>
>> I initially started a thread on a different mailing list [1], and you
>> can take look there for some additional background.
>>
>> I am using a 4.14.15 stable kernel on a RK3288 SoC (FireFly RK3288
>> board) which uses the DW2 USB core. I have noticed that when
>> connecting a USB device there is unreasonable high CPU load produced
>> by the USB interrupts.
> 
> That's a normal problem with that kind of hardware.  I've seen devices
> with that type of USB core take a 30% cpu usage just when you plug a USB
> keyboard into the device.
> 
> There's not much the kernel can do about horrible hardware, sorry, go
> complain to the device manufacturer :(
> 
>> Here is one example with a MIDI keyboard connected on USB (not really
>> doing anything on it)
>>
>>     79     2 root     SW       0   0%  19% [irq/45-dwc2_hso]
>>     78     2 root     SW       0   0%  11% [irq/45-ff540000]
> 
> It doesn't matter if anything is happening on the device, USB goes and
> polls the device all the time, that's just the way that the protocol
> works.  With hardware like this, that polling is done by the kernel
> driver/CPU and does not have offload capability to the USB controller to
> handle this type of housekeeping.  Because of that, you see tons of CPU
> interrupts and a high load.
> 
> Again, not much we can do about that, sorry :(
> 
> good luck!
> 
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  https://urldefense.proofpoint.com/v2/url?u=http-3A__vger.kernel.org_majordomo-2Dinfo.html&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI&m=mnEzj_Q87pyYPBxV3CbMXuG55KNzxqhYf7tuz517xjg&s=eftxO7ffuUu2L87Mqwa6K8p7s1mpI__boRvzDI70HvY&e=
> 
dwc2 HW doesn't track (u)frames internally. SW forced to track (u)frames 
by unmasking SOF interrupts. This is why when any device with periodic 
EP connected to port require to unmask SOF's as result seen high CPU 
load. dwc2 SW dynamically mask/unmask SOF interrupts depend on using 
periodic EP by connected device.
There are no any polling in SW.

Lot of HW functionality delegated to dwc2 driver to reduce gate count in HW.
This "horrible" core very small and cheap.

good luck!

Minas
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: High CPU load produced by USB (DW2)

[Minas Harutyunyan]

Hi Mirza,

On 2/7/2018 1:49 PM, Mirza Krak wrote:
> Hi.
> 
> I initially started a thread on a different mailing list [1], and you
> can take look there for some additional background.
> 
> I am using a 4.14.15 stable kernel on a RK3288 SoC (FireFly RK3288
> board) which uses the DW2 USB core. I have noticed that when
> connecting a USB device there is unreasonable high CPU load produced
> by the USB interrupts.
> 
> Here is one example with a MIDI keyboard connected on USB (not really
> doing anything on it)
> 
>     79     2 root     SW       0   0%  19% [irq/45-dwc2_hso]
>     78     2 root     SW       0   0%  11% [irq/45-ff540000]
> 
> Can also see that there is a "HIGH" interrupt count
> 
> root@esp5-d1:~# watch cat /proc/interrupts | grep usb
>   45:   43681938          0          0          0     GIC-0  57 Level
>    ff540000.usb, dwc2_hsotg:usb1
>   46:          0          0          0          0     GIC-0  55 Level
>    ff580000.usb, ff580000.usb, dwc2_hsotg:usb2
>   45:   43829473          0          0          0     GIC-0  57 Level
>    ff540000.usb, dwc2_hsotg:usb1
>   46:          0          0          0          0     GIC-0  55 Level
>    ff580000.usb, ff580000.usb, dwc2_hsotg:usb2
>   45:   43972333          0          0          0     GIC-0  57 Level
>    ff540000.usb, dwc2_hsotg:usb1
>   46:          0          0          0          0     GIC-0  55 Level
>    ff580000.usb, ff580000.usb, dwc2_hsotg:usb2
>   45:   44118769          0          0          0     GIC-0  57 Level
>    ff540000.usb, dwc2_hsotg:usb1
>   46:          0          0          0          0     GIC-0  55 Level
>    ff580000.usb, ff580000.usb, dwc2_hsotg:usb2
>   45:   44267876          0          0          0     GIC-0  57 Level
>    ff540000.usb, dwc2_hsotg:usb1
>   46:          0          0          0          0     GIC-0  55 Level
>    ff580000.usb, ff580000.usb, dwc2_hsotg:usb2
> 
> Again not really doing anything with the device, it is just connected.
> I have also tested with server different devices with same result (BT
> and WLAN).
> 
> The CPU load is exposed when I add "threadirqs" to kernel arguments,
> otherwise it does not seem that it accounted for (not see in "top")
> but the number of interrupts is still high.
> 
> Any thoughts on this? Please let me know if there is additional
> information that I can provide to help debug this.
> 
> 
> [1]. https://urldefense.proofpoint.com/v2/url?u=https-3A__www.spinics.net_lists_linux-2Drt-2Dusers_msg18341.html&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI&m=DnUeBv1jR8jz4npf8WClUsYhhcd0eYqW0aDc4l7V96o&s=6fpUB5epwB1otF9_hwacG1JIkWJaHN0duhAyZIaiMqM&e=
> 

Could you please provide additional info:
1. Does your core support descriptor DMA mode? (bits 31 and 30 of GHWCFG4).
2. Version of core (GSNPSID)?
3. Do you connect any HS HUB between dwc core port and keyboard? Is it 
available connection scenarios when Split traffic generated?
Thanks,
Minas
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: High CPU load produced by USB (DW2)

[Mirza Krak]

On 8 February 2018 at 12:02, Minas Harutyunyan
<Minas.Harutyunyan-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> wrote:
> Hi Mirza,
>
> On 2/7/2018 1:49 PM, Mirza Krak wrote:

< snip >

>
> Could you please provide additional info:
> 1. Does your core support descriptor DMA mode? (bits 31 and 30 of GHWCFG4).
> 2. Version of core (GSNPSID)?

It does seem to support descriptor DMA mode, and content of both
GHWCFG4 and GSNPSID are posted below.

root@esp5-d1:~# dmesg | grep -E "GHWCFG4|GSNPSID"
[    1.109298] dwc2 ff540000.usb: GSNPSID @0xF0940040 : 0x4F54310A
[    1.109344] dwc2 ff540000.usb: GHWCFG4 @0xF0940050 : 0xC8004030
[    1.489016] dwc2 ff580000.usb: GSNPSID @0xF09C0040 : 0x4F54310A
[    1.489063] dwc2 ff580000.usb: GHWCFG4 @0xF09C0050 : 0xDBF04030

Full register dump at boot (no devices connected) can be found at [1].

> 3. Do you connect any HS HUB between dwc core port and keyboard? Is it
> available connection scenarios when Split traffic generated?

There is actually an HS HUB (FE1_QFP48) between dwc core and keyboard,
I was not aware of it but it is mounted on the board.


[1]. https://gist.github.com/mirzak/a6245dddd4670f3b908a9783f9db8b0d
-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: High CPU load produced by USB (DW2)

[Minas Harutyunyan]

On 2/8/2018 5:07 PM, Mirza Krak wrote:
> On 8 February 2018 at 12:02, Minas Harutyunyan
> <Minas.Harutyunyan-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> wrote:
>> Hi Mirza,
>>
>> On 2/7/2018 1:49 PM, Mirza Krak wrote:
> 
> < snip >
> 
>>
>> Could you please provide additional info:
>> 1. Does your core support descriptor DMA mode? (bits 31 and 30 of GHWCFG4).
>> 2. Version of core (GSNPSID)?
> 
> It does seem to support descriptor DMA mode, and content of both
> GHWCFG4 and GSNPSID are posted below.
> 
> root@esp5-d1:~# dmesg | grep -E "GHWCFG4|GSNPSID"
> [    1.109298] dwc2 ff540000.usb: GSNPSID @0xF0940040 : 0x4F54310A
> [    1.109344] dwc2 ff540000.usb: GHWCFG4 @0xF0940050 : 0xC8004030
> [    1.489016] dwc2 ff580000.usb: GSNPSID @0xF09C0040 : 0x4F54310A
> [    1.489063] dwc2 ff580000.usb: GHWCFG4 @0xF09C0050 : 0xDBF04030
> 
> Full register dump at boot (no devices connected) can be found at [1].
> 
>> 3. Do you connect any HS HUB between dwc core port and keyboard? Is it
>> available connection scenarios when Split traffic generated?
> 
> There is actually an HS HUB (FE1_QFP48) between dwc core and keyboard,
> I was not aware of it but it is mounted on the board.
> 
> 
> [1]. https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_mirzak_a6245dddd4670f3b908a9783f9db8b0d&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI&m=FuRmhDEOJlbUvuyApaxG_YmB514C3IOGSzs6Mq_fzC0&s=ELF0UP4IluOiL35JlnFjiltWZx-BcTIsTaPjaWb0RFk&e=
> 
Actually your core supported DDMA mode, moreover core allow SW to 
dynamically switch between BDMA and DDMA after core reset.
If dwc2 core work in DDMA mode then core can track (u)frames internally 
and unmasking SOF's not required, but Host in DDMA doesn't support Split 
transfers. This is why, in your case (FS/LS keyboard connected to HS 
HUB), core switched to BDMA and unmasking SOF interrupt to track (u)frames.

Thanks,
Minas
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: High CPU load produced by USB (DW2)

[Mirza Krak]

On 8 February 2018 at 14:53, Minas Harutyunyan
<Minas.Harutyunyan@synopsys.com> wrote:
> On 2/8/2018 5:07 PM, Mirza Krak wrote:
>> On 8 February 2018 at 12:02, Minas Harutyunyan
>> <Minas.Harutyunyan@synopsys.com> wrote:
>>> Hi Mirza,
>>>
>>> On 2/7/2018 1:49 PM, Mirza Krak wrote:
>>
>> < snip >
>>
>>>
>>> Could you please provide additional info:
>>> 1. Does your core support descriptor DMA mode? (bits 31 and 30 of GHWCFG4).
>>> 2. Version of core (GSNPSID)?
>>
>> It does seem to support descriptor DMA mode, and content of both
>> GHWCFG4 and GSNPSID are posted below.
>>
>> root@esp5-d1:~# dmesg | grep -E "GHWCFG4|GSNPSID"
>> [    1.109298] dwc2 ff540000.usb: GSNPSID @0xF0940040 : 0x4F54310A
>> [    1.109344] dwc2 ff540000.usb: GHWCFG4 @0xF0940050 : 0xC8004030
>> [    1.489016] dwc2 ff580000.usb: GSNPSID @0xF09C0040 : 0x4F54310A
>> [    1.489063] dwc2 ff580000.usb: GHWCFG4 @0xF09C0050 : 0xDBF04030
>>
>> Full register dump at boot (no devices connected) can be found at [1].
>>
>>> 3. Do you connect any HS HUB between dwc core port and keyboard? Is it
>>> available connection scenarios when Split traffic generated?
>>
>> There is actually an HS HUB (FE1_QFP48) between dwc core and keyboard,
>> I was not aware of it but it is mounted on the board.
>>
>>
>> [1]. https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_mirzak_a6245dddd4670f3b908a9783f9db8b0d&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI&m=FuRmhDEOJlbUvuyApaxG_YmB514C3IOGSzs6Mq_fzC0&s=ELF0UP4IluOiL35JlnFjiltWZx-BcTIsTaPjaWb0RFk&e=
>>
> Actually your core supported DDMA mode, moreover core allow SW to
> dynamically switch between BDMA and DDMA after core reset.
> If dwc2 core work in DDMA mode then core can track (u)frames internally
> and unmasking SOF's not required, but Host in DDMA doesn't support Split
> transfers. This is why, in your case (FS/LS keyboard connected to HS
> HUB), core switched to BDMA and unmasking SOF interrupt to track (u)frames.

Thank you for your valuable respons.

It is indeed as you mentioned the combination of HS and FS/LS devices
that trigger the high CPU load. Running HS only devices does not
produce any noticeable load.

But I am confused by one thing, I have two different boards with the
same SoC and same version of the DWC2 IP. Both boards have an internal
USB hub for the external connectors, though it seems that they have
different types of HUB' s. And I only have problems with one of them.
The second board does not have a problem mixing HS and FS/LS devices.
Is it possible that the USB HUB has some kind of "offloading" for the
Split transfers?

Tinkerboard USB hub (works well when mixing HS and FS/LS devices)
----------------------------

$ lsusb -t
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Audio, Driver=, 480M
    |__ Port 1: Dev 2, If 1, Class=Audio, Driver=, 480M
    |__ Port 1: Dev 2, If 2, Class=Audio, Driver=, 480M
    |__ Port 1: Dev 2, If 3, Class=Audio, Driver=, 480M
    |__ Port 1: Dev 2, If 4, Class=Audio, Driver=, 480M
    |__ Port 1: Dev 2, If 5, Class=Audio, Driver=, 480M
    |__ Port 1: Dev 2, If 255, Class=Human Interface Device, Driver=usbhid, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 3: Dev 4, If 0, Class=Audio, Driver=, 12M
        |__ Port 3: Dev 4, If 1, Class=Audio, Driver=, 12M
        |__ Port 4: Dev 3, If 0, Class=Human Interface Device,
Driver=usbhid, 12M

$ lsusb -d 05e3:0610 -v

Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0
  bDeviceProtocol         2 TT per port
  bMaxPacketSize0        64
  idVendor           0x05e3 Genesys Logic, Inc.
  idProduct          0x0610 4-port hub
  bcdDevice           32.98
  iManufacturer           0
  iProduct                1 USB2.0 Hub
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           41
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0
      bInterfaceProtocol      1 Single TT
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              12
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0
      bInterfaceProtocol      2 TT per port
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              12
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             4
  wHubCharacteristic 0x00e0
    Ganged power switching
    Ganged overcurrent protection
    TT think time 32 FS bits
    Port indicators
  bPwrOn2PwrGood       50 * 2 milli seconds
  bHubContrCurrent    100 milli Ampere
  DeviceRemovable    0x00
  PortPwrCtrlMask    0xff
 Hub Port Status:
   Port 1: 0000.0100 power
   Port 2: 0000.0100 power
   Port 3: 0000.0103 power enable connect
   Port 4: 0000.0103 power enable connect
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0
  bDeviceProtocol         0 Full speed (or root) hub
  bMaxPacketSize0        64
  bNumConfigurations      1
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x0001
  Self Powered


FireFly USB HUB (does not work well when mixing HS and FS/LS devices)
-----------------------

$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 480M
        |__ Port 3: Dev 4, If 0, Class=Audio, Driver=snd-usb-audio, 12M
        |__ Port 3: Dev 4, If 1, Class=Audio, Driver=snd-usb-audio, 12M

$ lsusb -d 1a40:0101 -v

Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0
  bDeviceProtocol         2 TT per port
  bMaxPacketSize0        64
  idVendor           0x1a40 Terminus Technology Inc.
  idProduct          0x0101 Hub
  bcdDevice            1.00
  iManufacturer           0
  iProduct                1 USB 2.0 Hub [MTT]
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           41
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0
      bInterfaceProtocol      1 Single TT
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              12
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0
      bInterfaceProtocol      2 TT per port
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              12
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             4
  wHubCharacteristic 0x0080
    Ganged power switching
    Ganged overcurrent protection
    TT think time 8 FS bits
    Port indicators
  bPwrOn2PwrGood       50 * 2 milli seconds
  bHubContrCurrent    100 milli Ampere
  DeviceRemovable    0x00
  PortPwrCtrlMask    0xff
 Hub Port Status:
   Port 1: 0000.0503 highspeed power enable connect
   Port 2: 0000.0100 power
   Port 3: 0000.0103 power enable connect
   Port 4: 0000.0100 power
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0
  bDeviceProtocol         0 Full speed (or root) hub
  bMaxPacketSize0        64
  bNumConfigurations      1
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x0001
  Self Powered

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: High CPU load produced by USB (DW2)

[Minas Harutyunyan]

On 2/14/2018 12:57 PM, Mirza Krak wrote:
> On 8 February 2018 at 14:53, Minas Harutyunyan
> <Minas.Harutyunyan-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> wrote:
>> On 2/8/2018 5:07 PM, Mirza Krak wrote:
>>> On 8 February 2018 at 12:02, Minas Harutyunyan
>>> <Minas.Harutyunyan-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> wrote:
>>>> Hi Mirza,
>>>>
>>>> On 2/7/2018 1:49 PM, Mirza Krak wrote:
>>>
>>> < snip >
>>>
>>>>
>>>> Could you please provide additional info:
>>>> 1. Does your core support descriptor DMA mode? (bits 31 and 30 of GHWCFG4).
>>>> 2. Version of core (GSNPSID)?
>>>
>>> It does seem to support descriptor DMA mode, and content of both
>>> GHWCFG4 and GSNPSID are posted below.
>>>
>>> root@esp5-d1:~# dmesg | grep -E "GHWCFG4|GSNPSID"
>>> [    1.109298] dwc2 ff540000.usb: GSNPSID @0xF0940040 : 0x4F54310A
>>> [    1.109344] dwc2 ff540000.usb: GHWCFG4 @0xF0940050 : 0xC8004030
>>> [    1.489016] dwc2 ff580000.usb: GSNPSID @0xF09C0040 : 0x4F54310A
>>> [    1.489063] dwc2 ff580000.usb: GHWCFG4 @0xF09C0050 : 0xDBF04030
>>>
>>> Full register dump at boot (no devices connected) can be found at [1].
>>>
>>>> 3. Do you connect any HS HUB between dwc core port and keyboard? Is it
>>>> available connection scenarios when Split traffic generated?
>>>
>>> There is actually an HS HUB (FE1_QFP48) between dwc core and keyboard,
>>> I was not aware of it but it is mounted on the board.
>>>
>>>
>>> [1]. https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_mirzak_a6245dddd4670f3b908a9783f9db8b0d&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI&m=FuRmhDEOJlbUvuyApaxG_YmB514C3IOGSzs6Mq_fzC0&s=ELF0UP4IluOiL35JlnFjiltWZx-BcTIsTaPjaWb0RFk&e=
>>>
>> Actually your core supported DDMA mode, moreover core allow SW to
>> dynamically switch between BDMA and DDMA after core reset.
>> If dwc2 core work in DDMA mode then core can track (u)frames internally
>> and unmasking SOF's not required, but Host in DDMA doesn't support Split
>> transfers. This is why, in your case (FS/LS keyboard connected to HS
>> HUB), core switched to BDMA and unmasking SOF interrupt to track (u)frames.
> 
> Thank you for your valuable respons.
> 
> It is indeed as you mentioned the combination of HS and FS/LS devices
> that trigger the high CPU load. Running HS only devices does not
> produce any noticeable load.
> 
> But I am confused by one thing, I have two different boards with the
> same SoC and same version of the DWC2 IP. Both boards have an internal
> USB hub for the external connectors, though it seems that they have
> different types of HUB' s. And I only have problems with one of them.
> The second board does not have a problem mixing HS and FS/LS devices.
> Is it possible that the USB HUB has some kind of "offloading" for the
> Split transfers?
> 
> Tinkerboard USB hub (works well when mixing HS and FS/LS devices)
> ----------------------------
> 
> $ lsusb -t
> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
>      |__ Port 1: Dev 2, If 0, Class=Audio, Driver=, 480M
>      |__ Port 1: Dev 2, If 1, Class=Audio, Driver=, 480M
>      |__ Port 1: Dev 2, If 2, Class=Audio, Driver=, 480M
>      |__ Port 1: Dev 2, If 3, Class=Audio, Driver=, 480M
>      |__ Port 1: Dev 2, If 4, Class=Audio, Driver=, 480M
>      |__ Port 1: Dev 2, If 5, Class=Audio, Driver=, 480M
>      |__ Port 1: Dev 2, If 255, Class=Human Interface Device, Driver=usbhid, 480M
> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
>      |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
>          |__ Port 3: Dev 4, If 0, Class=Audio, Driver=, 12M
>          |__ Port 3: Dev 4, If 1, Class=Audio, Driver=, 12M
>          |__ Port 4: Dev 3, If 0, Class=Human Interface Device,
> Driver=usbhid, 12M
> 
> $ lsusb -d 05e3:0610 -v
> 
> Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
> Device Descriptor:
>    bLength                18
>    bDescriptorType         1
>    bcdUSB               2.00
>    bDeviceClass            9 Hub
>    bDeviceSubClass         0
>    bDeviceProtocol         2 TT per port
>    bMaxPacketSize0        64
>    idVendor           0x05e3 Genesys Logic, Inc.
>    idProduct          0x0610 4-port hub
>    bcdDevice           32.98
>    iManufacturer           0
>    iProduct                1 USB2.0 Hub
>    iSerial                 0
>    bNumConfigurations      1
>    Configuration Descriptor:
>      bLength                 9
>      bDescriptorType         2
>      wTotalLength           41
>      bNumInterfaces          1
>      bConfigurationValue     1
>      iConfiguration          0
>      bmAttributes         0xe0
>        Self Powered
>        Remote Wakeup
>      MaxPower              100mA
>      Interface Descriptor:
>        bLength                 9
>        bDescriptorType         4
>        bInterfaceNumber        0
>        bAlternateSetting       0
>        bNumEndpoints           1
>        bInterfaceClass         9 Hub
>        bInterfaceSubClass      0
>        bInterfaceProtocol      1 Single TT
>        iInterface              0
>        Endpoint Descriptor:
>          bLength                 7
>          bDescriptorType         5
>          bEndpointAddress     0x81  EP 1 IN
>          bmAttributes            3
>            Transfer Type            Interrupt
>            Synch Type               None
>            Usage Type               Data
>          wMaxPacketSize     0x0001  1x 1 bytes
>          bInterval              12
>      Interface Descriptor:
>        bLength                 9
>        bDescriptorType         4
>        bInterfaceNumber        0
>        bAlternateSetting       1
>        bNumEndpoints           1
>        bInterfaceClass         9 Hub
>        bInterfaceSubClass      0
>        bInterfaceProtocol      2 TT per port
>        iInterface              0
>        Endpoint Descriptor:
>          bLength                 7
>          bDescriptorType         5
>          bEndpointAddress     0x81  EP 1 IN
>          bmAttributes            3
>            Transfer Type            Interrupt
>            Synch Type               None
>            Usage Type               Data
>          wMaxPacketSize     0x0001  1x 1 bytes
>          bInterval              12
> Hub Descriptor:
>    bLength               9
>    bDescriptorType      41
>    nNbrPorts             4
>    wHubCharacteristic 0x00e0
>      Ganged power switching
>      Ganged overcurrent protection
>      TT think time 32 FS bits
>      Port indicators
>    bPwrOn2PwrGood       50 * 2 milli seconds
>    bHubContrCurrent    100 milli Ampere
>    DeviceRemovable    0x00
>    PortPwrCtrlMask    0xff
>   Hub Port Status:
>     Port 1: 0000.0100 power
>     Port 2: 0000.0100 power
>     Port 3: 0000.0103 power enable connect
>     Port 4: 0000.0103 power enable connect
> Device Qualifier (for other device speed):
>    bLength                10
>    bDescriptorType         6
>    bcdUSB               2.00
>    bDeviceClass            9 Hub
>    bDeviceSubClass         0
>    bDeviceProtocol         0 Full speed (or root) hub
>    bMaxPacketSize0        64
>    bNumConfigurations      1
> can't get debug descriptor: Resource temporarily unavailable
> Device Status:     0x0001
>    Self Powered
> 
> 
> FireFly USB HUB (does not work well when mixing HS and FS/LS devices)
> -----------------------
> 
> $ lsusb -t
> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
>      |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
>          |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 480M
>          |__ Port 3: Dev 4, If 0, Class=Audio, Driver=snd-usb-audio, 12M
>          |__ Port 3: Dev 4, If 1, Class=Audio, Driver=snd-usb-audio, 12M
> 
> $ lsusb -d 1a40:0101 -v
> 
> Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
> Device Descriptor:
>    bLength                18
>    bDescriptorType         1
>    bcdUSB               2.00
>    bDeviceClass            9 Hub
>    bDeviceSubClass         0
>    bDeviceProtocol         2 TT per port
>    bMaxPacketSize0        64
>    idVendor           0x1a40 Terminus Technology Inc.
>    idProduct          0x0101 Hub
>    bcdDevice            1.00
>    iManufacturer           0
>    iProduct                1 USB 2.0 Hub [MTT]
>    iSerial                 0
>    bNumConfigurations      1
>    Configuration Descriptor:
>      bLength                 9
>      bDescriptorType         2
>      wTotalLength           41
>      bNumInterfaces          1
>      bConfigurationValue     1
>      iConfiguration          0
>      bmAttributes         0xe0
>        Self Powered
>        Remote Wakeup
>      MaxPower              100mA
>      Interface Descriptor:
>        bLength                 9
>        bDescriptorType         4
>        bInterfaceNumber        0
>        bAlternateSetting       0
>        bNumEndpoints           1
>        bInterfaceClass         9 Hub
>        bInterfaceSubClass      0
>        bInterfaceProtocol      1 Single TT
>        iInterface              0
>        Endpoint Descriptor:
>          bLength                 7
>          bDescriptorType         5
>          bEndpointAddress     0x81  EP 1 IN
>          bmAttributes            3
>            Transfer Type            Interrupt
>            Synch Type               None
>            Usage Type               Data
>          wMaxPacketSize     0x0001  1x 1 bytes
>          bInterval              12
>      Interface Descriptor:
>        bLength                 9
>        bDescriptorType         4
>        bInterfaceNumber        0
>        bAlternateSetting       1
>        bNumEndpoints           1
>        bInterfaceClass         9 Hub
>        bInterfaceSubClass      0
>        bInterfaceProtocol      2 TT per port
>        iInterface              0
>        Endpoint Descriptor:
>          bLength                 7
>          bDescriptorType         5
>          bEndpointAddress     0x81  EP 1 IN
>          bmAttributes            3
>            Transfer Type            Interrupt
>            Synch Type               None
>            Usage Type               Data
>          wMaxPacketSize     0x0001  1x 1 bytes
>          bInterval              12
> Hub Descriptor:
>    bLength               9
>    bDescriptorType      41
>    nNbrPorts             4
>    wHubCharacteristic 0x0080
>      Ganged power switching
>      Ganged overcurrent protection
>      TT think time 8 FS bits
>      Port indicators
>    bPwrOn2PwrGood       50 * 2 milli seconds
>    bHubContrCurrent    100 milli Ampere
>    DeviceRemovable    0x00
>    PortPwrCtrlMask    0xff
>   Hub Port Status:
>     Port 1: 0000.0503 highspeed power enable connect
>     Port 2: 0000.0100 power
>     Port 3: 0000.0103 power enable connect
>     Port 4: 0000.0100 power
> Device Qualifier (for other device speed):
>    bLength                10
>    bDescriptorType         6
>    bcdUSB               2.00
>    bDeviceClass            9 Hub
>    bDeviceSubClass         0
>    bDeviceProtocol         0 Full speed (or root) hub
>    bMaxPacketSize0        64
>    bNumConfigurations      1
> can't get debug descriptor: Resource temporarily unavailable
> Device Status:     0x0001
>    Self Powered
> 

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.

Thanks,
Minas

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: High CPU load produced by USB (DW2)

[Mirza Krak]

On 14 February 2018 at 13:07, Minas Harutyunyan
<Minas.Harutyunyan-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> wrote:
> On 2/14/2018 12:57 PM, Mirza Krak wrote:
>> On 8 February 2018 at 14:53, Minas Harutyunyan
>> <Minas.Harutyunyan-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> 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.

Should this patch be a candidate for stable? Because in the current
state, this combination DWC2 + HS HUB + FS device, is not "usable".

[1]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/dwc2?h=v4.16-rc1&id=38d2b5fb75c15923fb89c32134516a623515bce4

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: High CPU load produced by USB (DW2)

[Minas Harutyunyan]

On 2/15/2018 5:20 PM, Mirza Krak wrote:
> On 14 February 2018 at 13:07, Minas Harutyunyan
> <Minas.Harutyunyan-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> wrote:
>> On 2/14/2018 12:57 PM, Mirza Krak wrote:
>>> On 8 February 2018 at 14:53, Minas Harutyunyan
>>> <Minas.Harutyunyan-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> 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!
> 
> Should this patch be a candidate for stable? Because in the current
> state, this combination DWC2 + HS HUB + FS device, is not "usable".
> 
Ask the author of patch or dwc2 maintainer.

Thanks,
Minas


> [1]. https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_commit_drivers_usb_dwc2-3Fh-3Dv4.16-2Drc1-26id-3D38d2b5fb75c15923fb89c32134516a623515bce4&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI&m=5Np0whDSSNNvE3TAVBpFa0JUmvQbS3qWdpC0PQssosY&s=CYTOKYUsKlYbJKodeDN_ZybQpBL0ULIyf2Y_MeZgV30&e=
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: High CPU load produced by USB (DW2)

[Marek Vasut]

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-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> wrote:
>>> On 2/14/2018 12:57 PM, Mirza Krak wrote:
>>>> On 8 February 2018 at 14:53, Minas Harutyunyan
>>>> <Minas.Harutyunyan-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> 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 ?

-- 
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: High CPU load produced by USB (DW2)

[Minas Harutyunyan]

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-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> wrote:
>>>> On 2/14/2018 12:57 PM, Mirza Krak wrote:
>>>>> On 8 February 2018 at 14:53, Minas Harutyunyan
>>>>> <Minas.Harutyunyan-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> 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.

Thanks,
Minas

Re: High CPU load produced by USB (DW2)

[Marek Vasut]

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-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> wrote:
>>>>> On 2/14/2018 12:57 PM, Mirza Krak wrote:
>>>>>> On 8 February 2018 at 14:53, Minas Harutyunyan
>>>>>> <Minas.Harutyunyan-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> 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?

-- 
Best regards,
Marek Vasut

Re: High CPU load produced by USB (DW2)

[Minas Harutyunyan]

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-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> wrote:
>>>>>> On 2/14/2018 12:57 PM, Mirza Krak wrote:
>>>>>>> On 8 February 2018 at 14:53, Minas Harutyunyan
>>>>>>> <Minas.Harutyunyan-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> 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.
Thanks,
Minas

Re: High CPU load produced by USB (DW2)

[Marek Vasut]

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-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> wrote:
>>>>>>> On 2/14/2018 12:57 PM, Mirza Krak wrote:
>>>>>>>> On 8 February 2018 at 14:53, Minas Harutyunyan
>>>>>>>> <Minas.Harutyunyan-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> 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.

-- 
Best regards,
Marek Vasut

Re: 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-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> wrote:
>>>>>>>> On 2/14/2018 12:57 PM, Mirza Krak wrote:
>>>>>>>>> On 8 February 2018 at 14:53, Minas Harutyunyan
>>>>>>>>> <Minas.Harutyunyan-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> 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

Re: High CPU load produced by USB (DW2)

[Marek Vasut]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

On 02/20/2018 06:51 AM, Minas Harutyunyan wrote:
[...]
>>>> 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

See attached

> and driver debug log.

What exactly do you mean by this one ?

-- 
Best regards,
Marek Vasut

[-- Attachment #2: usb.log --]
[-- Type: text/x-log, Size: 8073 bytes --]


Bus 001 Device 003: ID 0781:5581 SanDisk Corp. Ultra
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0781 SanDisk Corp.
  idProduct          0x5581 Ultra
  bcdDevice            1.00
  iManufacturer           1 SanDisk
  iProduct                2 Ultra
  iSerial                 3 4C530001110620109113
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              224mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength           22
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000002
      Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   1
      Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat          10 micro seconds
    bU2DevExitLat         256 micro seconds
Device Status:     0x0000
  (Bus Powered)

Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         2 TT per port
  bMaxPacketSize0        64
  idVendor           0x0424 Standard Microsystems Corp.
  idProduct          0x2514 USB 2.0 Hub
  bcdDevice            b.b3
  iManufacturer           0 
  iProduct                0 
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           41
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                2mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      1 Single TT
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              12
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      2 TT per port
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              12
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             4
  wHubCharacteristic 0x0009
    Per-port power switching
    Per-port overcurrent protection
    TT think time 8 FS bits
  bPwrOn2PwrGood       50 * 2 milli seconds
  bHubContrCurrent      1 milli Ampere
  DeviceRemovable    0x00
  PortPwrCtrlMask    0xff
 Hub Port Status:
   Port 1: 0000.0503 highspeed power enable connect
   Port 2: 0000.0100 power
   Port 3: 0000.0100 power
   Port 4: 0000.0100 power
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0 Full speed (or root) hub
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0001
  Self Powered

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         1 Single TT
  bMaxPacketSize0        64
  idVendor           0x1d6b Linux Foundation
  idProduct          0x0002 2.0 root hub
  bcdDevice            4.09
  iManufacturer           3 Linux 4.9.78-rt61-yocto-preempt-rt+ dwc2_hsotg
  iProduct                2 DWC OTG Controller
  iSerial                 1 ffb00000.usb
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              12
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             1
  wHubCharacteristic 0x0008
    Ganged power switching
    Per-port overcurrent protection
    TT think time 8 FS bits
  bPwrOn2PwrGood        1 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0x00
  PortPwrCtrlMask    0xff
 Hub Port Status:
   Port 1: 0000.0503 highspeed power enable connect
Device Status:     0x0001
  Self Powered

[-- Attachment #3: Type: text/plain, Size: 200 bytes --]

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: High CPU load produced by USB (DW2)

[Minas Harutyunyan]

Hi,

On 3/5/2018 11:14 PM, Marek Vasut wrote:
> On 02/20/2018 06:51 AM, Minas Harutyunyan wrote:
> [...]
>>>>> 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
> 
> See attached
> 
>> and driver debug log.
> 
> What exactly do you mean by this one ?
Enable debugging messages and verbose debugging messages for dwc2 from 
make menuconfig. Provide dmesg starting from dwc2 load till HS device 
connected to dwc2 port and enumerated.

Thanks,
Minas

> 

Re: High CPU load produced by USB (DW2)

[Minas Harutyunyan]

Hi,

On 3/6/2018 10:45 AM, Minas Harutyunyan wrote:
> Hi,
> 
> On 3/5/2018 11:14 PM, Marek Vasut wrote:
>> On 02/20/2018 06:51 AM, Minas Harutyunyan wrote:
>> [...]
>>>>>> 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
>>
>> See attached
>>
>>> and driver debug log.
>>
>> What exactly do you mean by this one ?
> Enable debugging messages and verbose debugging messages for dwc2 from
> make menuconfig. Provide dmesg starting from dwc2 load till HS device
> connected to dwc2 port and enumerated.
> 
> Thanks,
> Minas
> 
>>
> 
> 
Driver debug log not required.
Based on lsusb output: to dwc2 port connected "Standard Microsystems 
Corp. USB 2.0 Hub" to which connected your HS device "SanDisk Corp. 
Ultra". Because of connected HUB, which have periodic endpoint 
(Interrupt IN EP1) like all HUB's, dwc2 forced in Buffer DMA mode unmask 
SOF interrupts.

Thanks,
Minas

Re: High CPU load produced by USB (DW2)

[Marek Vasut]

On 03/06/2018 09:09 AM, Minas Harutyunyan wrote:
> Hi,
> 
> On 3/6/2018 10:45 AM, Minas Harutyunyan wrote:
>> Hi,
>>
>> On 3/5/2018 11:14 PM, Marek Vasut wrote:
>>> On 02/20/2018 06:51 AM, Minas Harutyunyan wrote:
>>> [...]
>>>>>>> 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
>>>
>>> See attached
>>>
>>>> and driver debug log.
>>>
>>> What exactly do you mean by this one ?
>> Enable debugging messages and verbose debugging messages for dwc2 from
>> make menuconfig. Provide dmesg starting from dwc2 load till HS device
>> connected to dwc2 port and enumerated.
>>
>> Thanks,
>> Minas
>>
>>>
>>
>>
> Driver debug log not required.
> Based on lsusb output: to dwc2 port connected "Standard Microsystems
> Corp. USB 2.0 Hub" to which connected your HS device "SanDisk Corp.
> Ultra". Because of connected HUB, which have periodic endpoint
> (Interrupt IN EP1) like all HUB's, dwc2 forced in Buffer DMA mode unmask
> SOF interrupts.

I don't understand the last part, can you rephrase ?

What does that mean regarding the SOF question above ?