Re: [PATCH v4 2/2] usb: dwc3: Add Google Tensor SoC DWC3 glue driver

On Thu, Nov 06, 2025, Roy Luo wrote:

On Thu, Nov 6, 2025 at 8:38 AM Thinh Nguyen [off-list ref] wrote:

quoted

On Tue, Nov 04, 2025, Roy Luo wrote:

quoted

On Tue, Nov 4, 2025 at 10:07 AM Thinh Nguyen [off-list ref] wrote:

quoted

On Fri, Oct 31, 2025, Roy Luo wrote:

quoted

On Wed, Oct 29, 2025 at 6:35 PM Thinh Nguyen [off-list ref] wrote:

In dwc3_google_suspend(), looks like is_hibernation is set after you
enable pme irq, probably very unlikely, but can the interrupt be
asserted then? If so, will there be another interrupt asserted?
Otherwise the current logic may think it was spurious interrupt a miss
an event.

The pme interrupt can only be asserted after controller is in
hibernation, that is, after the usb psw dom is turned off and
the dwc3_google_usb_psw_pd_notifier() callback is
completed. So no, the interrupt won't fire before is_hibernation
is set.

Thanks for the confirmation.


<snip>

quoted

quoted

quoted

quoted

I'm still trying to wrap my head around how usb_top_pd, usb_psw_pd, and
the google->dev are working together in the glue here, particularly why
usb_top_pd is needed. It seems usb_top_pd shouldn't be handled by this
glued? Do you do anything except setting wakeup-capable?

BR,
Thinh

To provide more context, the underlying usb power domain has 3 power
states: Full Power, Power Gated, Off. The usb_top_pd and usb_psw_pd
are the logical power domains to represent the 3 power states.
- Full Power:     usb_psw_pd ON,   usb_top_p ON.
- Power Gated: usb_psw_pd OFF, usb_top_p ON.
- Off:                 usb_psw_pd OFF, usb_top_p OFF.

To enter hibernation, the usb power domain must enter Power Gated
state. To achieve this, this glue driver holds a handle to usb_top_pd
and would cast a vote to keep it ON when attempting to enter
hibernation. In addition, the usb_psw_pd runtime PM is directly tied
to google->dev so that usb_psw_pd would be OFF when google->dev
suspends. Together, the usb power domain would reach Power Gated
state when device suspends.

I hope this information helps.

Yes. This is very helpful.

So, while the glue driver is bound, usb_top_pd is always ON? Even when
xhci driver is not bound or when in device mode?

Since usb_top_pd is the parent power domain of usb_psw_pd, and
usb_psw_pd RPM is directly tied to glue device, usb_top_pd would
be ON when glue device is active (because usb_psw_pd is ON)
and would be OFF when glue device suspends in non-hibernation
scenarios (because usb_psw_pd is OFF). In hibernation scenario,
a vote is casted for usb_top_pd to keep it on even when the
glue device is suspended and usb_psw_pd is OFF.

To your question, usb_top_pd is not always ON because it would be
turned off when the glue device suspends in non-hibernation scenario.
When in device mode and provided dwc3 dev is active, usb_top_pd
would be ON because its child usb_psw_pd is ON.

Thanks for the clarification and bearing with my questions.

If there's no device connected, do you role-switch back to default mode?
Often I see that the role-switch is defaulted to peripheral and switch
to default mode if there's no connection.

Yes, the default mode would be peripheral and it would switch
to peripheral mode if there's no connection.

quoted

I want to check the case where the device may wakeup by connection but
cannot because it is not in host mode. Do you have a separate
TCPC/connector that can wakeup the system on attachment?

Yes, there's a separate TCPC/connector to trigger a role
switch when there's an incoming connection.

This addressed my concerns. My other comments are minor nits.

You can include this on your next submission:

Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>

Thanks,
Thinh