| Message ID | 201104130205.26988.rjw@sisk.pl (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Wed, 13 Apr 2011, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rjw@sisk.pl> > > Change the PM core's behavior related to power domains in such a way > that, if a power domain is defined for a given device, its callbacks > will be executed instead of and not in addition to the device > subsystem's PM callbacks. > > The idea behind the initial implementation of power domains handling > by the PM core was that power domain callbacks would be executed in > addition to subsystem callbacks, so that it would be possible to > extend the subsystem callbacks by using power domains. It turns out, > however, that this wouldn't be really convenient in some important > situations. > > For example, there are systems in which power can only be removed > from entire power domains. On those systems it is not desirable to > execute device drivers' PM callbacks until it is known that power is > going to be removed from the devices in question, which means that > they should be executed by power domain callbacks rather then by > subsystem (e.g. bus type) PM callbacks, because subsystems generally > have no information about what devices belong to which power domain. > Thus, for instance, if the bus type in question is the platform bus > type, its PM callbacks generally should not be called in addition to > power domain callbacks, because they run device drivers' callbacks > unconditionally if defined. What about systems where it makes sense to execute the subsystem callbacks even if power isn't going to be removed from the device? It's quite possible that the subsystem could reduce the device's power consumption even when the device isn't powered down completely. Is the extra overhead of invoking the subsystem callback really all that troublesome? Alan Stern
On Wed, Apr 13, 2011 at 8:17 AM, Alan Stern <stern@rowland.harvard.edu> wrote: > On Wed, 13 Apr 2011, Rafael J. Wysocki wrote: > >> From: Rafael J. Wysocki <rjw@sisk.pl> >> >> Change the PM core's behavior related to power domains in such a way >> that, if a power domain is defined for a given device, its callbacks >> will be executed instead of and not in addition to the device >> subsystem's PM callbacks. >> >> The idea behind the initial implementation of power domains handling >> by the PM core was that power domain callbacks would be executed in >> addition to subsystem callbacks, so that it would be possible to >> extend the subsystem callbacks by using power domains. It turns out, >> however, that this wouldn't be really convenient in some important >> situations. >> >> For example, there are systems in which power can only be removed >> from entire power domains. On those systems it is not desirable to >> execute device drivers' PM callbacks until it is known that power is >> going to be removed from the devices in question, which means that >> they should be executed by power domain callbacks rather then by >> subsystem (e.g. bus type) PM callbacks, because subsystems generally >> have no information about what devices belong to which power domain. >> Thus, for instance, if the bus type in question is the platform bus >> type, its PM callbacks generally should not be called in addition to >> power domain callbacks, because they run device drivers' callbacks >> unconditionally if defined. > > What about systems where it makes sense to execute the subsystem > callbacks even if power isn't going to be removed from the device? > It's quite possible that the subsystem could reduce the device's power > consumption even when the device isn't powered down completely. The understanding Rafael and I came to was that if a power domain is attached to a device, then the power domain becomes the responsible party. Normally this means it will turn around and immediately call the bus_type pm ops, but it has the option to not call them if for a particular system it knows better, or to defer calling them. Basically, if you're using a power domain, it is assumed that the power domain has particular knowledge about the system, and it should have the option to override the default behaviour. > > Is the extra overhead of invoking the subsystem callback really all > that troublesome? It isn't an overhead problem. It's a control & complexity problem. We could try to implement a heuristic or api to control when the bus type PM ops should be overridden, but I think it is cleaner to make it a rule that if you implement a power domain, then that power domain becomes responsible for all PM operations. g.
Hi Rafael, On Wed, Apr 13, 2011 at 9:05 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > From: Rafael J. Wysocki <rjw@sisk.pl> > > Change the PM core's behavior related to power domains in such a way > that, if a power domain is defined for a given device, its callbacks > will be executed instead of and not in addition to the device > subsystem's PM callbacks. Thanks for your work on this! I'm very happy to see a more fine grained interface for SoC specific code compared to the weak symbols and other coarse grained alternatives for the platform bus. My only thought on this is if we really want to limit ourselves to only control power domains using these callbacks. I can imagine that some SoCs want to do other non-power domain specific operations with these callbacks, and if so, perhaps using the term power domain as name of the pointer in struct device would be somewhat odd. OTOH, I really dislike naming discussions in general and I can't really think of any good names. So it all looks more like a set of system specific PM override hooks. Or is there something that is really power domain specific with these hooks? Thanks, / magnus
On Thursday, April 14, 2011, Magnus Damm wrote: > Hi Rafael, > > On Wed, Apr 13, 2011 at 9:05 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > From: Rafael J. Wysocki <rjw@sisk.pl> > > > > Change the PM core's behavior related to power domains in such a way > > that, if a power domain is defined for a given device, its callbacks > > will be executed instead of and not in addition to the device > > subsystem's PM callbacks. > > Thanks for your work on this! I'm very happy to see a more fine > grained interface for SoC specific code compared to the weak symbols > and other coarse grained alternatives for the platform bus. > > My only thought on this is if we really want to limit ourselves to > only control power domains using these callbacks. I can imagine that > some SoCs want to do other non-power domain specific operations with > these callbacks, and if so, perhaps using the term power domain as > name of the pointer in struct device would be somewhat odd. OTOH, I > really dislike naming discussions in general and I can't really think > of any good names. So it all looks more like a set of system specific > PM override hooks. > > Or is there something that is really power domain specific with these hooks? Not in principle, but I think there is. Namely, if there are two groups of devices belonging to the same bus type (e.g. platform) that each require different PM handling, it is legitimate to call them "power domains" (where "domain" means "a set of devices related to each other because of the way they need to be handled"), even if they don't share power resources. Of course, if they do share power resources, the term is just right. :-) Thanks, Rafael
On Wednesday, April 13, 2011, Grant Likely wrote: > On Wed, Apr 13, 2011 at 8:17 AM, Alan Stern <stern@rowland.harvard.edu> wrote: > > On Wed, 13 Apr 2011, Rafael J. Wysocki wrote: > > > >> From: Rafael J. Wysocki <rjw@sisk.pl> > >> > >> Change the PM core's behavior related to power domains in such a way > >> that, if a power domain is defined for a given device, its callbacks > >> will be executed instead of and not in addition to the device > >> subsystem's PM callbacks. > >> > >> The idea behind the initial implementation of power domains handling > >> by the PM core was that power domain callbacks would be executed in > >> addition to subsystem callbacks, so that it would be possible to > >> extend the subsystem callbacks by using power domains. It turns out, > >> however, that this wouldn't be really convenient in some important > >> situations. > >> > >> For example, there are systems in which power can only be removed > >> from entire power domains. On those systems it is not desirable to > >> execute device drivers' PM callbacks until it is known that power is > >> going to be removed from the devices in question, which means that > >> they should be executed by power domain callbacks rather then by > >> subsystem (e.g. bus type) PM callbacks, because subsystems generally > >> have no information about what devices belong to which power domain. > >> Thus, for instance, if the bus type in question is the platform bus > >> type, its PM callbacks generally should not be called in addition to > >> power domain callbacks, because they run device drivers' callbacks > >> unconditionally if defined. > > > > What about systems where it makes sense to execute the subsystem > > callbacks even if power isn't going to be removed from the device? > > It's quite possible that the subsystem could reduce the device's power > > consumption even when the device isn't powered down completely. > > The understanding Rafael and I came to was that if a power domain is > attached to a device, then the power domain becomes the responsible > party. Normally this means it will turn around and immediately call > the bus_type pm ops, but it has the option to not call them if for a > particular system it knows better, or to defer calling them. > > Basically, if you're using a power domain, it is assumed that the > power domain has particular knowledge about the system, and it should > have the option to override the default behaviour. > > > > > Is the extra overhead of invoking the subsystem callback really all > > that troublesome? > > It isn't an overhead problem. It's a control & complexity problem. > We could try to implement a heuristic or api to control when the bus > type PM ops should be overridden, but I think it is cleaner to make it > a rule that if you implement a power domain, then that power domain > becomes responsible for all PM operations. Well said. :-) I'm taking that as an ACK for my patch if you don't mind. Thanks, Rafael
Hi, The following two patches are based on top of https://patchwork.kernel.org/patch/702401/ . [1/2] converts shmobile (both the ARM and SH flavors) to using a power domain for overriding the platform bus type's PM callbacks, which makes it possible to remove the __weak definitions of the runtime PM callbacks from platform.c, which is done in [2/2]. Comments welcome. Thanks, Rafael
On Fri, 15 Apr 2011, Rafael J. Wysocki wrote: > On Thursday, April 14, 2011, Magnus Damm wrote: > > My only thought on this is if we really want to limit ourselves to > > only control power domains using these callbacks. I can imagine that > > some SoCs want to do other non-power domain specific operations with > > these callbacks, and if so, perhaps using the term power domain as > > name of the pointer in struct device would be somewhat odd. OTOH, I > > really dislike naming discussions in general and I can't really think > > of any good names. So it all looks more like a set of system specific > > PM override hooks. > > > > Or is there something that is really power domain specific with these hooks? > > Not in principle, but I think there is. Namely, if there are two groups > of devices belonging to the same bus type (e.g. platform) that each require > different PM handling, it is legitimate to call them "power domains" (where > "domain" means "a set of devices related to each other because of the way > they need to be handled"), even if they don't share power resources. > > Of course, if they do share power resources, the term is just right. :-) They could be called "PM domains" instead of "power domains". That's legitimate because they do get used by the PM core, even if they don't literally involve groups of devices sharing the same power supply. Alan Stern
On Thu, Apr 14, 2011 at 5:12 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > On Wednesday, April 13, 2011, Grant Likely wrote: >> On Wed, Apr 13, 2011 at 8:17 AM, Alan Stern <stern@rowland.harvard.edu> wrote: >> > On Wed, 13 Apr 2011, Rafael J. Wysocki wrote: >> > >> >> From: Rafael J. Wysocki <rjw@sisk.pl> >> >> >> >> Change the PM core's behavior related to power domains in such a way >> >> that, if a power domain is defined for a given device, its callbacks >> >> will be executed instead of and not in addition to the device >> >> subsystem's PM callbacks. >> >> >> >> The idea behind the initial implementation of power domains handling >> >> by the PM core was that power domain callbacks would be executed in >> >> addition to subsystem callbacks, so that it would be possible to >> >> extend the subsystem callbacks by using power domains. It turns out, >> >> however, that this wouldn't be really convenient in some important >> >> situations. >> >> >> >> For example, there are systems in which power can only be removed >> >> from entire power domains. On those systems it is not desirable to >> >> execute device drivers' PM callbacks until it is known that power is >> >> going to be removed from the devices in question, which means that >> >> they should be executed by power domain callbacks rather then by >> >> subsystem (e.g. bus type) PM callbacks, because subsystems generally >> >> have no information about what devices belong to which power domain. >> >> Thus, for instance, if the bus type in question is the platform bus >> >> type, its PM callbacks generally should not be called in addition to >> >> power domain callbacks, because they run device drivers' callbacks >> >> unconditionally if defined. >> > >> > What about systems where it makes sense to execute the subsystem >> > callbacks even if power isn't going to be removed from the device? >> > It's quite possible that the subsystem could reduce the device's power >> > consumption even when the device isn't powered down completely. >> >> The understanding Rafael and I came to was that if a power domain is >> attached to a device, then the power domain becomes the responsible >> party. Normally this means it will turn around and immediately call >> the bus_type pm ops, but it has the option to not call them if for a >> particular system it knows better, or to defer calling them. >> >> Basically, if you're using a power domain, it is assumed that the >> power domain has particular knowledge about the system, and it should >> have the option to override the default behaviour. >> >> > >> > Is the extra overhead of invoking the subsystem callback really all >> > that troublesome? >> >> It isn't an overhead problem. It's a control & complexity problem. >> We could try to implement a heuristic or api to control when the bus >> type PM ops should be overridden, but I think it is cleaner to make it >> a rule that if you implement a power domain, then that power domain >> becomes responsible for all PM operations. > > Well said. :-) > > I'm taking that as an ACK for my patch if you don't mind. And so you should. g.
On Fri, 15 Apr 2011, Rafael J. Wysocki wrote: > On Wednesday, April 13, 2011, Grant Likely wrote: > > On Wed, Apr 13, 2011 at 8:17 AM, Alan Stern <stern@rowland.harvard.edu> wrote: > > > On Wed, 13 Apr 2011, Rafael J. Wysocki wrote: > > > > > >> From: Rafael J. Wysocki <rjw@sisk.pl> > > >> > > >> Change the PM core's behavior related to power domains in such a way > > >> that, if a power domain is defined for a given device, its callbacks > > >> will be executed instead of and not in addition to the device > > >> subsystem's PM callbacks. > > >> > > >> The idea behind the initial implementation of power domains handling > > >> by the PM core was that power domain callbacks would be executed in > > >> addition to subsystem callbacks, so that it would be possible to > > >> extend the subsystem callbacks by using power domains. It turns out, > > >> however, that this wouldn't be really convenient in some important > > >> situations. > > >> > > >> For example, there are systems in which power can only be removed > > >> from entire power domains. On those systems it is not desirable to > > >> execute device drivers' PM callbacks until it is known that power is > > >> going to be removed from the devices in question, which means that > > >> they should be executed by power domain callbacks rather then by > > >> subsystem (e.g. bus type) PM callbacks, because subsystems generally > > >> have no information about what devices belong to which power domain. > > >> Thus, for instance, if the bus type in question is the platform bus > > >> type, its PM callbacks generally should not be called in addition to > > >> power domain callbacks, because they run device drivers' callbacks > > >> unconditionally if defined. > > > > > > What about systems where it makes sense to execute the subsystem > > > callbacks even if power isn't going to be removed from the device? > > > It's quite possible that the subsystem could reduce the device's power > > > consumption even when the device isn't powered down completely. > > > > The understanding Rafael and I came to was that if a power domain is > > attached to a device, then the power domain becomes the responsible > > party. Normally this means it will turn around and immediately call > > the bus_type pm ops, but it has the option to not call them if for a > > particular system it knows better, or to defer calling them. > > > > Basically, if you're using a power domain, it is assumed that the > > power domain has particular knowledge about the system, and it should > > have the option to override the default behaviour. > > > > > > > > Is the extra overhead of invoking the subsystem callback really all > > > that troublesome? > > > > It isn't an overhead problem. It's a control & complexity problem. > > We could try to implement a heuristic or api to control when the bus > > type PM ops should be overridden, but I think it is cleaner to make it > > a rule that if you implement a power domain, then that power domain > > becomes responsible for all PM operations. > > Well said. :-) > > I'm taking that as an ACK for my patch if you don't mind. Grant presented a convincing explanation. I have no objections. Alan Stern
On Friday, April 15, 2011, Alan Stern wrote: > On Fri, 15 Apr 2011, Rafael J. Wysocki wrote: > > > On Thursday, April 14, 2011, Magnus Damm wrote: > > > > My only thought on this is if we really want to limit ourselves to > > > only control power domains using these callbacks. I can imagine that > > > some SoCs want to do other non-power domain specific operations with > > > these callbacks, and if so, perhaps using the term power domain as > > > name of the pointer in struct device would be somewhat odd. OTOH, I > > > really dislike naming discussions in general and I can't really think > > > of any good names. So it all looks more like a set of system specific > > > PM override hooks. > > > > > > Or is there something that is really power domain specific with these hooks? > > > > Not in principle, but I think there is. Namely, if there are two groups > > of devices belonging to the same bus type (e.g. platform) that each require > > different PM handling, it is legitimate to call them "power domains" (where > > "domain" means "a set of devices related to each other because of the way > > they need to be handled"), even if they don't share power resources. > > > > Of course, if they do share power resources, the term is just right. :-) > > They could be called "PM domains" instead of "power domains". That's > legitimate because they do get used by the PM core, even if they don't > literally involve groups of devices sharing the same power supply. Well, "power domain" can be regarded as a short form of "power management domain", which makes the point kind of moot. ;-) Rafael
"Rafael J. Wysocki" <rjw@sisk.pl> writes: > From: Rafael J. Wysocki <rjw@sisk.pl> > > Convert OMAP1 to using the new generic clock manipulation routines > and a device power domain for runtime PM instead of overriding the > platform bus type's runtime PM callbacks. This allows us to simplify > OMAP1-specific code and to share some code with other platforms > (shmobile in particular). > > Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Kevin Hilman <khilman@ti.com>
On Monday, May 16, 2011, Kevin Hilman wrote: > "Rafael J. Wysocki" <rjw@sisk.pl> writes: > > > From: Rafael J. Wysocki <rjw@sisk.pl> > > > > Convert OMAP1 to using the new generic clock manipulation routines > > and a device power domain for runtime PM instead of overriding the > > platform bus type's runtime PM callbacks. This allows us to simplify > > OMAP1-specific code and to share some code with other platforms > > (shmobile in particular). > > > > Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> > > Acked-by: Kevin Hilman <khilman@ti.com> Thanks!
Index: linux-2.6/drivers/base/power/runtime.c =================================================================== --- linux-2.6.orig/drivers/base/power/runtime.c +++ linux-2.6/drivers/base/power/runtime.c @@ -168,7 +168,6 @@ static int rpm_check_suspend_allowed(str static int rpm_idle(struct device *dev, int rpmflags) { int (*callback)(struct device *); - int (*domain_callback)(struct device *); int retval; retval = rpm_check_suspend_allowed(dev); @@ -214,7 +213,9 @@ static int rpm_idle(struct device *dev, dev->power.idle_notification = true; - if (dev->type && dev->type->pm) + if (dev->pwr_domain) + callback = dev->pwr_domain->ops.runtime_idle; + else if (dev->type && dev->type->pm) callback = dev->type->pm->runtime_idle; else if (dev->class && dev->class->pm) callback = dev->class->pm->runtime_idle; @@ -223,19 +224,10 @@ static int rpm_idle(struct device *dev, else callback = NULL; - if (dev->pwr_domain) - domain_callback = dev->pwr_domain->ops.runtime_idle; - else - domain_callback = NULL; - - if (callback || domain_callback) { + if (callback) { spin_unlock_irq(&dev->power.lock); - if (domain_callback) - retval = domain_callback(dev); - - if (!retval && callback) - callback(dev); + callback(dev); spin_lock_irq(&dev->power.lock); } @@ -382,7 +374,9 @@ static int rpm_suspend(struct device *de __update_runtime_status(dev, RPM_SUSPENDING); - if (dev->type && dev->type->pm) + if (dev->pwr_domain) + callback = dev->pwr_domain->ops.runtime_suspend; + else if (dev->type && dev->type->pm) callback = dev->type->pm->runtime_suspend; else if (dev->class && dev->class->pm) callback = dev->class->pm->runtime_suspend; @@ -400,8 +394,6 @@ static int rpm_suspend(struct device *de else pm_runtime_cancel_pending(dev); } else { - if (dev->pwr_domain) - rpm_callback(dev->pwr_domain->ops.runtime_suspend, dev); no_callback: __update_runtime_status(dev, RPM_SUSPENDED); pm_runtime_deactivate_timer(dev); @@ -582,9 +574,8 @@ static int rpm_resume(struct device *dev __update_runtime_status(dev, RPM_RESUMING); if (dev->pwr_domain) - rpm_callback(dev->pwr_domain->ops.runtime_resume, dev); - - if (dev->type && dev->type->pm) + callback = dev->pwr_domain->ops.runtime_resume; + else if (dev->type && dev->type->pm) callback = dev->type->pm->runtime_resume; else if (dev->class && dev->class->pm) callback = dev->class->pm->runtime_resume; Index: linux-2.6/drivers/base/power/main.c =================================================================== --- linux-2.6.orig/drivers/base/power/main.c +++ linux-2.6/drivers/base/power/main.c @@ -425,10 +425,8 @@ static int device_resume_noirq(struct de if (dev->pwr_domain) { pm_dev_dbg(dev, state, "EARLY power domain "); - pm_noirq_op(dev, &dev->pwr_domain->ops, state); - } - - if (dev->type && dev->type->pm) { + error = pm_noirq_op(dev, &dev->pwr_domain->ops, state); + } else if (dev->type && dev->type->pm) { pm_dev_dbg(dev, state, "EARLY type "); error = pm_noirq_op(dev, dev->type->pm, state); } else if (dev->class && dev->class->pm) { @@ -516,7 +514,8 @@ static int device_resume(struct device * if (dev->pwr_domain) { pm_dev_dbg(dev, state, "power domain "); - pm_op(dev, &dev->pwr_domain->ops, state); + error = pm_op(dev, &dev->pwr_domain->ops, state); + goto End; } if (dev->type && dev->type->pm) { @@ -628,12 +627,11 @@ static void device_complete(struct devic { device_lock(dev); - if (dev->pwr_domain && dev->pwr_domain->ops.complete) { + if (dev->pwr_domain) { pm_dev_dbg(dev, state, "completing power domain "); - dev->pwr_domain->ops.complete(dev); - } - - if (dev->type && dev->type->pm) { + if (dev->pwr_domain->ops.complete) + dev->pwr_domain->ops.complete(dev); + } else if (dev->type && dev->type->pm) { pm_dev_dbg(dev, state, "completing type "); if (dev->type->pm->complete) dev->type->pm->complete(dev); @@ -731,7 +729,12 @@ static int device_suspend_noirq(struct d { int error; - if (dev->type && dev->type->pm) { + if (dev->pwr_domain) { + pm_dev_dbg(dev, state, "LATE power domain "); + error = pm_noirq_op(dev, &dev->pwr_domain->ops, state); + if (error) + return error; + } else if (dev->type && dev->type->pm) { pm_dev_dbg(dev, state, "LATE type "); error = pm_noirq_op(dev, dev->type->pm, state); if (error) @@ -748,11 +751,6 @@ static int device_suspend_noirq(struct d return error; } - if (dev->pwr_domain) { - pm_dev_dbg(dev, state, "LATE power domain "); - pm_noirq_op(dev, &dev->pwr_domain->ops, state); - } - return 0; } @@ -840,21 +838,27 @@ static int __device_suspend(struct devic goto End; } + if (dev->pwr_domain) { + pm_dev_dbg(dev, state, "power domain "); + error = pm_op(dev, &dev->pwr_domain->ops, state); + goto End; + } + if (dev->type && dev->type->pm) { pm_dev_dbg(dev, state, "type "); error = pm_op(dev, dev->type->pm, state); - goto Domain; + goto End; } if (dev->class) { if (dev->class->pm) { pm_dev_dbg(dev, state, "class "); error = pm_op(dev, dev->class->pm, state); - goto Domain; + goto End; } else if (dev->class->suspend) { pm_dev_dbg(dev, state, "legacy class "); error = legacy_suspend(dev, state, dev->class->suspend); - goto Domain; + goto End; } } @@ -868,12 +872,6 @@ static int __device_suspend(struct devic } } - Domain: - if (!error && dev->pwr_domain) { - pm_dev_dbg(dev, state, "power domain "); - pm_op(dev, &dev->pwr_domain->ops, state); - } - End: device_unlock(dev); complete_all(&dev->power.completion); @@ -964,7 +962,14 @@ static int device_prepare(struct device device_lock(dev); - if (dev->type && dev->type->pm) { + if (dev->pwr_domain) { + pm_dev_dbg(dev, state, "preparing power domain "); + if (dev->pwr_domain->ops.prepare) + error = dev->pwr_domain->ops.prepare(dev); + suspend_report_result(dev->pwr_domain->ops.prepare, error); + if (error) + goto End; + } else if (dev->type && dev->type->pm) { pm_dev_dbg(dev, state, "preparing type "); if (dev->type->pm->prepare) error = dev->type->pm->prepare(dev); @@ -983,13 +988,6 @@ static int device_prepare(struct device if (dev->bus->pm->prepare) error = dev->bus->pm->prepare(dev); suspend_report_result(dev->bus->pm->prepare, error); - if (error) - goto End; - } - - if (dev->pwr_domain && dev->pwr_domain->ops.prepare) { - pm_dev_dbg(dev, state, "preparing power domain "); - dev->pwr_domain->ops.prepare(dev); } End: