linux-kernel - Re: [linux-pm] [RFC][PATCH 1/2] PM / Runtime: Support for generic I/O power domains

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201105041908.26070.rjw@sisk.pl>
Date:	Wed, 4 May 2011 19:08:25 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	MyungJoo Ham <myungjoo.ham@...il.com>
Cc:	Linux PM mailing list <linux-pm@...ts.linux-foundation.org>,
	linux-sh@...r.kernel.org, Greg KH <gregkh@...e.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [linux-pm] [RFC][PATCH 1/2] PM / Runtime: Support for generic I/O power domains

On Wednesday, May 04, 2011, MyungJoo Ham wrote:
> On Sat, Apr 30, 2011 at 5:11 AM, Rafael J. Wysocki <rjw@...k.pl> wrote:
> >
> > Well, not really.  There are a few things to consider.
> >
> > First, in general, there may be devices that have a real parent and belong
> > to a power domain at the same time, so we can't "steal" the parent
> > pointers from them.
> 
> Ah. right we only have one parent per device. Ok, setting a power
> domain as a device's parent is not going to work for some devices.
> 
> 
> However, I have some other questions.
> 
> 1. pm_genpd_runtime_suspend and pm_genpd_runtime_resume are opened to
> outside (not static and "extern"ed). Are devices supposed to call
> pm_genpd_runtime_* directly?

I suppose you mean drivers.  No, they aren't.

> Shouldn't they be hidden so that devices
> are forced to turn on/off power domains with runtime_pm framework
> only? Is there any reason to expose them?

I thought some subsystems might bypass pm_genpd_init() and use their own
initialization, in which case the extern definitions would be useful.

That said, they aren't necessary at the moment, so I'll make them static
in the final version of the patch.

> 2.  If we can assure that related clocks are not turned on when a
> power domain is shutting down, it'd be nice.

If you look at the shmobile patch at
https://patchwork.kernel.org/patch/742932/
you'll see that it uses the ->stop_device() and ->start_device()
callbacks for this purpose.

> I guess it would be sufficient to let it "WARN" at
> gov->power_down_ok().

Sure, you can do that too.

> Is it the intention of governor?

No, the intention of the governor is to make it possible to take
for example, latencies, into account when deciding whether or not to
power down the domain.  In short, my idea is that the governor will
have information on how much time it's going to take to power down
and resume the power domain (along with all devices) and, on the other hand,
what maximum wakeup latency is acceptable for the given power domain.
It will compare the two numbers and return "true" if the second one is
greater, for example.  That said, I don't have a clean use case at the moment,
so that's more of a future stub than something necessary right now.

> Thank you! I also think this is going to help us a lot, too :)

Good to hear that. :-)

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/