[PATCH v2 1/4] PM / Domains: Remove pm_genpd_dev_need_restore() API

Ulf Hansson ulf.hansson at linaro.org
Fri Oct 3 03:36:43 PDT 2014


On 2 October 2014 17:54, Sylwester Nawrocki <s.nawrocki at samsung.com> wrote:
> On 02/10/14 15:30, Ulf Hansson wrote:
> [...]
>> Correct me if I am wrong, but I think in principle these exynos
>> drivers don't use pm_runtime_set_active() during ->probe() and are
>> instead relying on CONFIG_PM_RUNTIME to be enabled.
>
> Yes, pm_runtime_set_active() is not used in probe(), I believe this
> is not required. In case of those IP blocks there is no use of activating
> them during probe(). Instead we check if PM_RUNTIME is enabled through
> pm_runtime_enabled() helper and enable the device clock(s) if not.
> I agree it all doesn't quite work in current mainline for !PM_RUNTIME,
> since there is nothing ensuring that the power domains are enabled
> in such kernel configuration.
>
>> That's not a good behaviour. If these drivers are build without
>> CONFIG_PM_RUNTIME - they won't work.
>
> They wouldn't similarly work with pm_runtime_set_active() call in probe()
> with CONFIG_PM_RUNTIME disabled, would they ?

Yes they would, although they require some minor additional adaptations.

Those resources that are enabled from the driver's runtime PM resume
callback, should also be enabled during ->probe(). The
pm_runtime_set_active() will then update the state to reflect this.

Then, if CONFIG_PM_RUNTIME is enabled - the device will be scheduled
to go inactive from driver core (pm_request_idle()), after ->probe()
has completed. Thus saving power if it's unused.
If CONFIG_PM_RUNTIME isn't enabled - the driver will still be
functional, since all resources are enabled during ->probe().

Kind regards
Uffe



More information about the linux-arm-kernel mailing list