On Wed, Sep 08, 2010 at 10:08:42AM -0700, Kevin Hilman wrote: > Grant Likely <grant.likely@xxxxxxxxxxxx> writes: > > > On Tue, Sep 07, 2010 at 05:54:41PM -0700, Kevin Hilman wrote: > >> From: Kevin Hilman <khilman@xxxxxx> > >> > >> Implement the new runtime PM framework as a thin layer on top of the > >> omap_device API. OMAP specific runtime PM methods are registered with > >> the as custom methods on the platform_bus. > >> > >> In order to determine if a device is an omap_device, its parent device > >> is checked. All omap_devices have a new 'omap_bus' device as their > >> parent device, so checking for this parent is used to check for valid > >> omap_devices. If a device is an omap_device, then the appropriate > >> omap_device functions are called for it. If not, only the generic > >> runtime PM functions are called. > >> > >> Device driver's ->runtime_idle() hook is called when the runtime PM > >> usecount reaches zero for that device. Driver's ->runtime_suspend() > >> hooks are called just before the device is disabled (via > >> omap_device_idle()), and device driver ->runtime_resume() hooks are > >> called just after device has been enabled (via omap_device_enable().) > >> > >> OMAP4 build support from Rajendra Nayak <rnayak@xxxxxx>. > >> > >> Cc: Rajendra Nayak <rnayak@xxxxxx> > >> Signed-off-by: Kevin Hilman <khilman@xxxxxx> > > > > It appears that this one will fail to compile when CONFIG_PM_RUNTIME > > is unset. Once you've fixed that you can add my a-b line: > > Thanks for catching this. > > > Acked-by: Grant Likely <grant.likely@xxxxxxxxxxxx> > > > > I think this should go via Greg's tree to avoid ordering issues. > > Not a strong preference, but I'd rather see this go via OMAP as we are > building on it in the OMAP tree for this merge window. The ordering > issues will only affect OMAP users and I have taken care of that in my > staging branches that other are using for their runtime PM conversions. okay. g. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html