On Sat, 6 Feb 2010, Mark Brown wrote:
> On Fri, Feb 05, 2010 at 09:57:46PM -0500, Alan Stern wrote:
> > On Fri, 5 Feb 2010, Mark Brown wrote:
>
> > > It's not that it's hard per se, it's that it feels like it's peering
> > > inside the implementation of the API. Having the PM core provide
>
> > You mean like providing an is_runtime_suspended() test? Then you could
> > write:
>
> > int my_suspend(struct device *dev)
> > {
> > if (is_runtime_suspended(dev))
> > return 0;
> > return my_runtime_suspend(dev);
> > }
>
> > Or maybe you'd prefer to see a convenient pm_use_runtime_suspend()
> > function that you could use for your dev_pm_ops.suspend pointer, which
> > would do essentially the same as the above? (Along with a
> > corresponding pm_use_runtime_resume() function, of course.)
>
> Either (or both, of course - implementing the second would probably
> imply the former). The ops that can be assigned would be the clearest
> option but the accessor function should be enough to make it clear that
> this is something drivers are supposed to be doing.
Providing the new ops would be a little awkward because
CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME are independent: Either can be
enabled without the other. This means the code to call the
runtime_suspend and runtime_resume methods would have to be split out
into a separate source file that would get built whenever either config
option is enabled. It's doable, just somewhat awkward.
I'll give it a try and we'll see how it turns out...
Alan Stern
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
