> From: Felipe Balbi [mailto:balbi@xxxxxx] > Sent: Tuesday, February 07, 2012 10:15 PM > > On Tue, Feb 07, 2012 at 02:19:49PM -0800, Paul Zimmerman wrote: > > > > > > OK, I will poke around and see if I can find an existing driver to use as > > > an example. > > > > Hi Felipe, > > > > Can you explain a little about how the runtime_pm stuff will work in > > the DWC3 driver, disregarding the HAPS platform for now. > > > > For example, if the device is a PCI device, won't the PM ops need to > > be part of the struct pci_driver in the dwc3-pci module? > > > > If so, how will they be able to communicate with the routines in the > > dwc3 module? Or if not, how will that work exactly? > > Ok, the way it works is that the e.g. PCI device is a parent device to > the DWC3. So, in fact, you will end up with two pm ops: one that only > knows about DWC3 and one that only knows about PCI. > > The pm core guarantees that parent's e.g. runtime_suspend(), will only > be called after all children (in this case, only one) are suspended. > Likewise for resume. > > So, what we need to do is to make one pm ops that knows everything the > power management features on DWC3 and another which knows about PCI, > then hook them up properly and whenever pm usage counter reaches zero, > dwc3's runtime_suspend() is called, then after that dwc3-pci's > runtime_suspend() will be called. Thank you! That was the piece of the puzzle that was missing. OK, I'll take a crack at implementing the pm ops for dwc3 and dwc3-pci. > Just keep in mind that glue layer also needs to keep track of its own > usage counters, what I mean by that, is that on dwc3-pci probe you > should probably call pm_runtime_get_sync() and right before returning > from probe, you call pm_runtime_put(). This will make sure that the PCIe > device is powered up when you need and can be autosuspended when you > don't need it anymore. I see that Alan had a correction to this part in a later email. -- Paul -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
