Hi, Thinh Nguyen writes: > Jun Li wrote: >>> -----Original Message----- >>> From: Felipe Balbi On Behalf Of Felipe Balbi >>> Sent: 2020年5月15日 17:31 >>> To: Jun Li >>> Cc: John Stultz ; lkml ; Yu >>> Chen ; Greg Kroah-Hartman ; Rob >>> Herring ; Mark Rutland ; ShuFan Lee >>> ; Heikki Krogerus ; >>> Suzuki K Poulose ; Chunfeng Yun >>> ; Hans de Goede ; Andy Shevchenko >>> ; Valentin Schneider ; >>> Jack Pham ; Linux USB List ; open >>> list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS ; >>> Peter Chen ; Jun Li ; Thinh Nguyen >>> >>> Subject: Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device >>> controller >>> >>> >>> Hi, >>> >>> Jun Li writes: >>>>> @@ -397,12 +407,18 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned >>> cmd, >>>>> dwc3_gadget_ep_get_transfer_index(dep); >>>>> } >>>>> >>>>> - if (saved_config) { >>>>> + if (saved_hs_config) { >>>>> reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); >>>>> - reg |= saved_config; >>>>> + reg |= saved_hs_config; >>>>> dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); >>>>> } >>>>> >>>>> + if (saved_ss_config) { >>>>> + reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); >>>>> + reg |= saved_ss_config; >>>>> + dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg); >>>>> + } >>>>> + >>>>> return ret; >>>>> } >>>> Unfortunately this way can't work, once the SS PHY enters P3, disable >>>> suspend_en can't force SS PHY exit P3, unless do this at the very >>>> beginning to prevent SS PHY entering P3(e.g. add "snps,dis_u3_susphy_quirk" for >>> test). >>> >>> It sounds like you have a quirky PHY. >> From what I got from the IC design, the behavior of DWC3_GUSB3PIPECTL_SUSPHY >> bit should be as what I said, not a quirky. >> >> Hi Thinh, could you comment this? > > You only need to wake up the usb2 phy when issuing the command while > running in highspeed or below. If you're running in SS or higher, > internally the controller does it for you for usb3 phy. In Jun's case, > it seems like it takes longer for his phy to wake up. > > IMO, in this case, I think it's fine to increase the command timeout. Is there an upper limit to this? Is 32k clock the slowest that can be fed to the PHY as a suspend clock? -- balbi