All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@kernel.org>
To: Sebastian von Ohr <vonohr@smaract.com>,
	Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Thinh Nguyen <thinhn@synopsys.com>
Subject: RE: [BUG REPORT] usb: dwc3: Timeouts with USB 2.0 LPM active
Date: Tue, 04 May 2021 09:28:54 +0300	[thread overview]
Message-ID: <87bl9rhv15.fsf@kernel.org> (raw)
In-Reply-To: <3d2305a43c1f4e3dad2e29286f42982d@smaract.com>

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

Sebastian von Ohr <vonohr@smaract.com> writes:

> Thanks for your super-fast reply!
>
>> From: Felipe Balbi [mailto:balbi@kernel.org]
>> Sent: Monday, May 3, 2021 3:52 PM
>> It's like the host is trying to go down to lower LPM states every 100ms:
>> 
>>      irq/13-dwc3-236     [000] d..1    71.363262: dwc3_event: event (00000401): WakeUp [U0]
>>      irq/13-dwc3-236     [000] d..1    71.363315: dwc3_event: event (00000401): WakeUp [U0]
>>      irq/13-dwc3-236     [000] d..1    71.363423: dwc3_event: event (00006084): ep1out: Transfer In Progress [0] (SIm)
>
> How do you arrive at 100ms? These wakeups are around 50 microseconds apart.

heh, I should've written 100uS :-) but yeah, they're 50uS apart.

>> > Is the USB 2.0 LPM extension even supposed to work with the dwc3 controller? I
>> 
>> yes, it should be supported :-)
>
> I've spent some time looking at the code and I don't understand how the device 
> is supposed to wake up the host once it's able to receive new data again. The 

For U1/U2 it's mostly handled by the HW itself. The only thing we do is
set the appropriate bits for the relevant SetFeature requests, see ep0.c.

> closest thing I could find is the __dwc3_gadget_wakeup function which is called 
> by dwc3_send_gadget_ep_cmd. But I don't understand the condition there. The 
> wakeup is only executed for DWC3_DEPCMD_STARTTRANSFER, but I understand bulk 
> transfers are only started once the endpoint is configured and then only 
> DWC3_DEPCMD_UPDATETRANSFER is used.

That's a "special note" on the databook :-)

>> could you share a dump of your descriptors? It could be that the wake-up
>> latencies are incorrect which tricks the host into trying to go down to
>> lower LPM states too frequently.
>
> Bus 001 Device 003: ID 3386:0001  
> Device Descriptor:
>   bLength                18
>   bDescriptorType         1
>   bcdUSB               2.10
>   bDeviceClass            0 (Defined at Interface level)
>   bDeviceSubClass         0 
>   bDeviceProtocol         0 
>   bMaxPacketSize0        64
>   idVendor           0x3386 
>   idProduct          0x0001 
>   bcdDevice            5.12
>   iManufacturer           1 SmarAct
>   iProduct                2 SmarAct Sensor
>   iSerial                 3 PSC-00000038
>   bNumConfigurations      1
>   Configuration Descriptor:
>     bLength                 9
>     bDescriptorType         2
>     wTotalLength           32
>     bNumInterfaces          1
>     bConfigurationValue     1
>     iConfiguration          4 SmarAct Config 1
>     bmAttributes         0xc0
>       Self Powered
>     MaxPower                2mA
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        0
>       bAlternateSetting       0
>       bNumEndpoints           2
>       bInterfaceClass       255 Vendor Specific Class
>       bInterfaceSubClass      0 
>       bInterfaceProtocol      0 
>       iInterface              5 SmarAct Sensor
>       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     0x01  EP 1 OUT
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0200  1x 512 bytes
>         bInterval               1
> 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   0x0000010e
>       Link Power Management (LPM) Supported
>   SuperSpeed USB Device Capability:
>     bLength                10
>     bDescriptorType        16
>     bDevCapabilityType      3
>     bmAttributes         0x00
>     wSpeedsSupported   0x000f
>       Device can operate at Low Speed (1Mbps)
>       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

Hmm, this is the maximum allowed value

>     bU2DevExitLat         511 micro seconds

This is not. Can you try setting this to 0x7ff and see if the problem
goes away? It could be that your platform needs more time to
wakeup. Then you're going to have to characterize it to figure out how
much this value should be.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

  reply	other threads:[~2021-05-04  6:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-03 13:12 [BUG REPORT] usb: dwc3: Timeouts with USB 2.0 LPM active Sebastian von Ohr
2021-05-03 13:52 ` Felipe Balbi
2021-05-03 14:15   ` Sebastian von Ohr
2021-05-04  6:28     ` Felipe Balbi [this message]
2021-05-04  9:47       ` Sebastian von Ohr
2021-05-05 12:37         ` Felipe Balbi
2021-05-12  9:28           ` Sebastian von Ohr
2021-05-05  8:02   ` Mathias Nyman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bl9rhv15.fsf@kernel.org \
    --to=balbi@kernel.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    --cc=thinhn@synopsys.com \
    --cc=vonohr@smaract.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.