On Tue, Nov 18, 2014 at 10:58:17PM +0100, Rafael J. Wysocki wrote: > On Tuesday, November 18, 2014 01:02:29 PM Dmitry Torokhov wrote: > > On Tue, Nov 18, 2014 at 10:17:46PM +0100, Rafael J. Wysocki wrote: > > > On Tuesday, November 18, 2014 10:03:18 PM Rafael J. Wysocki wrote: > > > > On Tuesday, November 18, 2014 12:04:38 PM Dmitry Torokhov wrote: > > > > > 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"? > > > > > > > > It is in ACPI like that too, but not in the form of the ACPI PM domain. > > > > > > > > > IOW why ACPI is that special? > > > > > > > > The ACPI PM domain is there specifically for bus types that don't > > > > provide > > > > non-trivial PM callbacks to avoid duplication of code (if it didn't > > > > exist, > > > > all of the bus types in question would need to provide callbacks with > > > > optional ACPI handling in them). That's all about it. > > > > > > > > And there are bus types that provide non-trivial PM callbacks *and* use > > > > ACPI in them, like PCI, and that is more interleaved with the native PM > > > > in there. For those bus types we can't add devices to the ACPI PM > > > > domain > > > > just because they have ACPI companion objects. > > > > > > > > I'm not really sure why it is important here, though. We're talking > > > > about > > > > genpd, aren't we? > > > > > > > > I just wanted to indicate that the PM domains concept is not only about > > > > handling power domains and not all of its use cases can be shoehorned > > > > into > > > > the same scheme. > > > > > > And by the way, things worked just fine for the ACPI PM domain before > > > commit > > > 46420dd73b80 (PM / Domains: Add APIs to attach/detach a PM domain for a > > > device) > > > which put the ACPI PM domain and genpd into one bag, which was a mistake, > > > because they are different things. > > > > > > > Can we maybe settle on the naming then so that we do not mix them up in > > the future? For me PM domain is group of devices that share certain > > power constraints so that they have to be powered up and down together. > > Is this definition is not correct (for genpd at least)? > > It is correct for genpd, it isn't correct for the ACPI PM domain. > > > And what is the proper definition for ACPI PM domain? > > I agree that the terminology is (somewhat?) confusing. > > From the code perspective, using a PM domain object is a way to provide PM > callbacks that will be executed for a subset of devices instead of or in > addition to the bus type (or class or device type) callbacks. Of course, > that applies to proper power domains in particular, but it can also apply > to broader sets of devices. In the ACPI PM domain case this covers devices > with ACPI power management support (or more precisely, devices with ACPI > companion objects that can provide PM support). In this context the word > "domain" means as much as "area of control" (which is a proper dictionary > definition of it AFAICS). > > genpd is all about proper power domains, like you said.
OK, thank you for explaining this. Up until now I was blissfully oblivious to the majority of PM intricacies :) -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
