On 2 October 2014 17:54, Sylwester Nawrocki <s.nawrocki@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |