PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)
in [Kernel]
|
Prev: Add Xeon 7500 series support to oprofile
Next: [PATCH 01/24] drivers/block/floppy.c: Convert some #include <asm/ to #include <linux/
From: Alan Stern on 21 Jan 2010 22:10 On Thu, 21 Jan 2010, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rjw(a)sisk.pl> > > Add new device sysfs attribute, power/control, allowing the user > space to block the run-time power management of devices. If this > attribute is set to "on", the driver of the device won't be able to power > manage it at run time (without breaking the rules) and the device will > always be in the full power state (except when the entire system goes > into a sleep state). .... > --- linux-2.6.orig/drivers/base/power/power.h > +++ linux-2.6/drivers/base/power/power.h > @@ -2,11 +2,15 @@ > > extern void pm_runtime_init(struct device *dev); > extern void pm_runtime_remove(struct device *dev); > +extern void pm_runtime_allow(struct device *dev); > +extern void pm_runtime_forbid(struct device *dev); Can you write a follow-up patch that moves these declarations to a public header file like include/linux/pm_runtime.h and EXPORTs the two new routines? It is sometimes useful for drivers to be able to call the routines directly. For example, we disable runtime PM for most USB devices by default. But a few drivers may know that their devices are able to handle it, so they want to change the default setting when they are bound. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on 22 Jan 2010 17:50 On Fri, 22 Jan 2010, Rafael J. Wysocki wrote: > > For example, we disable runtime PM for most USB devices by default. > > But a few drivers may know that their devices are able to handle it, so > > they want to change the default setting when they are bound. > > Runtime PM is disabled for all devices by default unless the driver enables > it. The setting in power/control is to override the driver's choice, so that > it can be disabled even if the driver tries to enable it. > > IOW, the user space is the owner of the power.runtime_auto flag and I don't > think we should allow drivers to modify it. Okay, I understand your point of view. It means I'll have to make some changes to the USB code. No problem. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on 22 Jan 2010 22:30 On Fri, 22 Jan 2010, Rafael J. Wysocki wrote: > > For example, we disable runtime PM for most USB devices by default. > > But a few drivers may know that their devices are able to handle it, so > > they want to change the default setting when they are bound. > > Runtime PM is disabled for all devices by default unless the driver enables > it. The setting in power/control is to override the driver's choice, so that > it can be disabled even if the driver tries to enable it. > > IOW, the user space is the owner of the power.runtime_auto flag and I don't > think we should allow drivers to modify it. After more thought, I changed my mind about this. The ability to override the driver's choice means that the user should be able to enable runtime PM even if the driver tries to disable it, as well as the other way 'round. In other words, it's not productive to say the user is the owner of the runtime_auto flag. What we _really_ want is to put the user in charge of whether or not a device is subject to runtime PM. First of all, note that if the driver doesn't support runtime PM then it makes no difference what value runtime_auto has. The issue is moot. So suppose the driver does support runtime PM. In this case, it's irrelevant that runtime PM starts out disabled by default when the device structure is initialized. The bus subsystem and driver will reinitialize the settings in the way they think best. But if the driver decides to disable runtime PM and pm_runtime_forbid() isn't EXPORTed, then the driver will be forced to implement its decision by leaving disable_depth > 0 -- which means there's nothing the user can do. The power/control attribute won't help. On the other hand, if the driver decides to disable runtime PM and it can do so by calling pm_runtime_forbid(), then the user can override the decision. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on 23 Jan 2010 10:30 On Sat, 23 Jan 2010, Rafael J. Wysocki wrote: > Hmm, OK. > > Of course, if the driver decides to leave disable_depth > 0, the user still > won't be able to do anything about that, but if I understand correctly, you > want drivers to have the option to use pm_runtime_forbid() initially, right > after pm_runtime_enable(), so that the user space can turn the runtime PM > on if desired via sysfs. > > That makes sense. I have a usage case for that myself. :-) > > Updated patch is appended. It looks good. Acked-by: Alan Stern <stern(a)rowland.harvard.edu> Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jesse Barnes on 24 Jan 2010 11:00
"Rafael J. Wysocki" <rjw(a)sisk.pl> wrote: >On Saturday 23 January 2010, Alan Stern wrote: >> On Sat, 23 Jan 2010, Rafael J. Wysocki wrote: >> >> > Hmm, OK. >> > >> > Of course, if the driver decides to leave disable_depth > 0, the user still >> > won't be able to do anything about that, but if I understand correctly, you >> > want drivers to have the option to use pm_runtime_forbid() initially, right >> > after pm_runtime_enable(), so that the user space can turn the runtime PM >> > on if desired via sysfs. >> > >> > That makes sense. I have a usage case for that myself. :-) >> > >> > Updated patch is appended. >> >> It looks good. >> >> Acked-by: Alan Stern <stern(a)rowland.harvard.edu> > >Thanks! > >Rafael > |