On Thu, Aug 04, 2022 at 06:04:53PM +0200, Johan Hovold wrote: > On Thu, Aug 04, 2022 at 08:35:10AM -0700, Matthias Kaehlcke wrote: > > On Thu, Aug 04, 2022 at 09:35:16AM +0200, Johan Hovold wrote: > > > After enabling runtime suspend for the dwc3 core, dwc3 glue and the xHCI > > the dwc3-qcom enters autosuspend when the delay expires. > > > > > And the controller is resumed in the wakeup-interrupt handler for the > > > runtime PM case. > > > > > > It seems to work ok, and it looks like the driver has supported this > > > since it was first merged. > > > > With and without your patch dwc3-qcom enters autosuspend and stays there. > > USB devices like a mouse or a USB to Ethernet adapter keep working while > > the glue is suspended. > > Are you sure you're looking at the right controller? And that it is > actually suspended? Good point! My mind was set on a SC7180 system, which has a single dwc3 controller, but this time I was tinkering on a SC7280 board, which has two dwc3, and obviously I was looking at the wrong one (－‸ლ) > If you plug in a keyboard, enable autosuspend for all devices in the > path (from glue to the keyboard device) and type away, then the > controller must remain active. Stop typing, and all devices in the chain > should suspend. That's what I expected, and now that I'm looking at the right controller I'm seeing it. I wondered whether the glue device was somehow special. > > How is the runtime resume triggered for the dwc3 glue? > > Either by the host driver when it needs to access the device, or by the > device if it is remote-wakeup capable (e.g. a keyboard, but not > necessarily a speaker). > > Note that the latter part is what is broken currently as the wakeup > interrupts were not enabled and those are needed to wake up sc8280xp > when the dwc3 glue has been runtime suspended. Thanks for helping me to get a better understanding!
