Re: [PATCH v2 2/2] usb: dwc3: Modify runtime pm ops to handle bus suspend

[Thinh Nguyen]

On Thu, Jun 01, 2023, Elson Serrao wrote:
> 
> 
> On 5/30/2023 3:51 PM, Thinh Nguyen wrote:
> > Hi,
> > 
> > On Fri, May 26, 2023, Elson Roy Serrao wrote:
> > > For bus suspend scenario we should skip controller halt
> > > as we still have the usb cable connected. So modify the
> > 
> > How can you know when the host requests for resume to wakeup the device?
> > We haven't implemented hibernation to handle that. If it's communicated
> > through the glue layer specific via the phy's event, then how do you
> > plan to make it generic and not specific to your platform?
> > 
> 
> The wakeup/resume path is platform dependent and is handled by phy sideband
> signalling through an external interrupt. This patch handles the dwc3 RT
> resume once the glue driver resume is triggered for bus resume scenario.
> According to the dwc3 data book (Section7.2) hibernation is an optional
> feature. So we may not be able to make it generic?

It would only do so if hibernation is enabled. The driver can detect if
the controller is capable of hibernation and if it is enabled.

> Adding a dt node (say snps,external-wakeup) to distinguish the wakeup path
> and having a check against that flag in the dwc3 RT pm ops to handle bus
> suspend/resume, would that be an acceptable solution ?
> 
> 
> > The reason we halt the controller and force a soft-disconnect is because
> > we don't have a handle for this yet. Perhaps I'm missing something here
> > because I don't see you handle it here either.
> > 
> > > runtime pm ops to handle bus suspend scenario. Also invoke
> > > autosuspend when device receives U3 notification so that
> > > controller can enter runtime suspended state. Ensure that
> > > the controller is brought out of runtime suspend before
> > > triggering remote wakeup.
> > > 


If the change is only specific to your platform, make sure to target
only your platform. Perhaps that can be done through a dt property.

Also, document how your platform works to capture the host resume event.
There are usb2 and usb3 phys. What can your platform capture to detect
host resume for each phy.

For usb3 phy, can your phy assert interrupt on LFPS signal of host
resume?

For example, Roger's patch related to TI platform can capture UTMI
linestate [*].

BR,
Thinh

[*] https://lore.kernel.org/linux-usb/fdfe707e-7689-373a-3aa4-e81cfeac1562@xxxxxxxxxx/