On Tue, Nov 18, 2014 at 09:14:56PM +0100, Rafael J. Wysocki wrote: > On Tuesday, November 18, 2014 09:55:15 AM Dmitry Torokhov wrote: > > On Tue, Nov 18, 2014 at 12:44:22PM -0500, Alan Stern wrote: > > > On Tue, 18 Nov 2014, Dmitry Torokhov wrote: > > > > > > > OK. Another question then: pm_runtime_get_noresume() does literally this: > > > > > > > > atomic_inc(&dev->power.usage_count); > > > > > > > > So who is responsible for actually waking up parent device and/or power > > > > domain? Is it simply missing because we did not really have PM domains > > > > before? > > > > > > Ths bus is responsible for making sure that all the standard resources > > > are available -- that is, all the resources that would be needed by a > > > normal device on that bus. Anything beyond that (such as > > > special-purpose clocks) has to be set up by the driver. > > > > > > Thus the bus would insure that the device was powered, its parent was > > > resumed, and the usual clock inputs were enabled. And of course, one > > > mechanism for doing this is to runtime-resume the power domain. > > > > This does not sound like anything bus-specific. Can we move powering on > > the domain before probing into the driver core, similarly to the default > > pin selection by pinctrl? > > We could do that for genpd if devices were added to domains before registering > (those devices). Otherwise, there's no guarantee that all has been set up yet. > > Note that this would only be the case for genpd, not for the ACPI PM domain > in particular, for example. The reason why is that the ACPI PM domain cannot > be used along with bus types that provide non-trivial PM callbacks, so pretty > much the bus type's ->probe needs to decide whether or not to use it. In genpd code there is a notion of providers that match devices and domains. Can we do the same for ACPI and stuff all that knowledge into it's "provider"? IOW why ACPI is that special? -- Dmitry -- 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
 |