Hi. On Tue, Feb 07, 2012 at 02:19:49PM -0800, Paul Zimmerman wrote: > > -----Original Message----- > > From: Paul Zimmerman > > Sent: Tuesday, February 07, 2012 1:16 PM > > > > 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. 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. -- balbi
Attachment:
signature.asc
Description: Digital signature
