linux-kernel - Re: Enable runtime PM automatically?

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <7hppbg63zo.fsf@deeprootsystems.com>
Date:	Thu, 18 Dec 2014 13:29:47 -0800
From:	Kevin Hilman <khilman@...nel.org>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Marek Szyprowski <m.szyprowski@...sung.com>,
	Amit Daniel Kachhap <amit.daniel@...sung.com>,
	"linux-arm-kernel\@lists.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-samsung-soc\@vger.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <len.brown@...el.com>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Tomasz Figa <tomasz.figa@...il.com>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Sylwester Nawrocki <s.nawrocki@...sung.com>,
	Thomas Abraham <thomas.ab@...sung.com>,
	Pankaj Dubey <pankaj.dubey@...sung.com>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	Linux PM list <linux-pm@...r.kernel.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Enable runtime PM automatically?

Geert Uytterhoeven <geert@...ux-m68k.org> writes:

> On Tue, Dec 16, 2014 at 11:10 PM, Kevin Hilman <khilman@...nel.org> wrote:
>> At a deeper level, the problem with this approach is that this is more
>> generically a runtime PM dependency problem, not a genpd problem.  For
>> example, what happens when the same kind of dependency exists on a
>> platform using a custom PM domain instead of genpd (like ACPI.) ?
>>
>> What's needed to solve this problem is a generalized way to have runtime
>> PM dependencies between devices.  Runtime PM already automatically
>> handles parent devices as one type of dependent device (e.g. a parent
>> device needs to be runtime PM resumed before its child.)  So what's
>> needed is a generic way to other PM dependencies with the runtime PM
>> core (not the genpd core.)
>>
>> If runtime PM handles the dependencies corretcly, then genpd (and any
>> other PM domain) will get them "for free".
>
> Having the proper dependencies is not sufficient. Currently drivers have to do
> something to use runtime PM.

Well, yes.  I've been assuming runtime-PM aware drivers.  But I agree
with the goal of not having to assume that.

> By default, runtime PM is disabled for a device
> ("device.power.disable_depth = 1").
>
> However, if PM domains are active, drivers must be runtime PM-aware for the
> gpd_dev_ops.start() method to be called in the first place (perhaps this is just
> one bug that's easy to fix --- the device is "assumed suspended", but can be
> used). They must
>   1. call pm_runtime_enable() to enable runtime PM for the device,
>   2. call pm_runtime_get_sync() to prevent the device from being put in a
>     low-power state at any time. This second call has the
> "side-effect" of calling
>     gpd_dev_ops.start().
>
> Hence, if PM domains are enabled, wouldn't it make sense to
>   1. enable runtime PM by default, for all devices (bound and unbound),
>   2. call pm_runtime_get_sync(), for all devices bound to a driver.
> Of course we have to keep track if drivers call any of the pm_runtime_*()
> methods theirselves, as that would have to move them from automatic to
> manual mode.
>
> Would this be feasible?

We have to be careful about where the PM core's _get_sync() call goes.

Because you're talking about "bound" devices, I guess you mean after the
driver probes?  Otherwise, it gets tricky if the _get_sync() is before
the driver probes, because the device driver may have work it wants to
do in its runtime PM callbacks, which are not initialized/available
before the driver probes.  Doing this before probe also makes it rather
difficult to know for sure the actual physical state of the device, and
make sure it matches the runtime PM state of the device.  Rafael
mentioned this also, and I'm not sure how we can be sure of the physical
state.

Some thoughts: devices without drivers would be runtime resumed by the
core, but will never be suspended, so the PM domain will never shut
down.  I guess the core will have to keep track of the devices it
automatically runtime resumed and decide to runtime suspend them too?
Hmm, where would that go?

Kevin
--
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/