Hi Mark,
On Tue, Nov 17, 2009 at 12:30 AM, Mark Brown
<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, Nov 09, 2009 at 01:31:36PM +0000, Mark Brown wrote:
>> On Mon, Nov 09, 2009 at 10:58:58AM +0000, Mark Brown wrote:
>> > On Mon, Nov 09, 2009 at 11:54:47AM +0900, Kuninori Morimoto wrote:
>
> Any chance someone from the PM side could comment on the issue below?
>
>> > > +static int fsi_runtime_nop(struct device *dev)
>> > > +{
>> > > + /* Runtime PM callback shared between ->runtime_suspend()
>> > > + * and ->runtime_resume(). Simply returns success.
>> > > + *
>> > > + * This driver re-initializes all registers after
>> > > + * pm_runtime_get_sync() anyway so there is no need
>> > > + * to save and restore registers here.
>> > > + */
>> > > + return 0;
>> > > +}
>> >
>> > This sets off alarm bells but it's perfectly reasonable, especially with
>> > platforms able to put things into a low power state with no explicit
>> > driver code now they can do power domain style things like SH. I've
>> > CCed in the PM folks since this seems like a perfectly reasonable use
>> > case which ought to be handled more nicely.
On SuperH we have Runtime PM enabled on a few platforms together with
a few updated drivers. The latest driver to become more power aware is
this FSI driver.
It's all quite simple, in the FSI driver we enable the clock to the
FSI hardware using Runtime PM functions, and whenever the clock is
turned off the SuperH specific bus code _may_ decide to call
->runtime_suspend() and turn off the power domain. The "_may_" comes
from the fact that multiple hardware blocks may be grouped together
into a single power domain, and all devices in the power domain must
support Runtime PM and have their clocks disabled before we can turn
off the power.
At this point the SuperH specific platform bus code requires the
callbacks ->runtime_suspend() and ->runtime_resume() to be present. It
may be a good idea to allow them to be NULL in the future or maybe
having some shared functions, but before starting to break out stuff
I'd like to see how other Runtime PM implementations deal with this.
So unless people object I prefer to keep it as-is for now.
/ magnus
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
