On Sat, Jun 22, 2024 at 8:05 AM Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx> wrote: > > Sorry for the delay response regarding this. > > On Wed, Jun 19, 2024, joswang wrote: > > Hi Thinh > > > > The workaround solution provided by your company for this issue is as follows: > > Workaround：if the phy support direct P3 to P2 transition，program > > GUSB3PIPECTL.P3P2Tranok=1 > > > > As the databook mentions: > > This bit is used only for some non-Synopsys PHYs that cannot do LFPS in P3. > > This bit is used by third-party SS PHY. It must be set to '0' for Synopsys PHY. > > > > For Synopsys PHY, if this bit is set to "1", will it cause unknown problems? > > Please help confirm this, thank you! > > > > That depends on what your use case and requirements are. > > I've reviewed this case. The impact to this issue is that power state > change may take longer than expected. It may violate the PIPE spec, but > functionally, at least for how linux drivers are handled, I'm not clear > on how this will impact the typical user. > > Can you help clarify your use case and what does this resolve beside the > fact that it workaround the increase latency/response time. > > Thanks, > Thinh Your company provides usage scenarios: System software places the controller in low-power when there is no traffic on the USB. Subsequently, system software programs the controller to exit low-power to resume traffic. The method to reproduce the problem provided by your company: 1. Program the DWC_usb31 controller to operate in device mode of operation. Program GUSB3PIPECTL.P3P2TranOK=0. To increase the probability of hitting the problem run with a slower frequency for suspend_clk (for example, 32 KHz and 160 KHz). 2. Place the link in U3 while ensuring that pipe_powerdown is driven to P3. 3. Program DWC_usb31 controller to exit U3. Ensure that for P0 ->P2 transition pipe_PhyStatus is returned immediately. 4. Program U3 exit from the remote link. 5. Program a D3 entry (pm_power_state_request=D3) at the same time (from the device application) and observe if the D3 entry acknowledgement (current_power_state_u3pmu=D3) takes longer than expected (> 10 ms). Currently, we do not have a real environment to verify this case, but considering the Android GKI regulations, we need to submit patches to Linux in advance. Based on the following workaround solution provided by your company，since the hardware cannot be changed, we can only use workaround 1 at present. Workaround 1: If the PHY supports direct P3 to P2 transition, program GUSB3PIPECTL.P3P2TranOK=1. However, note that as per PIPE4 Specification, direct transition from P3 to P2 is illegal. Workaround 2: Delay the pipe_PhyStatus assertion by an amount greater than two suspend_clk durations at the input of the controller's PIPE interface. We have the following questions and hope you can help us confirm them. Thank you! 1. This case seems to describe that the P3 to P2 power state change takes a long time, that is, the DWC3_usb31 controller takes a long time to exit the D3 state. Please help evaluate whether this problem is perceived from the software perspective, such as whether there is a problem in the xhci_suspend or xhci_resume process. If from the software perspective, this case will not cause the xhci driver to fail, then we may not deal with this problem. 2. If this case causes the above problem, for Synopsys PHY, configuring GUSB3PIPECTL.P3P2TranOK=1 will cause other unknown problems?
