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 --]
next prev parent 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.