Message-ID: <20240626012927.obxdoarp6cotfowo@synopsys.com>
Date: Wed, 26 Jun 2024 01:29:32 +0000
From: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
To: joswang <joswang1221@...il.com>
CC: Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        "robh@...nel.org" <robh@...nel.org>,
        "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
        "conor+dt@...nel.org" <conor+dt@...nel.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "balbi@...nel.org" <balbi@...nel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        joswang <joswang@...ovo.com>
Subject: Re: [PATCH v2, 2/3] usb: dwc3: core: add p3p2tranok quirk

Hi Joswang,

On Tue, Jun 25, 2024, joswang wrote:
> On Sat, Jun 22, 2024 at 8:05 AM Thinh Nguyen <Thinh.Nguyen@...opsys.com> 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?

For this to occur, the host must try to transition from P3 to P2, and
somehow goes into suspend and request for D3 immediately, which causes
D3 request to take longer than expected.

This is not something we would expect for xhci, because:
1) On xhci_resume(), we would expect the pci device to be powered on
   (D0). So it would not be in a condition for this issue to occur.
2) xhci_resume() takes some time restore the host controller states
   and reinitialize the registers and start the controller. Then
   xhci_suspend() also takes some time to save the states and halt the
   controller. So there's some time before the pci driver can send a D3
   request. I don't know how long your setup may take, but it's unlikely
   to hit this condition.

Even if we do somehow manage to run into this scenario, we can set a pci
quirk to increase pci_pm_d3hot_delay to increase the suspend/resume
timeout, avoid hitting this.

Unfortunately we don't have the real environment to verify this. But
IMHO, for a typical use case, I don't see the need to introduce this
"snps,p2p3tranok-quirk".

BR,
Thinh

Powered by blists - more mailing lists