Sebastian von Ohr <vonohr@xxxxxxxxxxx> writes: > Thanks for your super-fast reply! > >> From: Felipe Balbi [mailto:balbi@xxxxxxxxxx] >> 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:
signature.asc
Description: PGP signature
