Hi, Jun Li writes: >> 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? > >> If that's the case, then you probably need >> to use the flag you mentioned above. Please verify with that. > > With quirk of "snps,dis_u3_susphy_quirk", I had verified it can > resolve the problem, but this will make USB3 Super Speed PHY > never enter P3, this is a huge impact on USB power consumption. > > The timeout increase has no impact on those platforms which have > no this problem, but can give chance for platform with very low > supspend clk(like my case 32k) to work. I was under the impression that issuing a command would wake the PHY up. I don't have access to DWC3 documentation to verify, but that's as I remember. Is that not the case? -- balbi