Hi, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > On Thu, 4 Aug 2016, Felipe Balbi wrote: > >> > What are you trying to accomplish? Is the problem that wakeup signals >> > only cause the platform device to be runtime-resumed, but you also need >> > the HCD to wake up? And conversely, whenever the HCD gets >> > runtime-suspended you also want the platform device to go into runtime >> > suspend? >> >> this is DWC3 as peripheral-only. PCI Wakeup (PME) wakes up dwc3-pci, but >> we need dwc3 core (a platform device) to be resumed as well. > > Oh, so I got the types wrong. But the basic idea is still the same: > When the parent wakes up, it does a runtime-resume of the child. The > child is then responsible for making sure it stays awake as long as > necessary, and when it goes back to low power the parent naturally does > the same. right. Here's a doubt though: if dwc3-pci does a pm_runtime_resume() of the child, doesn't that mean child will try to sleep right away again since its usage_counter will be zero? We _do_ have a 5s timeout which should be enough to trigger enumeration, but still... I guess I'm missing something here. I guess it'll work just fine since we set a driver flag when we see a bus reset and that gets cleared once a disconnect shows up. Seems like the whole idea is to avoid an extra pm_runtime_put() in ->runtime_resume()? What if user sets autosuspend_delay to 0 in sysfs? Seems like this is likely to break, no? -- balbi
Attachment:
signature.asc
Description: PGP signature
